Hi Paul,
A few of us were recently discussing how to determine the proper
(default) key command to use for a particular interaction (e.g. moving
around in the date picker). This came up with Erin & I again when we
talked today with Mike Elledge about date picker accessibility. Daphne
reminded us that she thought you may have started working on a summary
document about this a while ago, but I couldn't find it on the wiki.
Is that out there somewhere that we could reference? I think something
like that (or even just a document summarizing our thinking if we
aren't making concrete recommendations for particular keys) would be a
great thing to put in the UX Toolkit.
Trying to make sense of the various resources I've found...
I'm wondering if we should just be following the guidelines in the
DHTML Style Guide Working Group's document: http://dev.aol.com/dhtml_style_guide
I think there's also a bit of info on this topic here:
http://www.w3.org/WAI/PF/aria-practices/#aria_ex
This possibly (tangentially?) related document was in an email Eli
sent out to fluid-work last month: http://unixpapa.com/js/key.html
And below is an email that Colin sent out about the Fluid approach to
keyboard bindings a while back.
Any advice other folks have for us on how to handle this would be very
helpful--thanks!
Allison
Begin forwarded message:
From: Colin Clark <[email protected]>
Date: March 20, 2008 2:45:54 PM PDT
To: fluid-work <[email protected]>
Subject: More on Fluid's approach to keyboard bindings
Hi all,
I have received a couple of questions off-list about how Fluid is
handling keyboard mappings for our components, and thought I'd try to
clarify our approach in the Reorderer and underlying framework.
Recently, Anastasia, Joseph, and Jonathan have been doing a lot of
testing and analysis to come up with some good, screen reader-friendly
default keyboard shortcuts for selecting and moving items with the
Reorderer. We think really good defaults are important, but we also
want to enable customizability. The Reorderer will support more than
one keyboard mapping, and will allow alternatives to be injected at
configuration time or dynamically in by a preferences editor.
Michelle and I are currently sketching out some Fluid framework code
that will provide a simple API for components to support customizable
keyboard mappings. This will prevent developers from having to
hardcode assumptions about keyboard controls, making components more
future-proof and interoperable. This approach is in line with our
general philosophy of allowing flexibility and customization for
different contexts and user needs.
With the help of Mike Elledge and Amy Chen at Oracle, we're also going
to do some quick, targeted user research to learn more about how users
of screen readers tend to accomplish tasks that are otherwise done
using mouse-based drag and drop. This will help us to continue to
refine our designs based on real feedback from users.
Colin
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
[email protected]
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
