RE: DHTML Style Guide - proposed behavior for Rich Text Editor

It's a paradigm that is used in Mac OS, i.e. disabled controls are taken out
of keyboard control, however, when VoiceOver is turned on, they are given
keyboard access as well.
I will argue though that keyboard access to all controls should be there at
all times.
Victor

-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf
Of Jon Gunderson
Sent: Wednesday, January 16, 2008 8:11 AM
To: Becky Gibson; wai-xtech@w3.org
Subject: RE: DHTML Style Guide - proposed behavior for Rich Text Editor


Becky,

Isn't it important for speech users to know about disabled controls in a
Toolbar.  If disabled controls are taken out of the keyboard navigation, how
will screen reader user know they are there?

Jon


---- Original message ----
>Date: Tue, 15 Jan 2008 11:43:09 -0500
>From: "Becky Gibson" <Becky_Gibson@notesdev.ibm.com>
>Subject: RE: DHTML Style Guide - proposed behavior for Rich Text Editor
>To: wai-xtech@w3.org
>
>
>wai-xtech-request@w3.org wrote on 01/09/2008 03:26:09 PM:
>
>> 
>> Hi Becky,
>> Also the toolbar could use the only tab stop and then left and right
>arrows
>> could be used to navigate toolbar controls.
>> Victor
>> 
>Yes, I thought we had discussed the toolbar behavior so I didn't 
>provide the details here.  However, I don't see anything in the Style Guide
>document so we should add toolbar to the list.   I know the group 
>discussed arrow key navigation through the toolbar and whether or not 
>disabled toolbar items should receive focus.  Somehow that didn't get 
>written up.
>
>Here is a quick summary of what I remember from the discussion:
>The first enabled toolbar button is in the tab order of the page. In 
>left to right languages this button will be the first enabled toolbar 
>button starting from the left.
>With focus on a toolbar button left and right arrow keys navigate to 
>the enabled buttons in the toolbar.
>Disabled toolbar buttons are not in the navigation and do not receive 
>focus.  This mimics the behavior of toolbars on the Mac.  I don't know 
>of any keyboard navigable toolbars in Windows applications.
>There still needs to be discussion of the behavior of controls such as 
>comboboxes, dropdown menus and combobuttons included in toolbars. For 
>example, combobuttons currently have two tab stops - one for the 
>default action of the button and one for the dropdown portion of the 
>button, how should this be handled when the combobutton is in a toolbar?
>
>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
>
>
>wai-xtech-request@w3.org wrote on 01/09/2008 03:26:09 PM:
>
>> 
>> Hi Becky,
>> Also the toolbar could use the only tab stop and then left and right
>arrows
>> could be used to navigate toolbar controls.
>> Victor
>> 
>> 
>> -----Original Message-----
>> From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
>Behalf
>> Of Becky Gibson
>> Sent: Wednesday, January 09, 2008 12:18 PM
>> To: wai-xtech@w3.org
>> Subject: 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
>> 
>> 
>> 
>> 
>> 
>
>
>
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility Disability Resources and
Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821

Voice: (217) 244-5870

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

Received on Wednesday, 16 January 2008 17:40:26 UTC