- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 1 Feb 2012 15:00:38 +1100
- To: Leif H Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: bhawkeslewis@googlemail.com, cooper@w3.org, schwer@us.ibm.com, faulkner.steve@gmail.com, cyns@microsoft.com, ian@hixie.ch, janina@rednote.net, jbrewer@w3.org, mike@w3.org, public-html-a11y@w3.org
Ah thanks, found it in http://www.w3.org/TR/wai-aria-implementation/. So they are just names given to groups of roles, but aren't really something developers should use? If so, I'd flag them, too, in a conformance checker that they should not be used. Thanks, Silvia. On Wed, Feb 1, 2012 at 2:05 PM, Leif H Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > It is defined in Aria. I would describe it as a category role. Authors are > not allowed to use them - they get implemented in AT only. Leif > > ------- Opprinnelig melding ------- >> >> Fra: Silvia Pfeiffer <silviapfeiffer1@gmail.com> >> Til: bhawkeslewis@googlemail.com >> Cc: cooper@w3.org, schwer@us.ibm.com, faulkner.steve@gmail.com, >> cyns@microsoft.com, ian@hixie.ch, janina@rednote.net, jbrewer@w3.org, >> mike@w3.org, public-html-a11y@w3.org >> Sendt: 1/2/'12, 3:59 >> >> >> Can I just ask for clarification: what exactly is an "abstract role"? >> I wasn't able to find a definition in this thread, in the linked >> document or in the ARIA spec. >> >> Thanks, >> Silvia. >> >> On Wed, Feb 1, 2012 at 10:44 AM, Benjamin Hawkes-Lewis >> <bhawkeslewis@googlemail.com> wrote: >>> >>> On Tue, Jan 31, 2012 at 2:01 PM, Michael Cooper <cooper@w3.org> wrote: >>>> >>>> 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 implies there is no such thing as an invalid role token. By >>> defining @role as a space-separated token list, we already oblige >>> conformance checkers to treat tokens - including concrete roles - as >>> conforming. Introducing the phrase "valid role token" only gives the >>> mistaken impression that a conformance checker could distinguish valid >>> and invalid role tokens. >>> >>>> 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. >>> >>> >>> Agreed. >>> >>>> 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. >>> >>> >>> [snip] >>> >>>> 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). >>> >>> >>> [snip] >>> >>>> 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. >>> >>> >>> Who would have a problem with that and why? >>> >>> At the very least, the ARIA spec needs to reserve the abstract and >>> concrete role tokens it *does* define lest they become ambiguous. >>> >>> Authors might easily use abstract roles in a mistaken attempt to >>> improve accessibility. >>> >>> Why not have conformance checkers flag use of abstract roles as >>> erroneous, especially given the ARIA spec says authors MUST not use >>> them? >>> >>>> 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. >>> >>> >>> I can see the rationale for warning on *unknown* roles, given ARIA >>> suggests UAs might implement support for custom roles. >>> >>> -- >>> Benjamin Hawkes-Lewis >>> >> > >
Received on Wednesday, 1 February 2012 04:01:27 UTC