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

I have updated Menu in the DHTML Style Guide to read as follows:

"Disabled menu items receive focus but have no action when enter or
left/right arrow is pressed. It is important that the state of the
button be clearly communicated to the user."

Thanks for your input...

---don
 

-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Victor Tsaran
Sent: Tuesday, February 19, 2008 7:48 PM
To: 'Becky Gibson'; wai-xtech@w3.org
Subject: RE: DHTML Style Guide - proposed behavior for Rich Text Editor


Hi Becky,
Sorry for jumping into this so late.
We are redesigning the rich-text editor for the Yahoo! User Interface
library and I wanted to bring some of our experiences to the table.
 See my comments below.



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.

Agreed.


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.  

This is slightly incorrect as on the Mac all buttons and menus receive
focus when assistive technology is running, however, they do not if AT
is not active.

I, therefore, suggest that by default all buttons should receive the
focus, but their state should be clearly communicated (disabled, grayed
out etc).
The user needs to know if a particular control is inactive so they can
figure out the reason for this, e.g. the user meant to select the text
for bolding but they have not done so, thus the BOLD button is disabled
to show that this action canno be performed.


I don't know of any keyboard navigable toolbars in Windows applications.

For examples see any of the mainstream toolbars, such as AOL toolbar,
Google toolbar and Yahoo! toolbar. Also, MS office applications have
very keyboard-friendly toolbars.


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? 

Do you mean split buttons? again, see Yahoo! toolbar for examples. We
have settled on SPACE bar activating default action while down arrow
activating context menu.
MSAA has a role of SPLITBUTTON while ARIA does not.
I have been arguing about this before so don't want to resurrect these
discussions here.

Regards,
Victor


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
> 
> 
> 
> 
>

Received on Monday, 3 March 2008 18:29:11 UTC