Re: ISSUE 30 @longdesc use cases

Jonas Sicking, Mon, 23 Aug 2010 11:52:48 -0700:

> I know @hidden and display:none hides content from screen readers when
> reading the general flow of the page. However, as I said, code
> inspection indicates that it does not prevent the content from being
> pointed to by aria-describedby. And my reading of the ARIA
> specification indicates that Firefox is correct in this
> implementation.

Where does ARIA 1.0 speak about @hidden? 

On the positive side, this idea reminds me a little bit about Sander's 
idea from 18th of August 2007, about an <alt></alt> element. [1][2] If 
the A11Y task force is willing to look at <alt> again, then may be 
@hidden could have a role to play there - not impossible, it could have 
a slightly different meaning when used in the <alt></alt> element.  I 
myself find <alt></alt> an interesting idea. still. But I don't expect 
salutation for bringing up that idea at this point in our work  ... 
(Btw, <alt></alt> isn't by necessity linked to removal of @longdesc - 
even your own idea does not by necessity require removal of @longdesc.) 

On the negative side: a general permission for ARIA – or @longdesc (!) 
– to link to any @hidden element, opens up the door to several problems:

1) We have a Decision to not remove @hidden from HTML5. If @aria-* can 
be used to refer to @hidden sections, then it could count as new 
information, which could justify a new look at the Decision.

2) Textual web browsers are obligated to implement @hidden as well. 
However, the permission you suggest, would lead authors to create pages 
containing alternative text that were inaccessible to textual web 
browsers (unless such browsers also support ARIA ...) If we could 
isolate your proposal to @longdesc, then perhaps it would not be the 
biggest problem. However, it seems likely that your proposal would turn 
@hidden into an attractive alternative not only to @longdesc but also 
to @alt and  <object>fallback/object>. Which, again, would lead to the 
mentioned problem for text browsers.

3) The problems created by 2) would also make it necessary to update 
the specification(s) with regard to how to write alternative text.

> However rather than arguing about what specifications say, the first
> order of business should be to check what implementations actually do.

4) To, in this case, look blindly at what works, would lead to a 
convoluted definition of @hidden. What would you suggest? Something 
like this: “@hidden hides an element *except* for @aria compatible 
screen readers” ? Or “it is not permitted to refer to @hidden sections, 
except via an aria reference” ? (To, eventually, say that @hidden has a 
slightly different interpretation when used with the hypothetical <alt 
hidden ></alt> element, does not, however, open up the same Pandoras 
box of inconsistency, as a general permission to link to any @hidden 
element would do.)

[1] http://www.w3.org/html/wg/wiki/ABetterAlt
[2] http://lists.w3.org/Archives/Public/public-html/2007Aug/0691
-- 
leif halvard silli

Received on Monday, 23 August 2010 23:28:42 UTC