Re: shift+tab behavior in tool bars

+1
Makes sense to put focus back where I was when I left the first group to 
maintain my sense of place.
As an aside, seems like second group should be exposed as radio buttons 
as they are mutually exclusive. This is how we did it for the NoRepeat, 
Once, All controls on the sample media player buttons in jQueryUI:

http://access.aol.com/aegis/#goto_button

CB

On 3/8/13 10:07 AM, Sailesh Panchang wrote:
> Steve,
> Font: Larger / Smaller / Italics / Bold
> Alignment: Right / Justified / Left / Centre
> So there are two groups ... this is not apparent to me. I figured it
> out by the wording and that arrow keys cycled around.
> Answer to your question:
> Well if I tabbed to second group when my focus was on 'Small font' and
> arrowed around and shift-tabbed back, my expectation is that my focus
> will be on 'Small font' button in group#1. It will be confusing if it
> landed on 'Large font'
> The working now is fine expect for observation above about  grouping
> not being clear.
> Sailesh Panchang
>
>
> On 3/8/13, 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
>>
>> <http://www.paciellogroup.com/resources/wat-ie-about.html>
>>

-- 
¯\_(ツ)_/¯

Received on Friday, 8 March 2013 16:12:45 UTC