DHTML Style Guide - proposed behavior for Rich Text Editor

My action item from the January 8, 2008 DHTML Style Guide meeting was to 
write up the behaviors for a Rich Text Editor Widget.


The edit control is provided by the browser. The edit control provides the 
keyboard support for navigating, adding, removing and selecting text so 
that behavior is not defined by the DHTML Style Guide.  The browser should 
also provide a keyboard mechanism for navigating into and out of the edit 
control.    Within Internet Explorer the edit control is put into the tab 
order of the page and can be navigated into, out of, and through using the 
tab and shift-tab keys like any standard form control.   Firefox also puts 
the edit control into the tab order.  However, Firefox has actually 
implemented tab as an action within the edit control so currently there is 
no keyboard way to navigate out of the editor component once focus has 
been placed inside of it. 

A rich text editor widget needs to provide a user interface for 
interacting with the browser provided edit control.  Interaction between 
the user interface and editor is defined here assuming that a toolbar is 
used. 
If not provided by the browser, the rich text editor widget must provide a 
keyboard mechanism to move into and out of the edit control.  Tab and 
shift-tab are the recommended keystrokes. This additional implementation 
is necessary for Firefox until Firefox provides an alternative keyboard 
mechanism to navigate out of the edit control.
The toolbar or other user interface component associated with the editor 
is placed in the tab order immediately before the editor.
To set an attribute on text within the edit control the user sets focus 
into the edit control, moves the insertion point, selects text and presses 
shift-tab to move focus from the editor back to the toolbar.  The user 
navigates through the toolbar (see toolbar behavior) to a desired 
attribute and invokes that attribute. 
When an attribute is invoked, that attribute is applied to the selected 
text in the editor and focus moves back into the editor at the previous 
insertion point with the selection intact. 

Options: 
Rather than using shift-tab to move focus from within the editor to the 
toolbar, another key combination could be used (alt-up arrow, 
ctrl-shift-letter, etc.).  This would eliminate the need to put the user 
interface control, in this example a toolbar, into the tab order 
immediately before the editor component.  However, there are drawbacks to 
using a different keystroke to navigate to the user interface: 1) it is 
not as "discoverable" as relying on the standard tab/shift-tab behavior; 
2) it is difficult to find key combinations which are not already captured 
by the browser or assistive technology. 
Focus could stay within the toolbar after the user invokes an attribute. 
The user would then have to press an additional key to move focus back 
into the editor.  This would allow multiple attributes to be set on the 
current selection without having to return back to the user interface but 
it would add an extra key sequence after setting just a single attribute.  
 Requiring a keystroke to move focus back into the editor would also 
require modifying the toolbar behavior to intercept this keystroke and to 
know how to set focus back to the component (the editor) that the toolbar 
is associated with. 




Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com
blog: WebA11y

Received on Wednesday, 9 January 2008 20:17:57 UTC