WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: LONGDESC in HTML5?

for

From: Vlad Alexander (XStandard)
Date: Sep 25, 2010 3:24AM

I wrote: "Unfortunately, we are still talking about @alt and @longdesc as "image descriptions" with the only difference being the number of characters typed."

Josh wrote: "What else would you like them to do?"

Let's take a look at the text from this article:
http://webaim.org/techniques/images/longdesc

Article text: "In some instances, an image is too complex to describe in a few words."

The purpose of alt is not to "describe" images but to replace them. Alternate text can be quite different than a description of an image.

Article text: "Although there does not appear to be any limit to the length of text in an alt attribute, alt text is meant to be relatively short, so it would be an abuse of this attribute to write more than a few words, or, at most, a few short sentences."

Why? @alt is part of document content just like paragraphs. If you don't impose arbitrary limits on paragraphs, why impose them on alt. The author should decide on the length of alt text.

Article text: "The answer, then, is to provide a brief alt text description of the image and then provide a longer description elsewhere."

This statement implies that alt and longdesc are the same except one is longer than the other.

We need to start calling content in the @alt attribute "textual substitute" for an image, and content appearing in the @longdesc as a "description" if we ever want alt to be authored correctly and longdesc to be used.

Take care,
-Vlad

-------- Original Message --------
From: Joshue O Connor
Date: 9/25/2010 1:38 AM
> On 25/09/2010 02:30, Vlad Alexander (XStandard) wrote:
>> Josh wrote: "FWIW, I think that UA support for @longdesc has been the real culprit,
>> and not necessarily shortcomings with the attribute itself.
>> Without some kind of breakthrough in thinking I sense we may be having this discussion again in ten years.."
>>
>> Greater UA (user agent) or authoring tool support will not help with a "breakthrough in thinking".
>
> Actually, what I really mean is its _implementation_. The user
> experience with @longdesc has been below par (even when supported). I
> have a few ideas on how that could be improved which I have floated in
> working group. Having said that, implementation is a vendor UA issue,
> the spec can define how an element behaves but the quality of the user
> experience is largely depended on how it is implemented in practice. So
> FWIW, I think there is a crucial part of the jigsaw missing.
>
>> The way we define @alt and @longdesc will in the long run change authoring practices and user agent / tool support.
>
> Yes, ARIA 2.0 may make aria-describedby take a URI, I think this will be
> a good move but again, that's down the road. The point is, the way
> @longdesc is defined - is it currently more a help than a hindrance? If
> it is more useful, then retain it and obsolete it when we have a better
> solution. The issue of authors not using it or the shiny new thing -
> will always be there.
>
>> Unfortunately, we are still talking about @alt and @longdesc as "image descriptions" with the only difference being the number of characters typed.
>
> What else would you like them to do? We are talking about mechanisms
> that enable an equivalent user experience, any ideas to make them better
> are very much appreciated.
>
> Cheers
>
> Josh
>
> ********************************************************************
> National Council for the Blind of Ireland (NCBI) is a company
> limited by guarantee (registered in Ireland No. 26293) .
> Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
> NCBI is also a registered Charity (chy4626).
>
> NOTICE: The information contained in this email and any attachments
> is confidential and may be privileged. If you are not the intended
> recipient you should not use, disclose, distribute or copy any of
> the content of it or of any attachment; you are requested to notify
> the sender immediately of your receipt of the email and then to
> delete it and any attachments from your system.
>
> NCBI endeavours to ensure that emails and any attachments generated
> by its staff are free from viruses or other contaminants. However,
> it cannot accept any responsibility for any such which are
> transmitted. We therefore recommend you scan all attachments.
>
> Please note that the statements and views expressed in this email
> and any attachments are those of the author and do not necessarily
> represent the views of NCBI
>
>
> ********************************************************************
>
>
>
>