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

Note that we discussed this some in the DHTML Style Guide meeting of 
September 21, 2007.  The discussion was about disabled menu items but 
buttons and toolbar buttons were briefly discussed as well.   Search for "
BG: action item changed:" in the minutes [1]. 
Since there is still discussion we should probably add focus of disabled 
items as an agenda item for an upcoming meeting. We need to determine the 
keyboard behavior for disabled form controls (combobox, textfield, 
buttons, etc), menu items, toolbar buttons, tab titles/panes, accordion 
title/pane, title panes, tree items, etc. There is already a precedent for 
form controls but  I think we need to look at all controls which can be 
disabled and determine the appropriate strategy.

[1] 
http://lists.w3.org/Archives/Public/www-archive/2007Sep/att-0065/dhtml-20070921.html
 
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/16/2008 12:39:41 PM:

> 
> 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:57:00 UTC