W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2010

FW: accessibility experts - keyboard input

From: Jim Allan <jimallan@tsbvi.edu>
Date: Wed, 26 May 2010 17:19:37 -0500
To: "'UAWG list'" <w3c-wai-ua@w3.org>
Message-ID: <01df01cafd21$86eb8310$94c28930$@tsbvi.edu>
Something we should select a few people to review.
Jim

>From Rich Schwerdtfeger and X-Tech
Subject: accessibility experts 

An important feature of web browser today is the ability to navigate rich
content editable areas. This feature is standardized in HTML 5. IBM,
Mozilla, and other members of the open community have been working hard on
addressing keyboard navigation. Alex Surkov, Mozilla, is creating a document
for browser manufacturers to follow when a keyboard is being used.
He would like feedback from the community on that document which should
become a best practices guide for browser manufacturers. It would be
problematic if the keyboard navigation behavior was only employed in
Firefox.

IBM is working on the accessibility of rich content editable areas, to
support some of our products, with Mozilla and members of the AT community
so we have an immediate need to address this issue. However, I am sure that
others will be interested.

Alex's proposal consists of two parts. The one part concerns to behavior in
caret navigation mode
(https://wiki.mozilla.org/Accessibility/RichContentKeyboardBehaviour).

The second part is about editor behavior
(https://wiki.mozilla.org/Accessibility/EditorBehaviourOnUserInput),
the editor behavior doc is built upon the doc for caret navigation mode.

Highlights:

- put all elements (including form controls) into keyboard navigation
sequence.
- define ARIA role's affect on keyboard navigation. It allows ARIA widgets
to behave similar to native widgets so that ARIA widget authors shouldn't
care about caret navigation inside ARIA widgets bydefault (of course ARIA
widget author always is able to override behavior).
- wrap elements (like form controls, links) by special characters (called
empty characters in the proposal) so that the user is able to put the caret
before element, before first character of the element's content.

The editor doc suggests to have two modes defining the behavior of UI
controls inside an editable area. The first mode is to make controls working
as usual, the second mode is to make them a stub controls (so that the user
can't interact with them).

Alex is fine with posting comments on the mozilla wiki pages above or via
email. If we could all provide Alex Surkov feedback it would be much
appreciated. I am going through the documents now.

Alex, thank you for pulling this together!

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group
_______________________________________________
dev-accessibility mailing list
dev-accessibility@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-accessibility
Received on Wednesday, 26 May 2010 22:20:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 26 May 2010 22:20:31 GMT