Fix 85% of your Web Accessibility issues in 5 easy steps

In a previous post, we saw the importance of Web Accessibility and mentioned The WebAIM Million, an analysis by WebAIM on the current state of Web Accessibility of 1 million popular pages.

The results were devastating: the analyzed home sites averaged almost 60 errors each, and the percentage of clean sites was less than 3%. But, there was a silver lining: most of the errors could be grouped into just a handful of categories. Out of a total of 59.6 million errors, 52.1 million were caused by only five easy-to-prevent problems:

• 36 million were instances of text with insufficient contrast.
• 12.3 million were images without an alterntive text.
• 2 million were inputs without a corresponding label.
• 1.3 million were ambiguous or empty links.
• 0.5 million were unordered headings.

Correcting these five issue types would fix most of the Accessibility problems detected.

The 5 easy steps

1. Increase text color contrast

Poor text contrast was the most common mistake according to the WebAIM report. On average, the analyzed home pages contained 36 issues with insufficient contrast between text and its background.

The difference between valid and invalid color contrast is sometimes subtle.

For me, this may be the most limiting requirement (at least creativity-wise), as many times I find an interesting color palette that I end up discarding because it doesn't meet the WCAG specifications. One option is following the less restrictive Level AA level criteria as it is not possible to satisfy all Level AAA success criteria for some content anyway.

WebAIM has a really nice tool to check color contrast, and you can find many other tools online. Actually, it is really easy to implement your own one. It requires some math, but nothing fancy, and it can be a great learning experience. For example, I developed a contrast checker myself in order to test RGB colors since all the checkers I found online worked with HEX values only.

2. Add alternative text to images

Adding alternative text to images is one of the main pillars and basic principles of Web Accessibility. Yet it is one of the most common problems in almost every website, even when the alt attribute is required in images.

<img src="guernica.jpg" alt="Guernica painting by Pablo Picasso" />

Although it seems as simple as adding the alt attribute with a description to the <img> tag, the alternative text may require a little bit of thought. What is the role of the image? What is the text surrounding it? We may not want to ignore the image (adding an alt=""), and we don't want to have screen readers repeating the same information twice.

alt="Guernica painting by Pablo Picasso" alt="Guernica: a large oil painting by Spanish artist Pablo Picasso completed in June 1937" alt=""

Any of the alt on the right could work for the image, it will depend on the context

And one more thing to consider: if the image is used as a CTA, the alt should be a description of the action to be taken and not of the image! Users may want to know that the image is a printer, but what they really want to know is that if they click on it, the document will be printed.

3. Label form elements

Labels present many benefits such as: (1) they help identify & provide additional information about the field; (2) when clicked they will focus on the linked form element; and (3) they are simple to implement. You just need to wrap the text with a <label> tag and use the for attribute to point to the element's id:

<label for="username">Username:</label>
<input id="username" type="text" name="user">
<label for="password">Password:</label>
<input id="password" type="password" name="pass">

Sometimes there may be tricky situations in which inputs may not have a specific label for each of them (e.g. a table with rows that allow edition, or a label that should apply to multiple fields). In these cases, you may use the attribute aria-labelledby to point to the element that will serve as a label:

<table>
  <thead>
    <tr>
      <th id="namelabel">Name</th>
      <th id="addresslabel">Address</th>
      <th id="agelabel">Age</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><input aria-labelledby="namelabel" name="name" /></td>
      <td><input aria-labelledby="addresslabel" name="address" /></td>
      <td><input aria-labelledby="agelabel" name="age" /></td>
    </tr>
    ...
  </tbody>
</table>

If you have a form or a component that includes form elements such as input fields or radio buttons, don't forget to add a label for the different form elements or add a aria-labelledby attribute.

4. Add meaning to links

How many times have you found a website or blog with summaries of the posts and links asking to "Read more"? While that is a description of the action that the user will perform, it doesn't really provide actual meaning to the link. Are we going to be reading more about elephants, web programming, or brain surgery? Read more about what?

Don't do these things... Read more

Do these things instead... Read more about Web Accessibility

One of these links provides actual information about the linked content

Now some may say: "But having a long meaningful link breaks the way in which our site is presented! There's only space for a 'Read more' caption!" And for them there is an alternative: use aria-label in your links:

<a href="#" aria-label="Read more about Web Accessibility">
  Read more
</a>

Modern screen readers will read the aria-label instead of the anchor text, so you could potentially leave your short link caption while providing a meaningful and accessible text.

5. Organize content correctly

The content on each page should be structured semantically and organized correctly, using the right headings in an orderly way. This may sound like a no-brainer, but it is a really common mistake: over half of the analyzed home pages presented this issue.

Screen readers allow users to jump from heading to heading. A poorly organized document will resemble a Choose Your Own Adventure book for them! And the disorganization is also confusing for the rest of us as well as for website crawlers.

Heading 1 Heading 3 Heading 2 Heading 4

Heading 1 Heading 2 Heading 3 Heading 4

Your document should be organized like the right column, never like the left one

Also, don't forget to use the proper semantic tags; it is important to use headings (<h1>, <h2>, etc.) instead of styling other elements to look like a title. They may be similar visually, but not all users rely on their vision.

Conclusion

The fact that 87% of the Web Accessibility problems found on the WebAIM analysis were really low hanging fruit errors may seem like great news, but we need to take these results with a grain of salt: the analyzed pages were just home pages, which normally don't include complex components subject to more complex accessibility issues.

Also, claiming that 85% of all the accessibility issues could be fixed with the 5 steps above is a bit of a stretch. (Sorry for the click-baity title.) Although, chances are that the actual percentage is not that far off from reality (which would make good the old 80/20 rule in computing).

