>> >> 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. - AaronReceived on Friday, 7 March 2008 05:54:57 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:43 GMT