ARIA and default values for HTML elements

Which roles and properties should be assumed for given HTML elements
(and attributes?) and which of those assumptions can be overriden.

Examples:

<tr> should normally imply a role of "row", *unless* it is part of a
table with "childrenArePresentational".

On the other hand, <ol> should apparently not have the role of "list",
despite the names.

-jJ

---------- Forwarded message ----------
From: Aaron Leventhal <aaronlev@moonset.net>
Date: Mar 11, 2008 10:33 AM
Subject: Re: ARIA
To: Jim Jewett <jimjjewett@gmail.com>
Cc: whatwg@whatwg.org, James Graham <jg307@cam.ac.uk>


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@w3.org
 <mailto:public-pfwg-comments@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

Received on Wednesday, 19 March 2008 23:13:05 UTC