Ridiculously easy trick for keyboard accessibility

One of the more frustrating things about accessibility is how ridiculously easy most things are to do. While most developers tend to see accessibility as nebulous and time consuming, the truth is some of the most impactful issues are actually easy to deal with. As a case-in-point: consider simple keyboard accessibility for custom controls otherwise activated by click. For the <button> element, you get free accessibility. It appears in the tab order and reacts appropriately to both click and keypress via the enter and spacebar. This is not the case for custom controls, such as those created with DIV and span. Typically you’ll see developers do something like this:


$('#fake-button').on('click', function() {
    //do stuff
});

The problem with the code above is that it only works when the user clicks the mouse button. So for whatever this button does on click, it absolutely does nothing when the enter key (or space bar) is pressed, which is how one expects to interact with buttons via keyboard. The solution is, obviously, to check for keypress too. BUT don’t do this:


$('#fake-button').on('click keypress', function() {
    //do stuff
});

That will trigger on any keypress, including the TAB key. For a keyboard user that would be a bit like triggering on mouseover. Instead, you need a function to check the specific key(s):


function a11yClick(event){
    if(event.type === 'click'){
        return true;
    }
    else if(event.type === 'keypress'){
        var code = event.charCode || event.keyCode;
        if((code === 32)|| (code === 13)){
            return true;
        }
    }
    else{
        return false;
    }
}

That function returns TRUE on either click or whenever the space bar or enter key have been pressed. Now all you need to do is this:


$('#fake-button').on('click keypress', function(event){
  if(a11yClick(event) === true){
    // do stuff
  }
});

Given how simple this is, developers really have no excuse for using only ‘click’ on controls.

If you are interested in learning about the next generation in Web Accessibility Testing, give Tenon.io a try.
If you or your organization need help with accessibility consulting, strategy, or accessible web development, email me directly at karl@karlgroves.com or call me at +1 443-875-7343. Download Resume [MS Word]

2 Comments

  • Posted November 24, 2014 at 5:11 pm   Permalink

    Very frustrating, indeed,when easy solutions are at hand, and yet bad practices remain steadily dominant.
    I had a similar feeling when I wrote this: http://accessiblog.fr/2012/02/little-action-great-effectsimproving-a-css-based-tooltip-in-18-seconds/. I posted the solution as a comment in the initial blog post. The reaction has been… nothing. Although my comment got stuck in the middle of several “cool stuff ” and “nice trick” messages, I had hoped the author would have shown some interest in expanding her code’s potential audience for such a tiny change. But AFAIK this attempt has been akin to “pissing into a violin” as we say in France.
    So if simple solutions backed by statistical evidence aren’t bought by web devs and designers… Then I don’t know what will work.

  • ginader
    Posted January 9, 2015 at 7:10 pm   Permalink

    This is a beautifully handy pattern! I have one little enhancement here:

    function a11yClick(event){
    if(event.type === 'click'){
    return true;
    }
    else if(event.type === 'keypress'){
    var code = event.charCode || event.keyCode;
    if(code === 32){ // don't scroll the page when space key is hit on an cta
    event.preventDefault();
    }
    if((code === 32)|| (code === 13)){
    return true;
    }
    }
    else{
    return false;
    }
    }

    By adding this extra preventDefault() the page will no longer scroll when the user hits the space bar on the new custom control just like on a native button.

One Trackback

Post a Comment