[whatwg] Validator.nu: "Attribute role not allowed on element h2 at this point."

It's my understanding that authors should only apply ARIA via script. The
redundancy cases seem to be the most reasonable use cases I've heard of for
wanting ARIA in the initial markup, but even that seems wrong. What happens
when you have type=range and role=slider, the UA doesn't understand the new
types, and the script either never loads or has an error? The AT will pick
up the role, but none of the functionality will be there. I don't see how
that's better than not having the role applied.


On Tue, Mar 13, 2012 at 3:11 AM, Charles Pritchard <chuck at jumis.com> wrote:

> On 3/12/12 11:42 PM, Simon Pieters wrote:
>
>> On Tue, 13 Mar 2012 02:16:29 +0100, Charles Pritchard <chuck at jumis.com>
>> wrote:
>>
>>  Warnings are generally not useful. Either something is fine and we should
>>>> support it, or it's wrong and we should alert the author. I think "must"
>>>> is very much the appropriate requirement level here.
>>>>
>>>
>>>  From the implementation-side, the spec is wrong, it ranks native HTML
>>> semantics above ARIA DOM semantics.
>>>
>>
>> You're confusing author conformance requirements with UA conformance
>> requirements.
>>
>
> The section did confuse me. It lays out some author requirements then goes
> into what looks like appropriate UA mapping.
> I don't see this working well for ARIA conformance testing, but I do like
> the mapping.
>
> This document tries to set strict requirements on authors for ARIA usage
> which doesn't exist in practice.
> It's intended to help, but I don't think it's needed; I believe it adds
> confusion.
>
> The Restrictions seem fine for telling vendors that they ought to be
> making their ARIA maps from native HTML to ARIA a certain way.
> But, as you said, I'm getting confused reading this doc.
>
>
>
>  As a "best practices" note, it seems overly optimistic. There are
>>> situations with AT navigation where role conflicts do occur and/or
>>> redundancy in tagging is helpful.
>>>
>>
>> Do you have concrete examples?
>>
>
> Concrete? No. I don't have an active JAWS/NVDA/WindowEyes + HTML4 project
> in front of me.
> If I did, I'm sure I'd have some concrete examples of how ARIA and HTML4
> work together with roles.
>
> Some wild guesses:
> Treating a link as a button or a button as a link.
> @disabled and aria-disabled may be used via reference with aria-controls.
> type="range" and role=slider for redundancy.
> various styling tricks with css selectors.
>
> Steve Faulkner posted that sometimes explicit ARIA roles signal to ATs to
> look for more ARIA attributes.
>
> I've used role and/or redundant ARIA within the scripting environment to
> minimize calls in applications checking for roles. Redundancy doesn't harm
> anything, I actively promote it, as it does help, sometimes. Conflicts can
> be a bad thing, they can lead to non-nonsensical or non-interactive
> reporting by ATs. I realize that, but I'd err on the side of allowing
> authors to make those decisions. They can use various tools that spit out
> warnings.
>
> Ian has stated that warnings aren't very useful, he's looking for error or
> bust. That's confusing when it comes to ARIA testing, as it's more about
> the pragmatic effects of applying semantics and using a variety of ATs to
> test them.
>
>
>  I don't believe it is appropriate for HTML to place restrictions on ARIA
>>> DOM. It's does not reflect implementations.
>>>
>>
>> It does not affect implementations at all.
>>
>
> Then I'm less concerned. My understanding was that this part of the
> specification is intended to affect implementations such that an authors
> use of @role in a tag would be overridden by the browser if that tag is on
> the conflict list.
>
>
>  The HTML spec should only specify what the default mappings are for HTML
>>> elements to ARIA.
>>> Authors may be advised to test AT software with their product.
>>>
>>> This statement is more in line with practice: "Authors must test
>>> accessibility tree as part of development and usage of ARIA semantics.".
>>>
>>
>> That's not machine checkable so less likely to have an effect at all.
>>
> So the "authors must" is for conformance tools? Again, it seems to be
> adding confusion. I'm not the only one.
>
> It looks like a good section explaining mapping to implementers that has
> been turned into a wiffle bat for bopping weary authors on the head.
>
> ARIA is a tool for supporting secondary UAs, not an extension to HTML
> Forms and groups. An aria role does absolutely nothing to alter the
> behavior of the primary UA.
>
> -Charles
>

Received on Tuesday, 13 March 2012 05:56:51 UTC