Kilian Valkhof

Building tools that make developers awesome.

Context hover – accessibility

Accessibility, 2 June 2008, 2 minute read

One of the things I feel I did not cover enough in my first article is the accessibility side of things. This has led to a Spanish article adding focus and blur events to the effect as well. That might seem like a good and accessible addition, but I think that it’s a bad idea, and I’ll explain why.

Accessibility

Although my Spanish is somewhat limited, what the article rightfully noted was that this effect didn’t work when using a keyboard to navigate your page. The writer remedied this by adding and removing the class on focus ans blur as well. This is the code he used. (I have changed his original code somewhat to make it slightly more efficient):


$("a").hover(
	function() {$("a[href="+$(this).attr("href")+"]").addClass("hover");},
	function() {$("a[href="+$(this).attr("href")+"]").removeClass("hover");}
      )
      .focus(
	function() {$("a[href="+$(this).attr("href")+"]").addClass("hover");}
      )
      .blur(
	function() {$("a[href="+$(this).attr("href")+"]").removeClass("hover");}
      );

However, I urge you not to use this

Though it seems like this is a “more accessible” method, in reality it is not. One of the key things with accessibility is thinking of your audience. Who would benefit from adding this effect, and who would not benefit from it.

Keyboard users do not benefit from this.

Actually, it makes it even harder for them. Keyboard users depend on visual cues to determine where they are on the page, such as the outline in Firefox around focussed elements, or the :focus style any good web developer adds to their website (The :focus style can and most of the times should be the same as the :hover style.)

So, if we’ve just established how a keyboard user determines where he is in a page, lets add in the above script. For fun I’ve made an example: Context hover, keyboard added. Close your eyes, tab through it a couple of times and tell me which link is selected and what link would get selected if you press tab again.

That was fun, wasn’t it?

Giving keyboard users the effect as well

So is there no way keyboard users will benefit from this technique? Of course there is. What the effect does it show all links with the same URL. The actual selected link is known because, well, you’re hovering your mouse over it. To make it of use for keyboard users, you need to have different styles for the currently focuses link, and the other links going to the same URL, like this example. If you tab through it, there is a difference between the currently selected link, and the other ones going to the same URL.

I still feel that this effect is only really useful for mouse users and should not be visible to keyboard users. However if you really want to use it, this is the way to make it worth their while, too.

The takeaway

Accessibility is important, but it takes more than just defining keyboard equivalents for your mouse actions. Accessibility is thinking about all your different audiences and making the experience as accessible and easy as possible for each of those audiences.

Polypane browser for responsive web development and design Hi, I'm Kilian. I make Polypane, the browser for responsive web development and design. If you're reading this site, that's probably interesting to you. Try it out!