- 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:23 UTC