Keyboard Support: Mysteries Unveiled
As you may or may not know, dear reader, I’ve divided my time between my usual role as a web developer and my newer passion for photography. If not, I’ve recently explained it. Being so divided and all, I’ve somewhat neglected reading other people’s blogs, now only spending a fraction of the time doing so. I’m still out there, though. Just recently, in fact, I was checking out that A List Apart (ALA) article by Dave Shea: CSS Sprites2 - It’s JavaScript Time.
It’s a good article describing a cool technique (somewhat like one I tried myself a year ago using animated GIFs instead of JavaScript). But there’s a problem with the new jQuery technique: No keyboard support for users who need stuff like that to help them get around (not everyone can use a mouse). In other words it lacks a common accessibility enhancement: link/anchor focus.
It’s Still Voodoo
It occurred to me that to this day there must still be some mystery surrounding keyboard support to web users. I really thought this was a thing of the past. I thought the web development community had gotten this far and was pushing forward, finally, with better consideration for more users. After all, personally I have spent some time and effort spreading the word — a May, 2007 Accessites article and a May, 2006 article here (and I’m just one voice of many). I was thinking the effort was paying off. It seems I was wrong. After all, if high profile industry leaders like those folks behind the ALA (whom, with their readers, have accessibility down pat) are still forgetting this, I apparently still have my work cut out for me.
It’s a bit frustrating. There are many aspects of providing for the disabled that can be pretty tricky to get right, but link focus is very easy. If it’s omitted there’s really no excuse. None at all. But I’m not writing this to shame those who are forgetting. Rather, this is a reminder. I’ll even provide a quick overview. I don’t want to upset anyone, I want to fix this blatant oversight. I want developers to remember. I can’t get them to care, and I don’t care if they do, but I do want them to be accommodating all the same. I’m not the only one pushing for this. There are other developers who are passionate about accessibility, then there are those who actually need it. These groups are also ready for web-wide adoption.
How to Add Focus to a Link with CSS
When you style links in your CSS file, you’ll probably do something like this, which will offer user interaction when they hover over a link. In this bare minimum example I will remove the underline and change the color. Very typical.
a:hover {
text-decoration : none;
color : red;
}
Now I will reveal the mystery behind adding that same support for keyboard users. Don’t blink else you’ll miss it as there’s not much to it at all.
a:hover, a:focus, a:active {
text-decoration : none;
color : red;
}
That’s it. I added a:focus, a:active. There is more to it that I would recommend, and have, such as adding a background color, and possibly isolating focus (land on) from active (click, or ‘land on’ to Internet Explorer) to enhance the experience even more. But since I don’t want to be too verbose here and now, I am asking that you read or re-read the past articles I wrote for more.
And With JavaScript…
Since the ALA article I mentioned uses JavaScript (JS), I realize I better cover that as well. Now I must warn you, I’m by no means a JS guru, In fact I’ll go so far as to say I suck at it, but I do know how to offer keyboard support so I will. To be extra careful, I had Tommy earn his editor’s title here especially. If you have slicker methods, which you may, please share (be sure transform your code into character entities if you do).
The basics: Concurrent to the use of onmouseover() and onmouseout() event handlers, there should be onfocus() and onblur() event handlers to accommodate keyboard users. JavaScript authors can reuse their code since the onfocus() handler should do the same as the onmouseover() handler, and the same should be true of the relationship between the onblur() and onmouseout() handlers. That’s all there is to it. Simply adding these two event handlers to the attachNavEvents() function in the case of the aforementioned script will provide the support needed to accommodate keyboard users.
As shown, as it pertains to the meager CSS required to afford simple support to keyboard users, offering this same support via JavaScript is just as simple. Some developers may think it of this as a particularly minor oversight, but to those who use their keyboards to navigate a web page, it’s important. Being that there is such a minor solution available, the ignorance and forgetfulness excuses are really starting to wear thin.
I turn my back for one minute to take some photos and, boom, the web starts back sliding. 
Blair Millen responds:
Posted: September 17th, 2008 at 3:50 am →
It’s a crying shame that you have to make another post about keyboard focus Mike… as you say, it’s such a simple addition to your stylesheet, there’s no reason other than laziness not to do it!
Tommy Olsson responds:
Posted: September 17th, 2008 at 5:13 am →
I think the reason is that many designers and developers – just like many users – only ever use the mouse for navigation. The linear tabbing that is all most browsers offer is simply too tedious to use. And since they don’t navigate by keyboard themselves, they might forget to test that aspect – or even believe that no one works that way.
The spatial navigation feature is probably the main reason I prefer Opera (although far from the only one).
John Faulds responds:
Posted: September 17th, 2008 at 6:18 am →
At the risk of coming across spammy, I actually wrote an article recently on my site in response to Dave’s ALA article using an image replacement technique that I believe is more accessible (links are still visible with images off) and I also added in keyboard support.
Mike Cherim responds:
Posted: September 17th, 2008 at 8:19 am →
One script from the ALA will more than likely end up on 100s of websites. Most who use it will never know about the omission. Being the ALA is a premier industry leader, they should strive to make damn sure they don’t leave any loose ends.
@John: Your solution is fantastic. I wasn’t really digging over at the ALA I was just checking it out. I learned of the oversight by tabbing onto the example page. I guess if I would have dug then I would have brought up the IR method used. That’s a deeper shame both oversights exist.
Joe Dolson responds:
Posted: September 17th, 2008 at 10:46 am →
Is there an echo here? Funny, I could have sworn that I’ve heard something about keyboard focus before…
I recently did an accessibility audit for a project where the developers assured me that they’d done everything they could to make sure the site was conformant to WCAG, and they simply wanted some outside confirmation that they’d gotten things right.
In general, they’d done all right: but keyboard navigability? Nothin’. Even those who are attempting to be conscientious seem to miss that fact over and over.
Jen Rohrig responds:
Posted: September 17th, 2008 at 1:21 pm →
People are silly… if they took the time to think about what they’re doing they’d realize that a lot of these things are simple and easy to do every time - make sure keyboard users are included, make sure images have alt text, make sure colors have good contrast, and so on … and even on already done sites adding these things can be quick and easy.
Stomme poes responds:
Posted: September 18th, 2008 at 5:44 am →
Now, I’ve often seen old articles at ALA edited later on to add new functionality or mention some browser/UA has a bug with something… anyone know if these two simple JS additions will be added as at least an addendum to the ALA article??
I’m super-guilty of not going back to old sites and adding keyboard functionality… it was only by luck that I was sent to Tyssen’s Drop Down Low Down which, a bit down the page, Matthew Carroll has a pretty normal Suckerfish menu but with just a bit more CSS so keyboards can (without Javascript) see where they are tabbing as they go through the submenus. Would have never seen it or known of it otherwise.
Mike Cherim responds:
Posted: September 18th, 2008 at 8:04 am →
That’ll be a positive step if they do, but upon just checking, not yet. Still no keyboard support, and the whole nav goes bye-bye with images off.
Ross Bruniges responds:
Posted: September 20th, 2008 at 8:45 am →
I cannot agree with you more about your stance that the large websites need to have higher levels of quality assurance in there articles and it’s something I plan to talk more about sometime soon over at my blog and an upcoming UK barcamp.
Articles can of course be proof of concept but no-where in the article did it say this, I can see why but if this is the case why write the article in the first place!
Good job writing up a follow up post Mike!
Mike Cherim responds:
Posted: September 20th, 2008 at 9:25 am →
Thanks Ross. By the way, I love the masthead on your site — I want to party with you man
Web Marketing Ann Arbor responds:
Posted: September 22nd, 2008 at 8:44 am →
I feel that even if its simple to do, some new bloggers don’t have as strong a programming base and need to be told how to do it!
Zohan responds:
Posted: October 2nd, 2008 at 4:26 am →
I agree with “I feel that even if its simple to do, some new bloggers don’t have as strong a programming base and need to be told how to do it!”
Deborah responds:
Posted: November 1st, 2008 at 1:33 pm →
Mike,
Very timely article, at least for my client’s recently released site. I came across your article after I released their site, and realized I had not added :focus and :active for the links. Thanks for the reminder!
Mike Cherim responds:
Posted: November 1st, 2008 at 1:50 pm →
Always glad to help, Deborah!