By Aurelio De Rosa

5 Things I’ve Learned About Accessibility

By Aurelio De Rosa

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:

        <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>

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>


<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:

    <a href="/book-page"><h2>jQuery in Action, Third Edition</h2></a>
    <a href="/book-page"><img src="book-cover.jpg" alt="" /></a>
        <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>

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

    <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>
        <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>

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.


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.

  • sff9

    About your second point: isn’t it better, both semantically and from the point of view of simplicity, to use the “title” attribute to do this?

    About your third point: in your example it would be better, in my opinion, to have a single link encompassing the whole “article” division. More semantic and simpler. The technique is good to know though; you could add some non-link text in the middle of the division, this would make the example more striking.

    Anyway, thanks for the post!

    • Vincent Young

      Second Point:
      1. Let’s first mention the use of “click here”. Very few cases where “click here” would be necessary. The link text should simply be “Go far away from Kansas.”

      2. The reason why a title attribute would *not* suffice is that many screen readers do not announce the title text by default.
      3. Screen readers provide access to a link menu with all the links on the page for easy navigability. Similar to how we might scan a page visually for all the blue links. If the link text is “click here” this really doesn’t provide context and the title text does not get included with the link list.
      4. Long story short, have meaningful link text and don’t use “click here”

      Third Point:
      The main issue/point is that you need one link… so restructure the HTML and make one link or potentially use javascript to make non links clickable. Use CSS to get the UI looking the way you need to if needs be.

      jQuery in Action, Third Edition is a fast-paced complete guide to jQuery.
      Buy now!

  • Aurelio De Rosa


    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.

    • 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.

    • sff9

      Thanks for the answer. I take note of the “title” problem, indeed your solution is better then (though I agree with Vincent Young that the best solution is probably to try to stick to meaningful links).
      My remark about the third point was actually misguided, I did not see that there was non-link text already in your example… Obviously it makes no sense to make the whole div a link if you don’t want everything in it to be a link. Sorry about this, and thanks a lot for your patience!

  • 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 ( ) 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.

      • Ash

        See the last two dot points on under the heading Examples of Success Criterion 2.4.4

        It states that using ‘read more’ or similar as link text is fine when in context. While I agree that link text should be as meaningful as possible (see first paragraph on the above link) there is also no issue with using generic text. Should a user wish to skip over the context a link is provided in then it could be reasoned they may not fully understand that links purpose.

        Take this site as it currently stands. Down the bottom in the footer is a heading for ‘Our Sites’ with a list of links following. If I chose to skip to the link, bypassing the heading the ‘Reference’ means nothing to me as I would not know the context of that link. Even as a visual user reading that link text alone is not overly useful but in context it makes perfect sense.

  • Julio Incarbone

    Hi Aurelio De Rosa, me super glad you’re starting into the exciting world of Web accessibility. I commented a few things that may serve in the future to implement a more robust way your knowledge …

    Let’s start one step at a time …

    When you mention the item: “. 1 Do Not Use the accesskey Attribute” While what you say is correct, there are many possibilities of overlapping letters. This is not correct in the case of the accesskey accessibility. The accesskey we placed inside the attribute must be numeric. Numbers from 0 to 9 that will allow us to avoid this big problem.

    I suggest you look at how they are formed standards of use of this attribute in the rule 508 of USA and England at these sites ( and ( )

    I agree with Daniel Ferro, mentioned that users are no longer using the tabindex for navigation. This does not mean they are not important and we must stop place, just that people with disabilities use other methods to access content that may interest them. Our users also improve their skills over time!.

    Regarding point 2, the context of links is essential to place the disabled person in the correct use of information. As mentioned Vincent Young, a title (if it may not mention a screen reader) or actually place action to develop (“go far away from Kansas”) is meaningfully better and extensive usability (call to action).

    Nothing like trying these things with real users, watching and learning from your challenges improve as programmers and people. Web accessibility allows us to include and innovate together.

    Thank you very much for this post and the debates it has generated, it is so rewarding.

    Bye and thanks

  • Phil Barnes

    Yew, another person on the same wave length – Accessibility doesn’t mean JS is turned off. It is too often that accessibility or the perceived level of an accessible website is to not push too far, only support lowest common. Problem is that approach is safe and stifles innovation. Re accesskey point, I have successfully worked with accesskeys within a modern portal app and they provided desktop like functionality within the functional screens. Though I will add a caveat, we knew the AT used within the Org and we only supported IE8 as it was an internal portal. Lot of testing to ensure no issues with AT and was passed by users of the tech.

  • 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?


    • Phil Barnes

      Hi Aurelio,

      Sorry for the delay in getting back, I had the comment in my email flagged as a “To do” :) In the example of our portal the, page Accesskeys took precedence over the browser. I believe this was achieved through the JS Framework that was employed. Further comments would be to re-iterate the testing, I would also suggestion more caution rolling out this functionality to external web applications where the SOE is not as contained, as a Gov Dept… Though I don’t think it is something to not do, as the benefits were great in many cases. I presented a case study for inclusive design or which accesskeys were a big part of the success of the project.

Get the latest in Front-end, once a week, for free.