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