It's easier when you do it earlier

category: thoughts

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:

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 & mentions (47)

Sami Keijonen likes this
Koen Kivits likes this
Kasper Kamperman likes this
Kilian Valkhof likes this
Meagan Eller likes this
Bram Smulders likes this
Enrique Sánchez likes this
Bakki likes this
Monique Dubbelman likes this
Alex James likes this
Jan Skovgaard likes this
IAAP D·A·CH likes this
Marek likes this
Brad Czerniak solves it once! likes this
Jens Grochtdreis likes this
tommy george likes this
Alisa Person likes this
Zugang für alle | Access for all likes this
Rufus Witt likes this
Jess Cahill likes this
Rian Rietveld reposted this
Bram Smulders reposted this
Bakki reposted this
Fronteers reposted this
Meagan Eller reposted this
Sami Keijonen reposted this
Guillaume Deblock reposted this
Eric Bailey reposted this
Marek reposted this
Accessabilly reposted this
Zugang für alle | Access for all reposted this
Jess Cahill reposted this
Terry O'Brien replied: Nice article Hidde, thanks!
Hidde replied: thank you!
Deborah Edwards-Oñoro replied:
Yep. hiddedevries.nl/en/blog/2021-0… #a11y #accessibility
Kilian Valkhof replied:
Like many things it's easier to bring accessibility considerations in earlier in the process. Hidde explains why, and how:
IAAP D·A·CH replied: Good read! Totally agreed: "making accessibility part of the agile process"
Lireo Designs replied:
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 replied: “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 replied:
"Web accessibility becomes easier and cheaper, when you address it earlier." hiddedevries.nl/en/blog/2021-0… #A11y #Accessibility
The Paciello Group replied:
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 replied:
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 replied: It's easier when you do it earlier, by @hdv hiddedevries.nl/en/blog/2021-0…
Johan Ramon replied:
It's easier when you do it earlier: hiddedevries.nl/en/blog/2021-0… #accessibility #a11y
Emmanuel DEMEY replied: Accessibility, It's easier when you do it earlier hiddedevries.nl/en/blog/2021-0… #accessibility
Michael Mathews replied:
I's easier when you do it earlier #a11y #accessibility hiddedevries.nl/en/blog/2021-0…
TetraLogical replied: 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
Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.