- From: John Foliot <john@foliot.ca>
- Date: Wed, 14 Mar 2012 10:42:36 -0400
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Charles McCathieNevile <chaals@opera.com>, RichardSchwerdtfeger <schwer@us.ibm.com>, W3C WAI-XTECH <wai-xtech@w3.org>, HTMLAccessibility Task Force <public-html-a11y@w3.org>
Quoting Steve Faulkner <faulkner.steve@gmail.com>:
> the bug is in the IE implementation
> acc description is for a human readable description not to pass URL's
>
> the implementation is broken and poorly thought out.
Hi Steve,
I think you are mistaken here (and FWIW I checked this with Rich).
At issue is the AAPI (and now ARIA) processing of non-visible content.
The ARIA Implementation Guide states:
"The following elements are not exposed via the accessibility
API and user agents MUST NOT include them in the accessibility tree:
...Elements, including their descendents, that have host language
semantics specifying that the element is hidden, such as CSS
display:none or visibility:hidden or HTML 5 hidden attribute."
- http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements
Since active links (and other Semantic structure) should normally be
exposed to the Accessibility Tree, but hidden content NOT exposed, the
URL for the longer description that @longdesc references
(ROLE_SYSTEM_LINK) must not be conveyed, thus it defaults to
AccDescription (which is string text):
"The text alternative for a given node is computed as follows:
Skip hidden elements unless the author specifies to use them via an
aria-labelledby or aria-describedby being used in the current
computation. By default, users of assistive technologies won't receive
the hidden information, but an author will be able to explicitly
override that and include the hidden text alternative as part of the
*label string* sent to the accessibility API." (emphasis mine)
- http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd
IE is actually getting it right!
In all working example of @longdesc today (whether via a screen reader
or 3rd-party browser extension) they all operate by querying the DOM,
which IMHO is not actually "broken or poorly thought out" - in fact it
simply underscores that any HTML consuming tool *could* do something
useful with @longdesc, they simply choose not to.
JF
Received on Wednesday, 14 March 2012 14:43:26 UTC