Common accessibility issues that you can fix today

WebAIM have come out with their latest report on which accessibility issues they found in the top million websites that they tested automatically. What is some low hanging fruit you could fix today?

For context, WebAIM, a non profit based out of Utah in the US, have done their ‘WebAIM Million’ project since 2019. They post an extensive analysis every year, looking at trends and improvements/decline in web accessibility over time. I find these posts very insightful and use them to inform my own workshops and outreach. It’s definitely recommended reading!

There are some caveats to be added with surveys based on automated accessibility testing. One is that ‘ease of detectability’ does not correlate with ‘impact on end users’. There are issues that are easy to detect and issues that impact end users most, these are not necessarily the same. Automated tests also cover only a small part of all accessibility, as some things aren’t detectable by machines (yet, or ever). I’m not suggesting this makes the survey less useful or good, but wanted to call it out explicitly. The ACT-Rules Community Group at the W3C works on harmonising test rules for things that are testable.

Ok, let’s look at the top issues and how developers, browsers and CMSes can take away barriers today. Some of these include ideas about what users can do (important caveat: none of this should be user responsibility, website owners should not expect users to use or know about these tools).

Low text contrast#heading-1

There are cases where text colour and the background colour have a ratio lower than the threshold in WCAG (see also MDN on contrast).

Designers can check contrast manually install plugins (using a tool like Contrast Ratio) or install a plugin like Stark for Figma or Sketch.

Developers can use an automated contrast checker to make sure you avoid low contrast text. Run a checker like the one in Firefox Dev Tools Accessibility Panel or axe in CI/CD, or paste two colours into a manual tool like Contrast Ratio.

Designers and developers alike can use Polypane’s contrast checker that suggests accessible alternatives, which makes it a lot easier to not just find the issue, but also fix it while you’re at it.

Users could use a plugin like Fix Contrast to not be affected: it tweaks colours on the fly so that you don’t have to suffer low contrast text.

There are some discussions on new colour contrast algorithms for WCAG, but this is still under discussion and not ready any time soon.

Missing alternative text#heading-2

When you create content, describe your images. In your CMS, on Twitter and even in GitHub issues: use that alternative text feature, so that users who can’t see the image can access the content in them. On platforms that don’t support alternative text, like Slack or mobile LinkedIn (!), you can describe images in text. If you choose a CMS or content platform, ensure it can handle alternative text or set it up to do so.

In the resulting HTML, you’ll want something like:

<!-- image with text -->
<img src="website-logo.png" alt="hiddedevries.nl" />

<!-- image with redundant content -->
<img src="hidde.png" alt="" /> 
<p>Photo of Hidde</p>

You can make your decisions on alternative text using the Alt Decision Tree, but basically the gist is that if you were to replace your image with a square, what would you write in the square for it to still be useful? Leaving it empty is an option if that’s the most useful alternative for the image.

Users can use Microsoft Edge, which fills in missing alternatives. AI aren’t very good at intentions or context, but pretty much perfect at recognising text. Next time a news website posts an image of new covid rules with no alternatives (as the main Dutch news website used to do throughout the pandemic), users of Edge can follow along.

Empty links and buttons#heading-3

When links, buttons or other interactive elements don’t have names, assistive technologies like screenreaders or voice controls have no way to uniquely refer to them. If it is to be interacted with, it needs a name.

Names are derived from text content, like the actual text that’s inside a button, or can be added through an attribute. See Naming things to improve accessibility for more detail or the spec that defines how controls get their names.

Developers need to ensure all controls they build (links, buttons, form fields, etc) have names, ideally that make sense out of context:

<!-- names that make sense out of context -->
<button>Submit form</button>
<button>Publish content</button>
<button>Expand filters</button>
<a href="//wikipedia.org">Wikipedia</a>
<a href="//twitter.com">Hidde on Twitter</a>

<!-- names that are confusing -->
<a href="/">click here</a><!-- avoid -->
<a href="/>read more</a><!-- avoid -->

<!-- names that are missing; avoid or add a name -->
<a href="//twitter.com/"><svg/></a><!-- avoid -->
<a href="//linkedin.com"><img src="" alt="" /></a><!-- avoid -->
<button><img/><button><!-- avoid -->

Browsers can sometimes derive names from nearby text, some do this when there is no text to derive a name from. This is not ideal, can lead to wrong and confusing guesses and be bad end user experience. The developer of this control will know best what the thing does and therefore how it should be named.

Missing form labels#heading-4

Form labels kind of fall under naming things, as they name form elements specifically.

Developers can fix this by ensuring form fields have a element of which the for attribute points to the id of the input/select/ textarea , this also makes that clicking label moves the cursor to the input:

<!-- “for” and “id” are same, this connects them -->
<label for="field">Address</label>
<input id="field" />

They can also add an aria-label attribute to the input to name it that way (but be careful, ARIA labels don’t get translated well).

Missing languages#heading-5

Proper language indication can get you a Pass on two (!) WCAG Success Criteria (3.1.1 and 3.1.2), and you only need to know one attribute for it.

Developers should ensure the element has a lang attribute with the right language:

<!-- marks this document as 'in English -->
<html lang="en">

Sometimes this is forgotten as the <html> element lives in some template you never touch, but it’s not hard to do, so always double check that this attribute exists and is set to the right language.

If there is content on part the page that is in another language, mark that too, again, with a lang attribute on the relevant DOM node. When you pick a plugin for internationalisation, ensure it sets the lang s or makes it easy for you to do so.

CMSes can make sure that lang attributes are set and set correctly. Browsers can guess languages, but they aren’t always good at this, specifically when it comes to distinguishing dialects: they often matter a lot to people, less so to machines.

Wrapping up#heading-6

These are some tips based on the most common issues that WebAIM Million 2022 identified. Let’s all put in the work to make sure we, our colleagues, our clients and our users avoid these issues. Like, actually. We need WCAG auditors to focus on higher hanging fruit, by fixing the lower hanging stuff for good.

If this is all new to you, hi, thanks for reading! I hope this helps and feel free to get in touch with questions. If you already knew all of this, please keep spreading the word, so that in next year’s survey, we’ll see steady improvements for the web at large.

Want to learn more about fixing low hanging fruit accessibility issues? In response to the same survey, Christian Heilmann blogged about how to fix accessibility issues using your browser