Re: shift+tab behavior in tool bars

Please keep in mind that not all toolbars are managed-focus widgets. For example, many toolbars have segmented controls in them, like the [align left | justify | align right ] radio group that is common in most native word processors. This is the reason the ARIA spec does not require toolbars to be managed-focus widgets; it just would not work in all cases.

In the examples, please be sure to account for toolbars that contain more than just single-action buttons. Thanks.


On Mar 8, 2013, at 2:16 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> According to the WAI-ARIA practise - Tab moves focus to the first enabled button in a toolbar.
> 
> I am taking the below link as an example:
> 
> http://www.oaa-accessibility.org/examplep/toolbar1/
> 
> 1) Tab to first button in Text formatting controls under Text Sample 1
> 
> 2) Press right arrow key to reach the second button
> 
> 3) Press Tab, it will reach the first button in the Paragraph formatting control.
> 
> 4) Press shift + tab - the focus will move to the second button in Text formatting controls.
> 
> Is the 4th step expected behavior? Or should the first button receive focus by default on doing reverse tab?
> 
> The design pattern for toolbar does not provide advice on reverse tab order
> 
> -- 
> with regards
> 
> Steve Faulkner
>