I try to think about Accessibility as much as possible.  Okay, not just “think about” it, but actually “be conscious” of it, as in “actually implement” it, as much as I know how.

So, sitting in an Accessibility session at SXSW 2010, I got to thinking about my lab-site, and thinking how well keyboard would work with the way I have the page structured.  Turns out, not well at all.

In my layout, the three main sections themselves sort of serve as the navigation, where each section’s header was the link to “reveal” that section’s content.

My first issue was that I was attaching a click event to the <h3> tags, rather than adding <a> tags since.  I think my initial thinking was justified, since without JavaScript, the page displays all three sections side-by-side, so no real navigation is required; if JavaScript is present, it hides two panels and makes the third larger.  But, if you were tabbing your way through the page, you could never get to the <h3> clicks, since an <h3> does not receive tabs…

Additionally, as you tabbed through the links, you had to go through all the links in each section before you got to the next section header’s link.  I don’t have a lot of links in any one section, but I still found it really annoying…

So, a couple changes:

1. I added <a> tags inside each section header, an <h3>.  Those <a> tags have hrefs to that section’s id (such as href="#contact"), and the onclick that I apply post-page-load just references this.href.  Because it is an <a> tag, it can now receive tabs, which leads to…
2. I also added a tabindex to each of the new <a> tags, giving them 1-3, leaving all other links in my HTML to fend for themselves, which they do quite nicely: tabbing through the page now takes you to each of the section header links, then to the links in whatever section is currently open.
3. And just for the heck of it, I also added an accesskey to each <a> tag…  :-)

So, there you go, another learning process, and another step in the right direction!

Happy coding,
Atg

Top⇪