Re: background on ARIA overrides

On Thu, 17 Dec 2009, Cynthia Shelly 
> 
> 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.

Agreed with everything above.


> <div> was originally a section of a document

Technically <div> originally just meant "division", not "section". Its 
meaning hasn't changed since HTML3.x.


> 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.

I agree, to a point. I don't think it would be a good use of ARIA to, 
e.g., turn a <p> into a heading, though. That would be like adding a curb 
cut to a freeway median. Sure, in one sense, it's improving accessibility 
(in the case of the analogy, to people with wheelchairs; in the case of 
ARIA, to people with ATs). However, if the designers cares about doing the 
right thing (in the analogy, if they ask for permission from the road 
authority; in the ARIA case, if they ask a validator to check their work) 
then they need advice that leads them to doing something that's far less 
fundamentally wrong.

Now, if they don't care about doing the right thing, then the conformance 
requirements are irrelevant, since they're not going to be using a 
validator. So I posit that we should, in designing the conformance 
requirements, only be considering those authors who care enough to find 
out what the right thing is.


> However, the opposite, turning a button into a heading, really doesn't 
> make sense.

I disagree that turning a button into a heading makes any less sense than 
turning a heading into a button.


> 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.

Agreed.


> 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

The approach seems fine in principle. I think the devil is in the details.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 17 December 2009 17:19:56 UTC