08 September 2006

Tabindex order accessibility issues

I released a new version of the Space Browse viewer yesterday. This was a major update because it made the viewer more accessible to keyboard users. However there are some unresolved issues... so any help appreciated.

The viewer has various tool button images used for navigation etc, as can be seen on the right in the "Space Browse widget". The previous viewer version used DIV HTML elements with onclick handlers added. The new version uses INPUT TYPE="image" elements (with onclick handlers) that let users use the tab key to move between focus elements on the page, thereby hopefully improving accessibility.

The new viewer INPUT elements all have TABINDEX attributes to set the order of the controls. For the viewer I started the TABINDEX values at 200. This helps the overall page layout:
  • Master page header: tabindex values start at 1
  • Page before viewer: tabindex values start at 100
  • Viewer: tabindex values start at 200
  • Page after header: tabindex values start at 300
  • Master page footer: tabindex values start at 400


I had to be careful with the INPUT image element borders. Originally I had border:1px solid gray;. However this did not work well in IE because it shows the element with the focus by giving it a gray dashed 1px border - this did not show up. So I used other colours.

Issue 1: tab order of elements added in JavaScript
My new viewer code adds some INPUT elements in JavaScript after the static elements have loaded. These added INPUT elements do have TABINDEX values in the correct order. However browsers do not respect these values - instead the elements are treated as if they had no TABINDEX, ie the user tabs to them after all the items that do have a TABINDEX. Tested in IE6, FF1.5 and O9 in Windows XP.

Issue 2: IE added elements invocation
Once you have tabbed to aan element in Internet Explorer you can press either Space or Enter to "click" it. When I added INPUT elements in JavaScript I saw a weird bug. If you use Space then the correct element is "clicked". However, if you use Enter then the wrong element is "clicked", ie the first added element is always "clicked". Tested in IE6 in Windows XP.

This is the code that I use:
fInput["onclick"] = function() { return space_gotoFrame(this.alt,true,null); }
where fInput is the INPUT element. When clicked, this.alt should be the filename of the photo to go to.

Issue 3: Opera tabbing
If appropriate, the viewer removes various INPUT elements by setting display:none;. In Opera 9 in Windows XP this caused problems with the tab order: Opera does not skip such elements, instead it goes back to the start of the page and so does not let you tab to all page elements.

Regards other browsers: FireFox was best at tabbing because the focus element stayed the same after a "click" even if the element was disabled. Interner Explorer always loses the focus element if it is disabled.

Later: ASP.NET asp:TreeView TabIndex
The ASP.NET asp:TreeView server control has a TabIndex property. However it does not implement it very well. The TreeView is implemented as a DIV with tables inside. The DIV is given the specified TabIndex; however the links inside are not, so those links appear at the wrong place in the tab order

No comments: