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

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 00:11:38 UTC