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

On Jun 30, 2007, at 7:07 AM, Joshue O Connor 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? I've said this  
before, but I think it bears repeating because the point gets lost  
(often with facetious responses). 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. We should try to think of how we can move <img> to a  
true embedded content element (like <picture> that has been  
suggested). We should figure out how @alt relates to genuine fallback  
content (and @longdesc as a feeble attempt at fallback content). In  
other words is it unnecessary for elements with genuine fallback  
content and only necessary for <img> and <embed> because they lack  
that capability.

Then I think we should deal with this in a forward looking way.  
Perhaps we need do nothing in the short-term with @longdesc. It can  
merely be one of those omitted attributes along with the <img>  
element in HTML5. The future will bring <picture>fallback</picture>  
alongside <video> and <audio>.

For the present implementation compatibility, I'm not sure what we  
need do. We could recommend authors use @longdesc to point to local  
elements only (within the same document). Perhaps we need a  
<longdesc> element. 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.

I've seen a several dismissive remarks on adding a <picture> element  
in the HTML5 discussions. However, the need for a new embedded  
element with fallback content for still images is far more important  
than adding <video> and <audio>. I'm not saying I'm against those new  
elements, but the need for them is far less than for a new embedded  
content element with fallback for still images.

> 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 think that this content could be  
made available through an inspector or contextual menu. By adding  
this to visual UAs it would help raise awareness for authors.  
However, most users of purely visual UAs will not need to access this  
content.

Take care,
Rob

Received on Saturday, 30 June 2007 12:41:11 UTC