[whatwg] ARIA

>>
>> ARIA doesn't really overlap with HTML, because ARIA only reports what 
>> a JS developer is using elements for.
>> So ARIA semantics should not affect  behavior. Any code for dealing 
>> with ARIA markup should be strictly in the accessibility API support 
>> code (MSAA/IAccessible2/ATK/AT-SPI/UI Automation/Universal Access).
>
> This seems like a poor idea from the point of view of authors actually 
> using the markup correctly as they will have to use special 
> accessibility-API aware tools to inspect the effects of their aria-* 
> markup.
We've addressed most design concerns like this (which are generally 
legitimate concerns) in the ARIA FAQ.
http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ

The goal was to have apps that still work normally in legacy browsers. 
This means all the code to implement widgets needs to be in the JS of 
the page.

On the other hand for the "landmark" roles which specify semantics but 
not behavior, I would agree that sticking with HTML elements is a better 
approach. Even if there is associated behavior for them, such as a 
hotkey, they will degrade well to older user agents.

- Aaron

Received on Friday, 7 March 2008 05:54:57 UTC