[whatwg] ARIA

[Aaron Leventhal]

Jim Jewett wrote:
> I think the question is more about how the HTML elements themselves 
> interact.
> For example,<tr>  elements should probably be interpreted by default
> as<tr aria-role="row">  because that is part of the semantics of tr.
>
> In some cases, the default mapping will also depend on other
> attributes.  (<input type=checkbox>  vs<input type=reset>)
>
> Ideally the specification would give a complete list of such defaults,
> because otherwise there will be at least a few disagreements.  For
> example, it looks as though<ol>  should *not* have aria-role=list, but
> that isn't something I would have guessed from the names.
>    
In general these are great questions. The question as I understand it, 
should the spec spell out which role & properties you get naturally with 
an HTML element, so an author knows if they even need to override them 
with ARIA in the first place?

Do you mind asking this question on the wai-xtech list/ You can get 
subscribed to on an individual request basis -- just email me and I'll 
help you get on it. If you don't want to spend a lot of time, then 
please at least send your feedback to public-pfwg-comments at w3.org 
<mailto:public-pfwg-comments at w3.org?Subject=Comment%20on%20WAI-ARIA%20Role>

> The next question is what to do when an author explicitly uses an aria
> attribute other than the default.  For example, it is fairly common to
> hook javascript to a checkbox so that it acts like a command button.
> Therefore
>
> <input type=checkbox aria-role=button>
>
> should probably be treated as having both roles, but
> aria-role=presentation (or even a parent with
> aria-role=childrenArePresentational) should probably remove the
> default aria-roles
>    
This one is simpler. ARIA properties override the built-in semantics. 
You can use |role| on any element, such as <input> and it will override 
the natural role of the element. Therefore <input type="checkbox" 
role="button"> will be reported to assistive technologies as a button. 
The same thing applies to properties. ARIA properties have the last say 
when they conflict with the natural properties of an element. Overriding 
one property with ARIA does not affect the other properties on an 
element. These simple rules were found to be the most effective. There 
are a lot of sensible concerns. I've drafted a FAQ here with some more 
info, which I think addresses most concerns: 
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ
A Best Practices Guide and Primer are under development for authors. I 
am also working an implementors guide for user agents. Let me know if 
you want to see that.

As aside: I noticed you refer to role as aria-role. The role attribute 
is the one ARIA attribute that doesn't need "aria-" as a prefix. It's a 
special attribute that is intended to address more than accessibility -- 
it's been argued already and unlikely to change because of currently 
shipping software.

- Aaron