Re: ISSUE 30 @longdesc use cases

On Mon, Aug 23, 2010 at 11:50 PM, Charles McCathieNevile
<chaals@opera.com>wrote:

> On Mon, 23 Aug 2010 14:34:06 +0200, David Singer <singer@apple.com> wrote:
>
>  OK, I hesitate to ask, point this out.  It is perhaps a minor point.
>>
>> There is an assumption/assertion here that a long description is hugely
>> relevant but only through accessibility provisions.
>>
>
> I don't think so. I certainly assume no such thing.
>
> I assume that there are designers who will *not* put such a notice on their
> page (a conclusion based on more than a decade of asking for such things,
> and talking to designers and the people who employ or contract them about
> why it doesn't happen).
>
>
>  But there may easily be puzzled users who do not have vision issues.
>>
>
> Indeed. It's a good use case for implementing it in the browser (as we
> did).
>
> The biggest flaw in our implementation is that we don't automatically
> notify the user whether there is a long description - they have to check for
> each iamge. (The browser+AT implementations I know *do* announce when there
> is a description available). We have a similar issue with accesskey, which
> we do better than other browsers (by providing easy access to all the
> defined accesskeys) but the user has to ask through a direct action if there
> are any rather than being able to have an active non-interfering
> notification.
>
>
>  There is nothing wrong with a page that says "A detailed description of
>> this can be found _here_.",
>>
>
> (except that it breaks the usability guideline to use distinctive text for
> links, which would suggest the link be in the earlier part of the sentence)
>
>
>  and indeed this will, in fact, benefit a number of users other than those
>> using screen readers (users new to the subject, in some cases, for example).
>>
>
> Indeed. Users who have limited vision, but don't typically use a screen
> reader for an example group that significantly expands the target audience.
> Another group is "people who don't actually understand the very intuitive
> graphics designed by the clever graphic artist" which has been a problem I
> have often suffered...
>
>
>  Not using the attribute does not preclude you from building informatively
>> constructed web sites, does it? I don't find "A detailed description of this
>> can be found _here_." 'traumatic' or 'confusing', myself, in general.
>>
>
> One difference is that you don't have any explicit association between the
> image and its description, whereas an img element with a longdesc attribute
> pointing to an absolute URL actually gets benefit from cut-and-paste
> construction.
>
> Also, while this is perfectly possible, as I note above it doesn't seem to
> have taken off, and a reason I have often heard cited in discussion with
> people who might be expected to do this but don't has been that they don't
> want to mess up their visual design. (Yes, this is anecdotal evidence). The
> attribute has the advantage of meeting the use cases (internal or external
> descriptions can be linked with explicit association) without placing any
> constraint on design.
>


The only Websites that I have seen that use a link to a description are
Government Websites or Websites of Government-like organisations that are
not so worreid about their design, but very worried about meeting WCAG
requirements. I think it is being looked at as non-elegant. For example, I
am yet to find images on Apple's Websites that have even a non-empty @alt
attribute, not to speak of a detailed description link.

What I am mostly wondering about is whether in future we want to use things
like @longdesc or prefer to use @aria-described-by. Having both doesn't seem
to make sense to me.

Cheers,
Silvia.