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

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 Tuesday, 31 January 2012 23:45:44 UTC