Kilian Valkhof

Front-end & user experience developer, Jedi.

Context hover – accessibility

Accessibility, 2 June 2008, 3 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.

Thanks for Reading!

I am Kilian Valkhof, a front-end and user experience developer from the Netherlands.
Contact me or ping me on twitter.

  1. Hello, first of all thanks for noting my article. I must disagree with you about the benefits of something like your script for keyboard navigating users.

    If I have a navigation link named “portfolio” and in some other place of the page I have another link pointing there but with another anchor, some users might not understand they both lead to the same place thus making them tab back to the nav link. Is the same issue as in mobile browsing, the visual cue makes users realize they don’t need to go up and down through the page (which is a real pain if you must do it with your keyboard, one step at a time and in the order the coder thought was better).

    Please remember, not all the people who browse with a keyboard is disabled so it’s not about accesibility this time.

  2. Oi, you are right, K – sometimes we can go too far. Agreed that your second example within this article is better than the first example. However, browsing the web, sometimes even as a mouse user I start to click on link, think better of it, and move my mouse away and release the button. The a has acquired focus in this step.

    Since it has focus, in the example, the remainder of links are underlined, and the focused link is marked as well. Then, as I go to hover, even more fluttering is happening across the page to result with a visual smattering of information. Convulsions follow.

    I agree with you: the original hover only implementation is the best.

  3. Rob

    Just in addition to that, it would be very easy to plug the holes in this that have been pointed out using jquery’s event triggers.

    Building on your second example, you simply fire the .blur() event on the focused anchor at the end of the mouseout function eg:


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

Be the first to know about new releases!

Newsletter subscribers will be the first to know about new apps I release or new articles I write, here or elsewhere.

Low-volume. I will only email you when I have something exciting to share.