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
