Re: LONGDESC: some current problems and a proposed solution added to the wiki

Robert Burns wrote:
>> Lachlan Hunt wrote:
>>> The method used to reveal the long description is up to the assistive technology.
>>
>> Thats true.
>>
>>> It doesn't need to navigate away from the page as if following an ordinary link, it could reveal it in a separate context instead (e.g. a side bar or popup).
>>
>> It could but currently the user does have to navigate away from the page
>> they are in. Presenting the longdesc content in another pop-up is IMO an
>> inelegant solution also so I would suggest a discussion on what would be
>> the best way to present this information to the user in a manner that is
>> non disruptive. (Although this is a user agent issue it is still
>> important that for our side we have a clear idea of how it ideally
>> should be rendered.
> 
> Are we talking about visual UAs here? Or all UAs? 

In this instance I am referring to screen readers, the term UA, as you
know can refer to browsers, vendor specific assistive technology
applications etc, when I use it in future I will try to be more specific
about what I am referring to.

> We should understand that @longdesc is the after-thought addition of fallback content to an element that is defined as canonically empty. 
>@alt is also part of dealing with that problem. So I think we should deal with those two attributes in that context.

Am not sure if I know what you mean by 'canonically empty'? Empty for
whom? Something is empty if it is empty, null, void or never meant to be
filled. As you know these attributes @alt or @longdesc etc fill a much
needed vacuum for people with disabilities. However, these points raise
an issue that maybe needs to be discussed. If what you say is true (and
I have no reason to disbelieve you Robert) then it may indicate where
there is a disconnect in the specifications. If images or tables were
considered canonically 'empty' than that means that their real world end
use (I mean the diversity of ways the content will be accessed) may not
have correctly considered. Following on from what you say, it could also
then be logically suggested that many HTML element or attributes are
'empty' until filled with some form of content.  That issue aside what
needs to be considered are the various methods used to access the
content these attributes contain, and how important this is to people
with disabilities.

What I am suggesting is rather than considering these attributes as
merely 'fall-backs', they should be considered as vital to the true
spirit of an inclusive web.

> For the present implementation compatibility, I'm not sure what we need do. 

I think that make two of us, or many more of us ;-)

> We could recommend authors use @longdesc to point to local elements only (within the same document). 

I guess that would be a duplication of content and in other ways render
@longdesc redundant as the information is already contained with the
document - and the user may not appreciate reading it twice. @longdesc
content  should be there for users who need it and hidden for those that
don't.

>> I think if it could be retrieved by the UA and then automatically read
>> out, rather like @summary and the user could just move focus when they
>> have finished. No pop-ups, navigating to other pages etc.
> 
> If we're talking about visual UAs, 

I was thinking along the lines of a behind the scenes move where the
screen reader maybe pre-loads the @longdesc content into its virtual
buffer when the image has focus and reads it out after the @alt content
(if @longdesc is present). Gregory mentioned [1]  that he would prefer
it to be a user activated choice, which is also fine but is at the
moment rather inelegant.Also  I think there could be value in this
method by reducing the cognitive load on the user and the complexity of
interrogating the element content by automating the process.

Josh

[1] http://lists.w3.org/Archives/Public/wai-xtech/2007Jun/0058.html











>UAs could easily add longdesc {display: none} for screen media to their default stylesheets and 
>easily support this interim approach. However, in the long-term I think we should fix these deficiencies in the language so that someday we won't have to deal with these piecemeal approaches anymore.

Received on Monday, 2 July 2007 08:18:07 UTC