Keyboard accessibility: changing tab order

Colin Clark colinbdclark at gmail.com
Wed Jan 27 19:20:53 UTC 2010


Hey guys,

It's awesome to have your help and feedback. Reading through this thread, though, I think we might have a bit of confusion here about what Boyan is trying to accomplish here. Let's look at this issue a bit more in depth. Undoubtedly I'm pointing out the obvious on several issues here, but humour me. :)

First, any element can legitimately be given a tabindex attribute with any value from -1 to infinity. By default, only form elements and links are focusable with the Tab key automatically.

The ideal approach will have the order of the markup laid out in a logical fashion so that user interface elements are focusable in the order of most to least important. In practice, this can sometimes be difficult, but we should examine Decapod's markup to ensure that any changes to the tab order are indeed necessary.

Next, let's take a look at the wireframe for the Capture screen Boyan is referring to. Everett, since this is a picture, I'll try to describe it here.

http://wiki.fluidproject.org/display/fluid/0.5y+Deliverable+Wireframe

Along the left, we've got a column of image thumbnails. They're reorderable, and each have a button associated with them labelled "Delete," allowing the user to delete the page. Clicking or activating a thumbnail will cause it to be displayed in the main panel. This main panel takes up the majority of the screen and displays a larger image of the book page, along with a couple of buttons above the thumbnail for Fixing and Comparing images. Below all of this is a large, central button labelled "Take Picture."

So, let's go through the implementation of this for keyboard navigation. Keep in mind we've got two complimentary use cases: 1. a mouse-using scanner operator who wants to use keyboard navigation to reduce repetitive tasks, and 2. a user who may not be able to use the mouse and requires the keyboard to access all user interface elements or even to introspect them.

1. The Thumbnail Column

So first, the thumbnail list in the left column. These can be reordered using mouse drag and drop or the keyboard using the Reorderer component we're all familiar with. The left-hand column is treated as a "widget." Like on the desktop, the overall widget container is in the tab order, and each picture is focusable using the arrow keys.

There shouldn't be anything we need to do to make these thumbnails focusable with the arrow keys--it's handled automatically by the Reorderer. The one thing that isn't handled automatically by the Reorderer is making the thumbnails activatable using the Enter/Space keys. That should be done using the Infusion keyboard accessibility plugin:

http://wiki.fluidproject.org/display/fluid/Keyboard+Accessibility+Plugin+API

The difficult part is the "Delete" button for each image, which is visually placed inside the thumbnail's container. We could put this button into the tab order and require users to use the Tab key do "dive deeper" into a thumbnail container (as we do for reorderable portlets), but I think this is probably overly complex. I imagine we might like to have a keyboard shortcut attached to the thumbnail image, such as the Delete key, which will remove a page from the list. Assuming the thumbnail is labelled correctly, the "Delete" button needn't be focusable at all.

2. Everything else

All the other buttons should be links or button elements. These are focusable natively with the Tab key, and Enter/Space activation is handled by the browser automatically. If we're finding that buttons like the Capture button aren't responding to the Enter key, there's an error in our markup or our code.

The other question here, and I think it's largely a design issue, is if the "visual priority" of the screen corresponds to the logical priority. In other words, looking at the screen as it stands, I imagine the default tab order is something like this:

1. The thumbnail column
2. The "Fix Image" button
3. The "Compare Before/After" button
4. The "Take Picture" button

Jonathan, does that order correspond with your designerly sense of what are the most important aspects of the UI and the frequency of tasks in each area? Or is, for example, the "Take Picture" button actually the most important thing on the page? If the visual and logical order differ for good reasons, we can probably use CSS to layout the page differently from document order.

Colin


On 2010-01-27, at 1:11 PM, Armin Krauss wrote:

> Thanks Everett for helping me out here. I did not think of this and I am happy you brought it up.
> 
> Boyan, does this help you in any way?
> 
> Armin
> 
> 
> 
> On Wed, Jan 27, 2010 at 12:22, E.J. Zufelt <everett at zufelt.ca> wrote:
> Good morning,
> 
> I would add to this that it is not ideal to try to add focusability to an element that does not natively support focus.
> 
> HTH,
> Everett
> 
> Follow me on Twitter
> http://twitter.com/ezufelt
> 
> View my LinkedIn Profile
> http://www.linkedin.com/in/ezufelt
> 
> 
> 
> 
> On 27-Jan-10, at 11:55 AM, Armin Krauss wrote:
> 
>> Hi Boyan,
>> 
>> the best way to have a tab order and comply with WCAG easily is to have the content in a order that needs no tab order. This means that the content is structured and sorted in the way the tab order should flow. Then you don't need to override the tab order. As a byproduct the content has a structure that makes for an user with AT more sense.
>> 
>> See 1.3.2 and 2.1.1 among others on http://webaim.org/standards/wcag/checklist
>> 
>> Hope that helps a bit.
>> 
>> Armin
>> 
>> --
>> 
>> 
>> 
>> On Wed, Jan 27, 2010 at 07:12, Boyan Sheytanov <boyan.sheytanov at asteasolutions.com> wrote:
>> Hi all!
>> 
>> I was trying to force the following tab order of the elements in Capture for Decapod: thumbnail item, take picture button, fix, compare, export. Since the buttons are <a> elements, they were easily ordered (having assigned them positive values for 'tabindex'). However, they do not seem to respond to pressing the Enter key. Additionally, the thumbnail item is a <li> element and the only valid values for the tabindex property are -1 or 0 (correct me if I am wrong here). These make the element focusable or part of the default tab order but I cannot find a way to make it the first element of the tab order.
>> 
>> My question is what is the 'proper' way to modify tab order and enable keyboard navigation in accessible web applications.
>> 
>> Greetings,
>> 
>> Boyan
>> 
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
>> 
>> 
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://fluidproject.org/mailman/listinfo/fluid-work
> 
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org




More information about the fluid-work mailing list