background on ARIA overrides

Last week, I was asked to write up some background information for the discussion on when and if ARIA should override native HTML semantics.  If I've missed anything, feel free to add it.

ARIA was designed as a patching technology, to fill in the holes in accessibility presented by HTML.  While HTML 5 has more semantic elements than prior versions, it does not have all the roles of ARIA.  There is a large body of existing content built using elements with no semantics (<div>, <span>), and ARIA can be used to add accessibility to this content relatively cheaply.

Developers are using script and css to change the semantics of existing elements.  ARIA allows them, or those who come after them, to inform accessibility technology about those semantic changes.  ARIA was always intended as a patching technology, to allow overriding of incorrect or incomplete semantics in the markup.  This is most obvious when the developer has used elements with no native semantics or behavior (<div> and <span>).

However, developers sometimes use elements that do have native semantics.  In fact, this is considered a best practice, in order to make content work in the widest range of browsers with the widest range of assistive technology, including those without ARIA support.  If you are building a piece of UI that behaves, for the most part, like a button, it makes sense to start with a <button> and then layer additional functionality on top of that.  Developers need to be able to override native semantics in these cases.  HTML 5 has native semantics for most of the common UI widgets of today.  But, there will be new widgets next year and the year after.  Developers need a way to mark those up so that assistive technology will understand them.

Native semantics are better, when they're available.  Pretty-close native semantics are better than none at all, so we encourage authors to use them, and then layer ARIA on top to improve the behavior for browsers that support it.  To this end, we want to define sets of related roles, that can override each other.  We haven't finished defining the groups, but we have some initial divisions.

The first is the division between document structure roles and widget roles. Document structure roles deal with, well, document semantics:  Things like paragraphs and headings.  They might also include landmark roles, like navigation, headers and footers.  These roles have no native behavior.  Widget roles deal with interactive elements, including links, form elements, and the new interactive elements in HTML 5 (menu, details, etc).  These elements have native behavior.

One of the most common use cases for ARIA is to turn something that was originally a document role into a widget role. DHTML can be used to make anything active, and ARIA is used to convey the fact of this to AT.  This is due to the history of HTML as a document language repurposed for UI.  <div> was originally a section of a document, but since it had no behavior (other than block rendering) it was widely repurposed with script and CSS.  ARIA is added to fix this, by exposing the behavior from the script to the accessibility API.  The same can be done with <h2> or <p> or any other non-interactive element.  We feel that document structure elements should be over-rideable with ARIA, and that this should not be treated as a validation error or warning.  Again, this sort of repurposing is one of the primary use cases of ARIA.

However, the opposite, turning a button into a heading, really doesn't make sense.  We feel that any attempt to do that should be a validation warning.  We also feel that browsers should go ahead and honor it, and not have any special code for dealing with author errors regarding ARIA.

That brings us to widget roles.  The direction we decided on at TPAC, which everyone in the room liked, was to define groups of widgets that make sense together, and allow those to override each other.  We haven't finished this task, but you can see the beginnings of it in this spreadsheet. [1]  We're starting by going down the list of elements and deciding what roles make sense to us.  From there, we'll define a small set of groups. We're also looking at the ARIA class relationships for clues here.

The people in the room at TPAC liked this approach, and we'd like to continue on this path to see where it goes.  Does anyone have strong objections to this approach?

[1]  http://spreadsheets.google.com/pub?key=toQHOF3-IiYACgHX9bs2GrA&single=true&gid=0&output=html