RE: summary of backward compat discussion

The "both" tree would have the web-like tabbing behavior, and the app-like arrow key behavior.  So, yes, all open nodes would get a tab stop.  In cases where there would be more than about 10 open nodes on page load, you would want to add a skip-nav feature.  

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


On 22 Sep 2008, at 2:25 PM, Cynthia Shelly wrote:

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

I asked about the 'both' behavior.

You introduced the idea of a tree that responds to either
set of keystrokes.  Not either/or or switch-on-browser-sniffing.

How would a 'both' tree respond to TAB TAB TAB?
Does it need a skip-link?  Something like...

??
TAB puts you on 1st tree node
TAB puts you on skip link, where
  - ENTER puts you on first tab stop after tree
  - TAB puts you on next visible tree node
??

Al
>
> -----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 19:00:20 UTC