- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 25 Aug 2010 04:08:16 +0200
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: "??HTMLWG WG" <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Leif Halvard Silli, Tue, 24 Aug 2010 18:50:18 +0200: > Steven Faulkner, Tue, 24 Aug 2010 16:04:09 +0100: >> it's not being used to represent an image its being used as a >> container for a long text alternative. > > We have been here before ... The ARIA 1.0 definition of role="img" is > "container": “A container for a collection of elements that form an > image.” Just as we discussed, Ian checked in [1] that <details> has "strong native semantics" as follows: [2] ]] The aria-expanded state must be set to "true" if the element's open attribute is present, and must be set to "false" otherwise. (The role can be changed as described in the next table, but is restricted to roles that use the aria-expanded state.) [[ In ARIA 1.0, an element with role="img" does use the aria-expanded state. Thus, the restriction to "roles that use the aria-expanded state" a first seemed like a permission to use <details role="img">. However, same sentence also says that "[t]he role can be changed as described in the next table", which states: ]] Role must be either form, group, navigation, note, or search [[ Bug 10424 has been filed: [3] to “clarify that <details> can take _all_ roles that use the aria-expanded state”. [1] http://html5.org/tools/web-apps-tracker?from=5330&to=5331 [2] http://dev.w3.org/html5/spec/content-models#annotations-for-assistive-technology-products-aria [3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=10424 -- leif halvard silli
Received on Wednesday, 25 August 2010 02:08:55 UTC