RE: summary of backward compat discussion

If you're building a tree with web-like behavior, tabbing would go through all the expanded items in the tree.  Enter on a node would toggle it open and closed.  For a tree that is long and/or expanded when the page loads (more than about 10 nodes open on page load), you would want a skip link.  

For an app-like tree, tab would go from widget to widget, and not go into the nodes of the tree at all.  

-----Original Message-----
From: Al Gilman [mailto:Alfred.S.Gilman@IEEE.org] 
Sent: Monday, September 22, 2008 11:21 AM
To: Cynthia Shelly
Cc: wai-xtech@w3.org
Subject: Re: summary of backward compat discussion


On 22 Sep 2008, at 1:19 PM, Cynthia Shelly wrote:

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

Are you saying that, in the 'both' tree in an ARIA-enabled browser  
that one tab would take you into the tree and the next tab would take  
you past the tree UNLESS the user hit ENTER or Right-arrow while the  
focus was on the place they first tabbed to?  Or would the tabbing  
sequence meander through all displayed tree items (all children of  
expanded tree items)?

Al
>
>

Received on Monday, 22 September 2008 18:26:08 UTC