Accessible DHTML Widget > Picking on the datepicker

Accessible DHTML Widget > Picking on the datepicker


Hi,
I'm one of many developers on Sakai, a large Learning Management
System (LMS) in use by a number of institutions. I am also one of a
few developers on Fluid, a project focusing on usability in Sakai and
a number of other community source projects. In Fluid and Sakai, we're
increasingly using jQuery in our development, for all the same and
wonderful reasons that other developers use jQuery.
I'm very excited by the work being done in the jQuery UI library but
I'm concerned with your approach for adding keyboard accessibility.
I'm going to pick on the datepicker because I'm more familiar with it
than some of the other parts of jQuery.UI and because it's great piece
of functionality. But my comments apply to any DHTML widget.
I don't know if this has been discussed on this forum or not, but
there are two approaches to keyboard accessibility. One is to use
accelerator (aka. access) keys, as you've done for the jQuery.UI
datepicker. The other is to factor the widget so that all the
clickable elements can accept focus and once focused can be activated
with the enter or spacebar keys.
Accelerator keys are seductive because they seem more direct and
immediate than forcing the user to tab through a set of controls to
move the focus, but they have some serious downsides as well:
1) Any component on the page may also want to use the same accelerator
key. (Compounded for folks who use adaptive accessibility devices or
software such as screenreaders that frequently co-opt those same
keys.)
2) It is difficult to communicate to the user which accelerator keys
go with which action. I would never have known that you could use
pageup and pagedown to change months in the datepicker widget, except
that I read the documentation.
Using the focus and select approach, while it is not as direct,
leverages the skills that users, especially disabled users, already
use to navigate and manipulate web pages. All web browsers enable the
user to tab between links and form elements. (Some browsers have this
on by default, for others you must turn it on.) Keyboard users already
expect to use the tab key to get around.
Additionally setting focus to a specific actionable element will
trigger screenreaders to *speak* the element though the element may
need additional markup to make it readable, alt text or a title
attribute. (Or if you're really ambitious, ARIA markup.) Cycling
through actionable elements gives non-sighted or partially-sighted
users a way to quickly scan through the functionality of the widget.
[Setting of focus is done alternately with the tab and arrow keys. The
exact semantics of when to use the tab key or arrow key is covered in
the DHTML Developer Checklist sited below.]
I know that this is a rather long rant. If you've read this far,
thanks.
I don't mean to put myself out as an expert on accessibility, these
are just the things that I've learned while working on Fluid. As part
of Fluid we are working on some jQuery plugins to make it easier to
write keyboard handlers and set focus. We hope to be sharing those
with the greater jQuery community soon.
- Eli Cochran
user experience developer
Educational Technology Services, UC Berkeley (ets.berkeley.edu)
The Fluid Project (fluidproject.org)
References:
Key-navigable custom DHTML widgets (Mozilla Developer Center)
http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets
DHTML Developer Checklist (The Fluid Project) [disclaimer: I am an
active developer on Fluid]
http://wiki.fluidproject.org/display/fluid/DHTML+Developer+Checklist