Forum Moderators: open
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?
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
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.
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.
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.