The main lesson to take away would be that improving Web Accessibility may be challenging, but it is not as complicated as it seems, and every improvement, even the tiniest one, counts.

Comments

[Vuild]

Mr Simpsons*

Great article, useful info well laid out & really covers a lot of the core issues.

I just started using the < picture > tag a lot more, does the same accessibility apply as img?

*check out his amazing CSS Simpsons on GitHub. :)

[Alvaro Montoro]

Maybe my next post should be about how to draw Homer Simpson with HTML+CSS :)

[Vuild]

Yes, why not.

But maybe Guernica in CSS. 😳

[Sophie The Lionhart]

Not OP but I think you may have forgotten a word! Which tag did you start using a lot more?

[Vuild]

Fixed, thanks Scott.

[Alvaro Montoro]

Thanks for the comment!

What tag are you using? (It doesn't display it)

[Vuild]

Picture

[Alvaro Montoro]

The <picture> should have a fallback <img> anyway.

One accessibility issue could happen if the image is not the same, because the alt that the screen reader will read is the one from the <img>. So if for any reason the images in the <source> don't match the one from the <img>, it could be confusing/misleading.

[Vuild]

That's the answer I need. Thank you. 👍

[Thibaut Allender]

Why would you use the picture element tho? It's not supported in IE11 and below without a polyfill, and it needs more markup that the img + srcset/sizes attributes, for exactly the same result (img + srcset/sizes is even easier to implement)

[Vuild]

Microsoft tried to own the Internet & for many years tried to break the web. IE numbers are low, it's render is worthless. They intentionally added a massive overhead to all dev for years. Don't waste much time (96, you remember clear). Chrome is trying to repeat.

Below IE11 is not really a real thing. Docs, devs & their shills will say it is but it is not. Don't build a site for that one person. Ignore hysterical ui ppl with no biz/vol experience. Go broke this way unless it is 'overfunded'.

Change of policy from me: Picture is now the correct tag for decorative. I don't actually care now because it's getting out of control productivity wise. I am basically ignoring all rules & doing what I want that gets results.

Not even going to do much srcset at all. It doesn't really make sense.

[Thibaut Allender]

So this is a post about accessibility and you're telling us to ignore users that still use IE11 and below?

While I totally agree they shouldn't be using outdated/unsupported browsers, the reality is, these users exist.

There's probably as many IE11 users as blind users, and yet, we don't ignore the blinds.

[Vuild]

Nope, I am telling you to do what you want & "theory" is rarely practice. "Make everything accessible" is not real world advice. I am telling you what I am now doing (instead of overengineering). A thread about accessibility doesn't mean you can't argue against timewasting.

I didn't not say ignore old browsers. I build sites that last years with clean simple code usually. I have sites from decades ago that work still (on desktop).

I try not to ignore blind users as they did not try to destroy the internet. Old outdate IE? IE stays last until Greg convinces me otherwise (he promised they would do better).

"But poor people" (yes, I actually know about this in practice, not theory). I'll build more sites rather than tackle a pointless usecase for a company who wishes I had no business here.

The large sites are rarely usable or follow the rules themselves.

Probably less clear.

[LilyOfTheValley]

Hi !
Thanks a lot for this post ! I'm trying to learn more about accessibility for an upcoming project and found myself overwhelmed with the search results, this post is clear, right to the point and gives examples. Do you (or anyone) know where I can find similar resources, to go deeper on the subject ?

[Alvaro Montoro]

I like WebAIM's tutorials (although it can be a lot of information and a bit overwhelming sometimes). Their accessibility checker is really simple to use and if it finds any issue, it will highlight it, show a short description of why it is an issue, and link to articles and guidelines related to it.

[Rémy 🤖]

Great and perfectly timed for me, I'm researching the topic those days.

A few more things I'd like to read about:

• Debugging accessibility (like the accessibility tab in the Firefox dev tools which looks great)
• Testing accessibility (what should we test? How do you simulate color blindness? How do you use a screen reader? What else?)

Also it seems to me that properly labelling forms/sections/etc is pretty important because it's a pre-condition for screen readers to see them as such. Is it just an impression?

Thanks!

[Alvaro Montoro]

The article was posted here: dev.to/alvaromontoro/free-web-acce...

It's not exactly the answer to all the questions you asked (thanks for the ideas for new topics!), but I hope it's helpful.

[Alvaro Montoro]

My next article is about the different free tools I use for testing accessibility. It will be posted today or tomorrow (waiting on some editions), and it addresses some of those questions.

[Kyle Johnson]

Great article! It really bothers me when web developers do not think about accessibility.

[Alvaro Montoro]

Thanks!

[Al Romano]

When looking for a web accessibility tool, check out this testing page by the UK Government.

This completely inaccessible page is chock-full of 143 accessibility errors and lets you benchmark your Accessibility tools' effectiveness. We made a custom fork of this at work to use for benchmarking tools.

WAVE by WebAIM is okay but there are better tools that scored higher for more coverage like Tenon or Asqatasun for checking during CI/CD pipes.

Not all tools are made equal so it's important to see which tool works best for you!

[Alvaro Montoro]

Those are great suggestions. I normally use Wave, but I have used Tenon too (I need to try Asqatasun).

I always tell people that their results must be taken with a grain of salt, as they mostly check the "technical parts" and miss many real issues (like some on the site that you linked, that would require a more "personal" approach), and many others are overzealous reporting things that could be considered false positives (which could be overwhelming, especially when you are beginning).

[Sujan-99969]

the NVDA is not reading the first line in list. please help me out from this

[Brian Gavin]

Agree, these are examples of low hanging fruit but do not necessarily solve for the ux gap disabled users face . Creating Personal Accessible Experiences is a must - hubs.la/Q026r6v10