Forum Moderators: open

Message Too Old, No Replies

WCAG AAA Status

Using the tabindex attribute

         

pageoneresults

6:23 pm on Jul 29, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



[w3.org...]

9.4 Create a logical tab order through links, form controls, and objects. [Priority 3]
For example, in HTML, specify tab order via the "tabindex" attribute or ensure a logical page design.

I've now found myself on a mission to gain WCAG AAA approved status and am running into some things that I don't quite understand.

I attempted to utilize the tabindex on links within a site. The problem I ran into is that the link structure changes depending on the page you are viewing. When that happens, the tabindex becomes incorrect.

So, I went back and removed all the tabindex attributes and found that the browser (IE) will automatically tab through links as they are presented on the page from top to bottom (already knew this). It also tabs its way right through form fields.

I am using accesskeys on important links and indicated those using a little bit of style and the <span class="u"> inline element.

Search (with a line under the S to indicate an accesskey).

.u{text-decoration:underline;color:#00a;background:#eee;font-weight:bold;}

This provides a visual clue as to what the accesskeys are. I've also set up an Access Key Bindings page where each accesskey is described and where it presents itself.

How important is it to utilize the tabindex attribute? Especially since browsers treat tabbing through links and forms the same. Without the tabindex attribute, the browser tabs through in a logical order. But, when validating the page against WCAG AAA guidelines, warnings come up indicating that the tabindex should be used. Is this absolutely mandatory or can I rely on the browser to present a logical tabbed index to users?

NickH

8:27 pm on Jul 29, 2003 (gmt 0)

10+ Year Member



My opinion is that one way to "create a logical tab order through links, form controls, and objects" is to lay out the page logically, and rely upon the browser's default order. Use of tabindex is therefore only required when the logical tab order departs from the default order.

Jim Thatcher barely mentions tabindex in his comprehensive "Constructing Accessible Web Sites".

Automatic validators are unable to verify that the tab order is logical, and therefore always suggest using tabindex. (Even though, in using it, you could detract from your page's usability.)

Beware that styling the active letter using span can cause some screen readers (eg. HPR) to speak, for example, "S" followed by "earch".

Nick

pageoneresults

8:46 pm on Jul 29, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



NickH, thanks for your reply. When I stripped out all of the tabindex attributes, I double checked to make sure that there was a logical tab order, and there is. It starts at top and tabs to every link, then any form elements, and then any links below those. It is definitely logical due to the layout.

Beware that styling the active letter using span can cause some screen readers (eg. HPR) to speak, for example, "S" followed by "earch".

There was another topic recently discussing this. Is there any way to work around this using a technique that works in most browsers? Apparently there are some issues with the first-letter pseudo element [w3.org]. I haven't tested that one yet based on the other discussions.

Also, I've got some Access Keys that are not the first letter of the link so the first-letter would not work in this instance.

pageoneresults

12:50 am on Jul 30, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I believe I've figured out a temporary solution to deal with the <span> issue and screen readers. What I've done now is removed the <span> element and have set up a <kbd> tag that appears in front of all accesskeys. I've styled the <kbd> to appear as it does on your keyboard (very nice effect). Anyway, I was able to eliminate all styling from the links and position the Access Key letters/numerals in front of their resource wrapped inside <kbd></kbd>.

Here is the CSS...

kbd{
font-size:.8em;
font-weight:bold;
text-decoration:underline;
border-top:.15em solid #ccc;
border-right:.25em solid #aaa;
border-bottom:.3em solid #888;
border-left:.2em solid #bbb;
padding:.05em .2em;
color:#000;
background:#eee;
cursor:help;
}

And then I have my Access Keys wrapped in the <kbd> tag and have assigned a title attribute indicating that it is an Access Key hint...

<kbd title="Access Key">A</kbd>

Possible solution if you have the leeway with design. You need to accomodate the <kbd> attributes and add in line-height, etc. to other elements to make it all work.

g1smd

8:38 pm on Jul 31, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Very interesting topic. I'm going to be trying some of these things out shortly.

Thanks for the pointers and the initial research and experimentation done so far.

BlobFisk

9:30 am on Aug 1, 2003 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Sorry to get to this one late!

Great tips pageoneresults! To be honest, much of the time, I only use tab index's on form pages. As long as your links appear in the html in logical order, then the browser will assign the correct order to elements.

The AAA rating still applies, even with this warning. In testing (with users with visual difficulties), pages with unassigned tab index's do fine, as long as the html (and the links) are in logical order.