W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2012

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 1 Feb 2012 15:00:38 +1100
Message-ID: <CAHp8n2knhA7prz-f_qGSqOHuNe=__gGULfkdRFBTrrsQQq743Q@mail.gmail.com>
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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:26 UTC