5 Things I’ve Learned About Accessibility

Every developer should learn something new every day, at least those who want to be good. It can be something as simple as a new CSS property or as complex as a library. Whatever it is, it’s all welcomed as long as you learn something.

In my attempt to follow this principle, I recently decided to focus on a topic I really care about and that, until now, I haven’t had the time to deepen my knowledge of: Accessibility. Accessibility (often abbreviated as a11y) is defined as the practice of removing barriers that prevent access to websites by people with disabilities.

In this article, I’ll share with you some tips and tricks to improve the accessibility of a website. I’ve learned these recently while attending related events (like InclusiveDesign24 and the May meetup of London Web Standards).

1. Do Not Use the accesskey Attribute

A few years ago, I discovered the existence of an HTML attribute called accesskey. It can be associated with any HTML element and its value is established by the author of the web page. Its aim is to provide to a user a way to activate or focus a certain element through the use of a key, or a combination of keys. To give you an idea, let’s imagine we have the following menu that uses the accesskey attribute:

<nav>
    <ul>
        <li><a href="/" accesskey="h">Home</a></li>
        <li><a href="/blog" accesskey="b">Blog</a></li>
        <li><a href="/about" accesskey="a">About</a></li>
    </ul>
</nav>

At first glance this seems like a great accessibility improvement as we’re enabling users to access a given page with a single command. But it’s not. In fact, one of the keys we set in the markup may be in use by the user’s assistive device (e.g. a screen reader), or by the browser employed by the user, or even by the user itself. As if that was not enough, we also can’t predict collisions because each browser may have a different combination of keys to press to use the specified accesskey.

For example, a Chrome user who wants to access the blog using the value defined in the accesskey attribute has to press ALT + SHIFT + b. Nice, isn’t it? Yes, it is… until you discover that the same combination is used by Chrome to focus the bookmarks bar. Thinking of changing the value? Perhaps a t is a better choice. Nope. The combination ALT + SHIFT + t is used in Chrome to focus the toolbar. We can continue this discussion for a while, but I’m sure you get the point.

Using the accesskey attribute may create more problems than it solves. Therefore, it’s better to avoid its use and focus on writing semantic markup for our pages. The user’s assistive technology (AT) will (hopefully) do the rest.

2. Use .visuallyhidden to Add Context to Links

How many times have you seen an article or a page with a anchor text like “read more” or “continue reading”. I see these a lot (cheers WordPress, Joomla, and so on) and it’s something I’ve done many times myself, I’m sure. I’ve learned that this is not enough for an AT user.

One of the features of ATs is to show a list of the links contained in a page. So if the page has links with anchor text like the ones described above, when a user uses this feature all he/she receives from their AT is a list of meaningless “Continue reading”, “Read more”, and similar.

How can we solve this issue? To create the magic potion to fix this, we need a bit of HTML and of CSS. In particular, we need a class that implements a technique to visually hide an element. The CSS code that implements such a technique, taken from the HTML5 boilerplate source, is shown below:

.visuallyhidden {
    border: 0;
    clip: rect(0 0 0 0);
    height: 1px;
    margin: -1px;
    overflow: hidden;
    padding: 0;
    position: absolute;
    width: 1px;
}

With this class in our CSS, we can change markup like this:

<a href="path/to/somewhere/over/the/rainbow">Click here</a>

into

<a href="path/to/somewhere/over/the/rainbow">Click here <span class="visuallyhidden">to go far away from Kansas</span></a>

With this simple change, people that don’t use ATs will continue to see the links as they were before. On the other hand, AT users (especially those using a screen reader) will have the software listing (or reading) “Click here to go far away from Kansas”. This will give them much more information about the link.

3. Use the tabindex Attribute

When developing a website, it may happen to have more than one element pointing to the same URL. Let’s take as an example the homepage of an online store selling books where we have a list of several books. For each of them we have the title, the cover, the description with a remainder of the book’s title, and a call to action (typically a “Buy now” button). Usually each of these elements links to the book’s page on the store.

For a user that relies on the TAB key to navigate web pages, as is the case for many people with disabilities, this situation can be very frustrating. In fact, for each of the books on the homepage the user has to tab four times to move to the next book. Now, what if a customer is interested in the tenth book? Our dear customer has to press the tab key 37 times! This calculation also assumes there aren’t other links before the list. You can see why this would be annoying.

To solve this problem we can make use of the tabindex attribute. When the value of this attribute is set to -1, the element is removed from the default navigation flow. What this means is that the element cannot be focused using the tab key, but it can be focused programmatically.

So, let’s say we have markup like the following:

<article>
    <a href="/book-page"><h2>jQuery in Action, Third Edition</h2></a>
    <a href="/book-page"><img src="book-cover.jpg" alt="" /></a>
    <p>
        <a href="/book-page">jQuery in Action, Third Edition</a> is a fast-paced complete guide to jQuery.
        <a href="/book-page">Buy now!</a>
    </p>
</article>

We can improve the experience of tab key users by employing the tabindex attribute, as shown below:

<article>
    <a href="/book-page" tabindex="-1"><h2>jQuery in Action, Third Edition</h2></a>
    <a href="/book-page" tabindex="-1"><img src="book-cover.jpg" alt="" /></a>
    <p>
        <a href="/book-page" tabindex="-1">jQuery in Action, Third Edition</a> is a fast-paced complete guide to jQuery.
        <a href="/book-page">Buy now <span class="visuallyhidden">jQuery in Action, Third Edition</span>!</a>
    </p>
</article>

In the code above we’ve set a tabindex attribute on all the links except the “Buy now” link. Doing so, AT users will focus a link only once per book while non-AT users will still be able to land on the book’s page by clicking on any of the links.

In addition, AT users are still able to skip directly to the section of interest because the title remains accessible using the tab key to navigate through headings (<h1>–<h6>). Oh, and did you notice that we’ve also improved the text of the link using the technique discussed in the previous point?

4. Accessibility Doesn’t Mean JavaScript is Turned Off

I don’t know where this information came from or when it originated, but many people think that people using ATs have JavaScript turned off. I knew this assertion too and for a time I thought it was true. Because of this assumption, for many developers, building a website that is accessibile is equivalent to developing for people who have JavaScript disabled. It turned out this is a false myth as shown by these statistics by WebAIM detailing the number of people with JavaScript enabled and disabled.

A graphical representation of those same statistics is shown below:

5. Test Like an AT User

This might be surprising, but to be honest it’s the best lesson I can share with you. No matter how many tricks or techniques you may learn, there is nothing better than using an AT to test the accessibility of your project. Pretend to be a screen reader user, a tab user, a blind user, a user without an arm, and try to navigate your own website. You’ll discover in just a few seconds how the web can be frustrating for a person with disabilities, and how strong is the need for a more accessible web.

If you need some suggestions for screen reader software to use to start testing your website, you can try NVDA (NonVisual Desktop Access) or JAWS on Windows, or VoiceOver on OS X.

Conclusion

In this article I’ve discussed some concepts and techniques I learned over the past few months. I hope you enjoyed thes tips and found them informative. Even more important, I hope this article has opened your mind a little to allow a different type of thinking on your next project.

Now it’s your turn. Did you know any or all of the techniques I’ve shared in this article? Do you have any of your own accessibility tips to share? Have you tried a screen reader? Share your thoughts in the discussion below.