Re: Keyboard issue

Here's what I have for now. Hope this is useful:


  Accessible custom widgets


    The problem: today's web applications lack accessibility

An increasing number of web applications are utilizing JavaScript to 
mimic desktop widgets like menus, tree views, rich text fields and tab 
panels. Web developers are constantly innovating, and future 
applications will contain complex, interactive elements such as 
spreadsheets, calendars, organizational charts and beyond. Until now, 
web developers who want to make their styled |<div>|, <|span> and <td> 
|based widgets keyboard accessible have lacked the proper techniques.

One part of the equation, semantics for custom widgets, is already being 
addressed by XHTML 2. Web developers need the ability to specify a role, 
value and states for any element. XHTML 2 is well on its way with the 
use of the role attributes and the ability to bind a data element to any 
element, ala XForms.


    Grouped Keyboard Navigation (the missing piece)

Authors need the ability to provide keyboard accessibility that goes 
beyond putting everything in a single long navigation cycle (via the TAB 
key on today's desktop UA's) Here's a real example from today's desktop 
user agents. Most DHTML menu bars don't act like regular menus with 
respect to keyboard access. If you can use the keyboard to get to the 
menu at all, a common mistake is to put each menu item in the main 
navigation cycle (often accomplished by making each menu item an |<a>|). 
In fact, the typical behavior for desktop application menus is that the 
entire menu is in the TAB cycle once, and from there arrow key 
navigation is supported. This also true for other "grouped navigation" 
widgets such as tree views, spreadsheets, lists, radio groups, tab 
panels. In fact the HTML <select> widget supports grouped navigation 
automatically, and some user agents support grouped navigation for 
groups of radio buttons with the same name. However, these are just 
examples -- once inside a container widget, the author should be allowed 
to decide what keys move focus within that, which means they need to be 
able to focus elements that are not in the main navigation cycle.

The cost of not having the capaibility to support grouped navigation is 
twofold:
1. Cluttered main navigation cycle: imagine a menubar with 100 items or 
a spreadsheet with 900 items in it. The user would have to move through 
each item before geting beyond the menubar or spreadsheet. Even 50 items 
are too many to move/tab through (i.e. a list of the 50 states of the 
United States).
2. Lack of usability and familiarity: if the custom elements are going 
to be tagged with semantics that suggest similarity to desktop widgets 
of the same name, then there should be at least a method enabling 
authors to mimic keyboard navigation for the known concept we're 
relating to. Just as a checkbox in web content can operate like a 
checkbox in a typical desktop application, it should at least be 
possible to make a menubar work similar to a typical desktop application.


    The Solution: Make the Set of Focusable Elements a Superset of the
    Main Navigation Cycle

This concept is supported in some of today's user agents via a 
nonstandard extension to HTML, which changes the meaning of tabindex. 
Mozilla follows IE's lead by extending the tabindex attribute to allow 
any element's focusability to be altered. By following the IE system for 
tabindex 
<http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/tabindex.asp> 
we're allowing DHTML widgets which are already keyboard accessible in IE 
to also be keyboard accessible in Mozilla. The rules have had to be bent 
in order to allow authors to make custom widgets keyboard accessible. 
The advantage of using the nonstandard solution is that can be used with 
the majority of today's user agents.

For XHTML 2 we need a standard-based solution that allows for grouped 
navigation widgets. An author must be allowed to focus() some elements, 
including a menuitem, treeitem or spreadsheet cell that are not 
necessarily in the main navigation cycle. How does XHTML 2 allow 
elements to be focusable but not in the tab cycle? Are elements that are 
bound to data in the focusable /and/ in the tab cycle by default? If an 
element cannot be focused, then a screen reader or other assistive 
technology cannot track the user's currently location.

Note: assistive technologies such as voice input and onscreen keyboards 
need to know what elements are focusable, so that user interface 
introspection is possible, allowing the user to make choices based on 
what is available. Currently the "focusable" state would include 
everything bound to data, correct? That sounds okay.

The author needs to be allowed to focus custom children of custom 
container widgets, receive key input events, and move focus to the next 
element as is appropriate for the author's navigation model. If 
everything that can receive focus (has data) is also in by default the 
main navigation cycle, that create a navigation order that is too 
cluttered. Will removing things from the main navigation cycle require 
the use of prevfocus and nextfocus on all elements in the document that 
the author wants to be in the main navigation cycle? That is much more 
expernsive than just allow the author to specify a boolean for whether 
something is in the main navigation cycle (or what is removed).

For some desktop container widgets, navigation among the child widgets 
might for example involve arrow keys, and in others it may not. There is 
no simple equation. For example, while the left/right arrow move 
spatially in a desktop spreadsheet, in a tree view they may 
collapse/expand or move to the parent or first child. Multiple 
discontiguous selection is another crucial desktop widget feature -- one 
model for that is the use of shift/control-arrow and 
shift/control-spacebar.  Other widgets may enable the use of navigation 
by pressing the first character in the label for the desired child widget.

Received on Friday, 18 February 2005 20:20:53 UTC