summary of backward compat discussion

Two issues:

1)      Graceful degradation
This one is less controversial, so I'll start with it.  The idea here is to create widgets that degrade gracefully to browsers and AT that do support script, but don't support ARIA.  Essentially, this is supporting the state of the world for real users from 2004 or so to sometime in 2009, when the first ARIA browsers and AT will be readily available (I'm guessing on the dates a little, but you get the idea).  It is reasonable to assume that for at least a year, and probably closer to 3 years, there will be significant numbers of users who have browsers and AT in this category.  This would include IE6 and 7, Firefox 2 and earlier (though some ARIA works in 2, quite a bit doesn't), JAWS 7-9, and a lot of other AT products.

Some UI widgets are very difficult to do without ARIA (spreadsheet grids and chat windows come to mind, but there are others).  Other widgets (menus, trees, dialogs, a few others), though, can be made quite accessible and quite usable to these users by modeling them in closest-match HTML semantics and being careful with script events and triggers.

For the widgets that we know how to make accessible without ARIA, it should be possible to build them that way, and then add ARIA markup to improve the experience for the users who have ARIA.  It should be possible to accomplish this in markup, without having to resort to user agent sniffing.  I'm working on several examples for the test cases and best practices that work like this.  I have run into a few things that might require minor changes to the spec, but not too many, and they seem relatively minor so far.  I'm hoping to sit down with a small group at the face to face and geek through this.


2)      Web-like behavior vs. application-like behavior

Web-page behavior would be tabbing to each element and hitting enter to open it.  Application behavior would be tabbing between widgets and using arrows and shortcut keys to navigate within a widget.  Both would be controls that react to both tab+enter navigation and arrow key navigation.

Should widgets support web-page like behavior, application-like behavior or both?  Which will be more usable for AT users?  Keyboard users?  Mouse users?  I suspect that the answer to this is scenario-dependant.  The menu on a news article may have different user expectations and requirements than the menu on a web mail app.  I'd love to see some usability research on this.  In the meantime, however, I think it's reasonable to build samples of both types, to make sure that the markup as spec'd can handle both.