April 30th I will be speaking at Webdirections Hover on a topic very dear to me: New and future media queries. Read on for more info on the conference, how to get tickets and a discount!
Context hover – accessibility
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.