It's easier when you do it earlier

Web accessibility becomes easier and cheaper, when you address it earlier. In this post, we’ll look at various ways to do that, like picking the right CMS and making accessibility part of the agile process. Combine them for maximum effect.

A quick disclaimer before we start: while this post is about web accessibility, the same probably goes for web security, web privacy and other important aspects of a healthy web.

To make websites accessible, most organisations choose to follow the Web Content Accessibility Guidelines (WCAG). It’s also the standard most governments embed in their rules. Meeting WCAG does not guarantee accessibility, but the standard is a good baseline. It is our best bet as a shared understanding ‌of what ‘this is accessible’ means.

Choose a CMS that helps with accessibility

WCAG is about the accessibility of content, so it makes sense to optimise what we do when we create content. We could pick CMSes that help editors create accessible content. In my talk “Your CMS is an accessibility assistant”, that I did last year, I discuss just that.

What if a CMS, when you add a video, prompts for subtitles? What if it, when you place text on a hero image, it helps you pick a color that has sufficient contrast, or suggests to add a background color? Some CMSes already ship with features like this.

WordPress’s Gutenberg editor, for instance, will tell you when you’re starting to use colours with insufficient contrast:

white text and light gray background, with on the right a color settings panel that shows a warning saying the color combination may be hard to read and suggests making the background darker

Features like this are super helpful, because they let us spot accessibility issues early in the process. Without them, we may have only found out about problems once the functionality went live and got audited. With good early warning systems, WCAG audits can focus on the more complex issues.

Check accessibility with every user story

A lot of web projects rely on some form of agile project management, many move new functionality through a set of stages. If you can build accessibility steps into the process, somewhere before the last stage, you can find and fix accessibility problems before they go live.

There are many ways to do this. You may not want to do a full WCAG audit on each piece of functionality, but I’ve seen teams leverage checklists that address low hanging fruit. When you combine a bunch of fairly easy to execute manual checks with some automated accessibility checker, you will likely be able to address problems while they emerge. For instance, add that keyboard handler while you’re building the widget, rather than following a formal accessibility audit months after the feature initially launched.

Some checks you could include are:

  • do the automated checks (for instance from axe-core, Tenon, Polypane or Siteimprove) return zero issues? Note, automated checks can only check 10-30% of WCAG issues, don’t rely on just automated checks
  • can all controls in the feature be used with only a keyboard?
  • can you still use everything if the browser is set to 400% zoom?
  • for all form inputs, does the input activate when you click on the label?
screenshot of terminal window running axe and another screenshot of wikipedia zoomed in 300%

Checklists have caveats though… the most important is to realise that “what’s most easy to check” is not necessarily the same as “what’s the most important to check”. It would be quite the coincidence if it was. But having said that, easy checks are probably the checks that are most feasible to include with each piece of functionality.

Level up on HTML proficiency

A large portion of issues I find in my WCAG audits relates to HTML and how to use it. Developers who know the HTML spec inside out are at a massive advantage when it comes to the WCAG compliance of the product they work on. Which elements to use when, how to build forms, what attributes exist for tables… it will all help write more accessible code.

For instance, developers who are aware that input-elements have an autocomplete attribute, will have no trouble meeting Identify input purpose (Success Criterion 1.3.5, which requires that attribute for form fields that collect personal information).

Ensuring new developers can bubble sort may be important to your business goals, but so is testing for HTML proficiency. Even, maybe especially, when you interview a full stack developer for your team, make sure you also interview for the HTML bit of the stack. It will help the team create accessible code from the start.

Wrapping up

In conclusion, with the right CMSes, checklists for every user story and high levels of HTML proficiency, teams can get a lot of their accessibility right early in the process. These all may all seem like no-brainers, but I’ve only seen very few organisations adopt them. I’m curious if others have more strategies for putting accessibility earlier in the process, please do reply via email or Twitter, or in the comments below.

Thanks Kilian and Bram for their helpful comments on earlier drafts.

Comments, likes & shares (61)

Terry O'Brien wrote on 4 February 2021:
Nice article Hidde, thanks!
Hidde wrote on 4 February 2021:
thank you!
IAAP D·A·CH wrote on 5 February 2021:
Good read! Totally agreed: "making accessibility part of the agile process"
Kilian Valkhof wrote on 5 February 2021:
Like many things it's easier to bring accessibility considerations in earlier in the process. Hidde explains why, and how:
Lireo Designs wrote on 5 February 2021:
If you can build accessibility steps into the process, somewhere before the last stage, you can find and fix accessibility problems before they go live. hiddedevries.nl/en/blog/2021-0… #WebDesign #accessibility
Fynn Becker wrote on 9 February 2021:
“Ensuring new developers can bubble sort may be important to your business goals, but so is testing for HTML proficiency.” hiddedevries.nl/en/blog/2021-0…
Huxley wrote on 9 February 2021:
"Web accessibility becomes easier and cheaper, when you address it earlier." hiddedevries.nl/en/blog/2021-0… #A11y #Accessibility
The Paciello Group wrote on 9 February 2021:
The earlier web accessibility is addressed in a project, the easier and cheaper it becomes. It's easier when you do it earlier hiddedevries.nl/en/blog/2021-0… #Accessibility #A11y
Eric Eggert wrote on 10 February 2021:
My pal @hdv did drop a truth bomb last week: It's easier when you do it earlier hiddedevries.nl/en/blog/2021-0…
CSS Basics wrote on 24 February 2021:
It's easier when you do it earlier, by @hdv hiddedevries.nl/en/blog/2021-0…
Johan Ramon wrote on 26 February 2021:
It's easier when you do it earlier: hiddedevries.nl/en/blog/2021-0… #accessibility #a11y
Emmanuel DEMEY wrote on 1 March 2021:
Accessibility, It's easier when you do it earlier hiddedevries.nl/en/blog/2021-0… #accessibility
Michael Mathews wrote on 1 March 2021:
I's easier when you do it earlier #a11y #accessibility hiddedevries.nl/en/blog/2021-0…
TetraLogical wrote on 5 March 2021:
It's easier when you do it earlier, advice on making accessibility part of your agile process by @skyatlantic hiddedevries.nl/en/blog/2021-0… #accessibility #agile #planning
TetraLogical wrote on 4 June 2021:
It's easier when you do it earlier. @hdv explains: hiddedevries.nl/en/blog/2021-0… #CMS #UserStories #HTML #accessibility
Raph wrote on 23 June 2021:
"It's easier when you do it earlier" Read the blog of Hidde de Vries about organizing web accessibility properly. Hidde looks at various ways to do that, like picking the right CMS and making accessibility part of the agile process. hiddedevries.nl/en/blog/2021-0…
The A11Y Project wrote on 24 June 2021:
"Web accessibility becomes easier and cheaper, when you address it earlier." @hdv hiddedevries.nl/en/blog/2021-0…
lukeb3000 wrote on 4 July 2021:
Web accessibility becomes easier and cheaper, when you address it earlier. You can get a lot of accessibility right early in the design process, read how to do that here - hiddedevries.nl/en/blog/2021-0… #accessible #accessibility #inclusive #a11y #DigitalAccessibility
@wnas wrote on 8 July 2021:
@hdv vraagje over je blogpost hiddedevries.nl/en/blog/2021-0… Je noemt 400% zoom, is dat geen 200%? “can you still use everything if the browser is set to 400% zoom?”
you do a great blog, Hidde!