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.

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:

JavaScript disabled/enable pie chart for AT users

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.

Win an Annual Membership to Learnable,

SitePoint's Learning Platform

  • Aurelio De Rosa

    Hello.

    First of all, thank you for taking the time to comment.

    About the first suggestion on the second point, it isn’t a better solution to use a title attribute. Employing it, a screen reader will read the text of the link *and* then the title, so it can be quite confusing. In my example, a screen reader will read “Click here link Click here to go far away from Kansas” instead of just “Click here to go far away from Kansas link”.

    About the second point, there are at least three reasons to not wrap an entire section inside an `a` element. The first reason is that it makes harder to deal with style. If you think at the default style, you’ll recall that all the text inside the section will be underlined, which isn’t really good for a classic, non-AT user. Changing this behavior will lead to a lot of style to write without any real benefit. The second reason is that several people use to select a word by double clicking it. If you have an `a` element that wraps the whole section, this action will trigger the click event, so it’ll open the page without selecting the word. The third reason is that a lot of people select text by clicking on the first word of interest and then moving the mouse. If you try to do that with the text of a link, several browsers try to drag the link, not select the text.

    I hope this helps.

    • http://dada.theblogbowl.in/ Shaumik Daityari

      Fully agree with you. The best way is to switch off your display and try working with the keyboard and NVDA and see how tough the real world is for some people.

      • Dennis Lembrée

        Also note that the option to read out the title attribute is turned off by many screen reader users.

  • http://www.forumone.com Daniel Ferro

    Actually, I have found that NOT using the tabindex is usually the way to go for optimal accessibility. When you start introducing tabindexes into the content of a page, different browsers interpret negative and missing tabindex in different ways and can really wreck the natural tab order of a page. Almost always, the natural tab order is preserved. About the only time you should use tabindex attribute is when the natural tab order is not in line with the visual order of items.

    It gets even more messy when content is generated dynamically or a page evolves slowly over the course of a few months and new sections are added to pages etc.

    In your book example, most people who use AT rely on headings to navigate from item to item. The user would simply switch their screen reader to heading mode to efficiently navigate to the item they are interested in.

    • Aurelio De Rosa

      Thank for your comment.

      As you can see I’ve only used the -1 value of tabindex that, based on specification, means scripts can focus the element, but not users. It should not cause any issue (like using a positive value). More words on this discussion have been spent in the article I linked ( http://www.sitepoint.com/learning-to-focus/ ) by Steve Faulkner and Patrick H. Lauke.

  • rhpaiva

    Good basic points for the ones starting, but please, don’t create a link where the anchor is “click here” in an article about accessibility. :)

    • LouisLazaris

      True, good point.

      But keep in mind that in no place in this article did Aurelio claim to be an accessibility expert. As he said in the intro, he’s simply sharing some points he’s learned. I think many of us are in that same boat, even I (who reviewed the article) should have noticed the “click here” in the example code and did something about it. :)

    • Aurelio De Rosa

      Hi @rhpaiva:disqus.

      First of all I want to thank @LouisLazaris:disqus for the reply. It’s absolutely true that I’m not an expert, so there may be a lot suggestions better than mine. However, on the point raised I have the following thoughts.

      I’m not really convinced that “click here” is wrong under a certain point of view (but that’s just my opinion). Using the trick shared in point 2, a screen reader user will have a meaningful (maybe a bit redundant) “click here to go far away from Kansas link”. On the contrary, a sighted user will have just the “click here” label. I’ve always thought the label is very easy to understand for a non-savvy web user and gives the user a quick feedback that he/she has to click on that very text. I’m not sure about the reaction that someone may have with a text like “go to far away from Kansas”. In that case, to let the user understand that label was a link, you’ve to rely on the style (underline, color different from the normal text, and so on) which may be not easy to guess. Besides, what if I don’t want my link to be underlined by default? I think the difficulty increases.

      That’s my opinion. If you have some insight or data that you want to share with us, I’d love to read them.

  • Aurelio De Rosa

    Hi Phil.

    Thank you for taking the time to comment. I’m asking you a couple of questions because you had the chance to perform some tests. How did IE8 played with conflicting accesskey? Does it advantages the accesskey of the page instead of browser commands? Any other comment on your experience?

    Cheers