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

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:00:19 UTC