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:

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?

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.

---

Originally posted as It's easier when you do it earlier on Hidde's blog.

Reply via email