- From: Jon Gunderson <jongund@uiuc.edu>
- Date: Wed, 16 Jan 2008 10:11:28 -0600 (CST)
- To: Becky Gibson <Becky_Gibson@notesdev.ibm.com>, wai-xtech@w3.org
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 16:11:51 UTC