Re: bug Bug 11891 - add role attribute to list of global attributes and add definition for it (part of Issue 199)

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 03:07:46 UTC