WebAIM - Web Accessibility In Mind

E-mail List Archives

Keyboard use in editors

for

From: Alastair Campbell
Date: Mar 1, 2007 3:00AM


Hi everyone,

An interesting question came up with regards to keyboard usage in
browser-based editors:

What should the tab key do when you are editing?

As part of the editor checklist I'm developing, I had suggested that
when in a list, tab should create a nested list (like Word).

Vlad Alexander has kindly contributed, and one suggestion was that tab
should do what it usually does in web-forms and go to the next control:
http://alastairc.ac/2006/10/wysiwyg-editor-spec-adding-structure/#commen
t-12740

There are three primary situations I can see:
1. Visual user tries to use tab to create a nested list.
2. Keyboard reliant user, tries to use tab for moving from form field to
form field.
3. Screen reader user, who has a forms-mode (for most windows based
screen readers at least), and expects tab to move one tab space to the
right.

There is some conflict here, especially between 2 & 3, as the keyboard
behaviour is different when a user is in forms mode.

There nearest guideline I can find in ATAG 2 is A.2.1:
"The author must have the option to enable single-key access to both of
the following functionalities:
* (a) move content focus to the next enabled control in the editing
interface (e.g., using "tab" key), and
* (b) navigate forward and backward within editing views (e.g.,
using "arrow" keys)."
http://www.w3.org/TR/ATAG20/#check-tool-keyboard-access

But that doesn't necessarily apply when you have a forms-mode, and/or
you are in the editing area of the interface.

Should the WYSIWYG area of an editor be a special case for keyboard
usage? One of my assumptions previously
(http://alastairc.ac/2006/12/wysiwyg-editor-spec-interface-accessibility
/) was that it is a special case, and you need to provide a good
mechanism to get from the editing area to the controls.

Kind regards,

-Alastair

--
Alastair Campbell | Director of User Experience

Nomensa Email Disclaimer:
http://www.nomensa.com/email-disclaimer.html