Accessibility in web — but why?

Photo by Melisa Hildt on Unsplash

As you clicked on this article, you might be interested in the question, why you should even care about accessibility in web. Maybe you even heard about it the first time when reading the title. I will try to explain to you, why it’s important to consider making your web application accessible and which benefits it might have for all your users.

Why should you care?

Accessibility is a big topic because there are a lot of people with disabilities. According to a report of the WHO from 2011 about 15% of the worlds population have some kind of disability. 2–4% have significant difficulties in functioning. Even if you just go with 2% there are still 154,000,000 people worldwide. Even if not all of them are using the internet there are still many which could possibly discover your web application and try to use it.

But it’s not all about people with disabilities. While you are making your web application accessible, you will in most cases also improve the usability of your application. Because beside of things like ARIA-labels there are aspects like contrast between text and background or the correct use of labels on input fields, which will also help users without disabilities. With better usability it is more likely that users enjoy the experience of your application and will love to come back to it. So the possible target audience for accessibility improvements is much bigger than you may initially expect.

What do you have to do?

If you are really considering making your web application accessible, there is still one big question to be answered: What do I have to do to make my application accessible? The most common answer and also the one which will be topic of this article are the Web Content Accessibility Guidelines.

Web Content Accessibility Guidelines (WCAG)

These guidelines from the the World Wide Web Consortium (W3C) give you a list of aspects you have to consider to make your web application accessible. Probably you will meet some of the aspects if you are just working with best practices, especially considering HTML5 structures and general syntax.

The aspects of the guidelines are grouped by two different criteria. The first one is the priority of the aspects. There are three different priority levels from A (highest priority) to AAA (lowest priority).

A-level aspects will primarily improve the general usability of your web application. This includes topics like:

  • The correct use of colors
  • The general relationship between elements
  • The possibility of navigating with just a keyboard

The AA-level will generally improve the accessibility for different kinds of disabilities. They include topics like:

  • The possibility of using the zoom function on a page without loosing functionality and content
  • Focus and hover states.

The AAA-level is mostly intensifying some of the aspects of the other two levels.

The other criteria is the grouping by topics. First is “Perceivable”, which includes aspects like colors and sequences. The second is “Operable”, which includes aspects like keyboard navigation and navigation. “Understandable” deals with aspects like readability and error identification. The last topic is “Robust”, where the aspects are aiming on having correct syntax and a correct structure.

From the guidelines to accessibility

To actually make your web application accessible you should at least meet the requirements of all A- and AA-level aspects. Now you could take each page of your web application and check if it meets all requirements of accessibility. But this can take a lot of time, which could scare many developers. But happily there are more options than just checking everything manually.

It’s as easy as never before

An alternative to the manual checking is using a testing tool for checking about half of the A- and AA-level aspects automatically. This won’t take all the work, but it helps you to find possible issues with your application regarding accessibility very fast. One of the best tools for this is Axe from Deque. It checks many aspects automatically and has also features which are useful to identify elements which don’t meet the tests requirements and also tells you what to do to fix that. So the first part of getting your application accessible is pretty straight forward.

The remaining aspects still have to be checked manually. But for this there is another tool, which is nearly as good as Axe for automatic tests but has also a checklist for all WCAG aspects including tips and features for checking the correctness of the current implementation. This tool is Accessibility Insights from Microsoft and is available as extension for Google Chrome.

Hands-on examples

To make the topic less theoretical we will now have a look on some examples. I wrote this very simple web page that just persists of some example sections:

Screenshot of a very simple web page I wrote to show some examples
Screenshot of a very simple web page I wrote to show some examples
It may not be beautiful, but it does its job ;)

Let’s have a look on each of these sections and what may be wrong there.

Incomplete Button

At first glance this looks like a pretty normal button with an icon. At the second glance you may think of what this button even does. There is no text that explains anything and the icon also doesn’t help (even if you realize this is the react icon). Let’s also have a look what Axe has to say about this button:

Axe also says that this button needs some text. The block on the bottom gives you some ideas, how to include this text. As you can see, some of those options aren’t even visual text. For example a default “Home”-button or a trash can as delete button are understandable for most users, so they won’t need text to understand what that button does. But as someone, who can’t visually see the button you have no clue what’s going on. So for those you could simply add e.g. a title or a aria-label, that gives that button a few words about it’s purpose. Another advantage of using the title would be that every user could hover over the button to see the title too in case they don’t know what it’s doing.

