- From: Michael Cooper <cooper@w3.org>
- Date: Tue, 31 Jan 2012 09:01:31 -0500
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- CC: Richard Schwerdtfeger <schwer@us.ibm.com>, Steve Faulkner <faulkner.steve@gmail.com>, Cynthia Shelly <cyns@microsoft.com>, Ian Hickson <ian@hixie.ch>, Janina Sajka <janina@rednote.net>, Judy Brewer <jbrewer@w3.org>, "Michael(tm) Smith" <mike@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
- Message-ID: <4F27F43B.1030505@w3.org>
Benjamin Hawkes-Lewis wrote: > On Fri, Jan 27, 2012 at 3:53 PM, Richard Schwerdtfeger > <schwer@us.ibm.com> wrote: > > Seems reasonable. Where does the WAI-ARIA spec define valid role tokens, though? > I would point to the "Role Attribute" section of the ARIA spec: http://www.w3.org/TR/wai-aria/host_languages#host_general_role > For example, how would an HTML conformance checker determine if > "accordion" is a valid role token? > > The spec defines some roles, but also says user agents may extend them > with new roles and that future specs will define how to use these new > roles interoperably. The Role Attribute section above requires that the role attribute accept *at least* the concrete ARIA roles as values. It does not impose requirements one way or the other about other values, including abstract ARIA roles. It does define that the first *recognized* token is the one used for mapping to the Accessibility API, at which point the WAI-ARIA 1.0 User Agent Implementation Guide http://www.w3.org/TR/wai-aria-implementation/ takes over. This does not require that the first token be the one authors expect will be used - if there is an ARIA 2.0, authors may want to use an ARIA 2.0 token first as the preferred role, and an ARIA 1.0 role as a second token as a backup for user agents that haven't updated yet. ARIA 1.0 user agents would just see the first token is unrecognized and discard it, and use the second. It may be that HTML 5 will be locked to ARIA 1.0, but that may not necessarily be the case by the time it reaches Rec status, and anyway hopefully the "Living Standard" version of HTML would seamlessly support any further versions of ARIA that come along. > It does say that "Content authors MUST NOT use > abstract roles because they are not implemented in the API binding". > There are no user agent constraints on abstract roles. User agents don't know that abstract roles are abstract, they just know they don't have a defined mapping for them. That's why there's an author prohibition on using those (since it's useless) but not a user agent requirement. > Should HTML conformance checkers: > > 1. Allow any token that is not an abstract role defined in WAI-ARIA > (e.g. allow "accordion" and "checkbox" but forbid "input"? > Conformance checkers should *allow* any token that meets the lexical requirements, i.e., doesn't have characters forbidden to a token in a token list. If conformance checkers are checking only for ARIA roles, it would be appropriate to *warn* about unrecognized tokens (including abstract roles). However, because the ARIA spec doesn't require that the role attribute contain only ARIA roles, and the XHTML Vocabulary defines additional ones, it may not be appropriate for conformance checkers to give this warning, unless the HTML spec wishes to constrain the role attribute to contain ARIA roles. The accessibility community wouldn't have a problem with this, but others may, so I recommend not introducing that constraint. > 2. Reject any token that is an abstract role defined in WAI-ARIA and > additionally require the token list to begin with a concrete role > defined in WAI-ARIA (e.g. allow "accordion" and "checkbox" but require > "checkbox" to come first). > Definitely should not require the token list to begin with a concrete role [from ARIA 1.0], because the first token might be a concrete role from a future version of ARIA and should be valid from a forwards compatibility perspective. Same as above on warn, not reject, of unrecognized / unmapped tokens. > 3. Reject any token that is not a concrete role defined in WAI-ARIA > (e.g. reject "accordion" and "input" whereever they occur in the token > list)? > Same as above on warn, not reject, of unrecognized / unmapped tokens. > Whichever way, it would probably be best to be explicit. > Agree. Michael -- Michael Cooper Web Accessibility Specialist World Wide Web Consortium, Web Accessibility Initiative E-mail cooper@w3.org <mailto:cooper@w3.org> Information Page <http://www.w3.org/People/cooper/>
Received on Tuesday, 31 January 2012 14:02:00 UTC