[whatwg] Validator.nu: "Attribute role not allowed on element h2 at this point."
Charles Pritchard
chuck at jumis.com
Tue Mar 13 00:11:38 PDT 2012
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
More information about the whatwg
mailing list