It’s just one or two simple attributes to add to a non-text button and it’s directly more user friendly, especially for screen readers.

Additionally, as you may have noticed from the element source, this image inside the bundle doesn’t even have an alt-text, so if the image can’t load for any reason, the button would be completely empty and nobody would know, what it actually does, so also always think of the alt attribute on images.

To summarize:

  • Problem: The function of button is unclear; Visually impaired people don’t have any information
  • Solutions:
    Use Axe for suggestions
    - Set title
    - Set aria-label
    - Set alt-text for images within button (also for images in general)

Insufficient Contrast

This is a topic that may affect all users of you application. This text is really hard to read, even with good eyes (or at least good glasses in my case).

Axe also recognizes this low contrast ratio. In general, the contrast ratio you need for this WCAG rule is depending on the kind of element and it’s size. Mostly I recommend to aim on a contrast ratio of 4.5:1 for everything, but e.g. for icons there is just a ratio of 3:1 needed. Whenever I have a color combination, that doesn’t fulfill the needed contrast ratio I use this contrast checker to find a better color combination. This tool also directly checks for all WCAG contrast rules and shows you how your combination looks.

As you see, this is actually a WCAG rule that also helps you with the general usability of your application because users can read information more easily and as this is covered by Axe you can always just quickly scan your page to check if the contrast of everything is fine.

To summarize:

  • Problem: Hard to read texts due to contrast
  • Solutions:
    - Use contrast checker to find color combinations
    - Aim for 4.5:1 (text) or 3:1 (icons) ratio

Invalid Element Combination

This is a topic that may not be visible in first place, but it’s actually also a best practice topic, regardless of accessibility. We have here a unordered list, which contains two list items and one paragraph. Visually they look the same, but actually it is invalid HTML. This may mostly concern users with screen readers. A screen reader can understand lists and may tell the user something like “List with 3 items”. But this won’t work if there are elements, that aren’t actually allowed within the list element.

Luckily, this is also covered by Axe. It checks your page for invalid html attribute combination. In this case it tells you to fix the paragraph inside the unordered list.

So this example not only helps users with screen readers to use your application, but also helps you to write valid HTML structures with best practices.

To summarize:

  • Problem: Unreadable elements for screen readers
  • Solutions:
    - Check with Axe for invalid attribute combinations
    - Test reading with screen readers

Wrong Tab Order

Visually, this is just a basic login form with input fields for your email address, password and then a submit button. I bet many of you switch from the email field to the password field using the tab button. Therefore you would expect the password input to be the next element to focus when pressing the tab button. But when the tab order is manually changed (like in the .gif below, where I just used the tab key), then you jump to the submit button first and after another tab you get to the password field.

The text inside the password field is just visible for demonstration purpose, please don’t do this at home

Axe also tells you that you shouldn’t set a tab index higher than zero because this might confuse like I showed above. A natural tab order is, in basically every situation, the best solution.

As you see, this also helps not just users with screen readers, but improves the general usability of your application and is really easy to implement as you just shouldn’t use a tab index higher than 0.

To summarize:

  • Problem: Incorrect tab order, confusion when switching between elements
  • Solutions:
    - Do not use tab index higher than 0
    - Use natural tab order

Guidelines vs. Reality

From personal experience I can recommend to also test your implementation from the users perspective you are developing for. I prefer generally checking, if the web application is completely usable with just a keyboard without having any trouble to reach interactive items. You could also go a step further and install a screen reader to experience the application from a blinds persons perspective. Don’t look on the screen, just react on the information the screen reader gives you. This really helps understanding, if your application is easy to understand and implemented for the use with assisting software.


If you are interested in making your web application accessible you can use tools which will speed up the implementation extremely. Especially when you are working on a new application you can directly make sure everything is implemented accessible, which leads to less needed effort than making the application accessible afterwards.

You should always have in mind that making applications accessible helps a lot of people to actually use it or make it even easier with regards to general usability, like I showed with the examples above.

I hope with the examples, solutions and tool suggestions, we can make the world a more accessible place for everyone!

Web Developer @ Incloud Engineering GmbH

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store