navigation in trees [was: Re: summary of backward compat discussion]

Reference:
http://www.w3.org/WAI/PF/Group/track/issues/56

[please continue this discussion on the list until the F2F]

** summary:

I want to re-assert my suggestion of a SHOULD not MUST in
the specification.

While the Group may feel that ARIA trees exhibiting
arrow-navigation-only (internally) is better, this
makes this a Best Practice.  But not necessarily a
specification MUST.

Because tab-navigation-plus-skip-links-on-long-list
delivers all the required functionality, it also qualifies
as a Sufficient Technique for WCAG2.  And it is better
for some users and some down-level user software.

In this case, where one approach is superior on some
evaluation factors and another superior on others,
while both pass minimum requirements, it seems
appropriate to me to:

a) limit the specification to a SHOULD favoring the
Best Practice approach, not a MUST.

b) publish the arrow-navigation-only version in the BPG

c) publish the tab-navigation-plus-skip-links-on-long-list
version as a WCAG2 Sufficient Technique in the WCAG2 Techniques.

d) cross-link the documents.  WCAG2 Techs mentions BPG
approach with a hyperlink and vice versa.

Al

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

>
> 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 Sunday, 5 October 2008 14:50:00 UTC