Guardrails for better accessibility support in frontend

Updated on April 19, 2023 with quote from latest WebAIM 2023 report

Ridiculous 45 degree staircase ramp with a sign for wheelchair access, next to a wooden staircase

The web is accessible by architecture

The polyglot nature of the web allows for the use of any language, server, operating system, hardware, and location unless it adheres to web protocols and standards. HTML with its declarative nature, is the semantic foundation that explicitly enables that content is accessible.

About 16% of all humans in the world have some kind of disabilities (source). But today’s complexity of web applications—sometimes combined with lack of enough knowledge, awareness or even care among stakeholders and project members—leads to challenges and limitations for people with disabilities to interact with the world online (if you need a refresher I recommend to watch this talk and see how people with disabilities use the web).

The WebAIM Million report of 2023 detected that, still,

96.3% of home pages had detected WCAG 2 failures! This improved very slightly from 96.8% in 2022. Over the last 4 years, the pages with detectable WCAG failures has decreased by only 1.5% from 97.8%. These are only automatically detected errors that align with WCAG conformance failures with a high level of reliability. Because automatic testing cannot detect all possible WCAG failure types, this means that the actual WCAG 2 A/AA conformance level was certainly lower.

And the most common errors are trivial to fix.

No discussions

Exclusion will happen unless product creators learn from
people with disabilities, apply insights to product creation, and extend benefits across a broad range of people
—Microsoft Inclusive Design Toolkit (PDF)

So, there should be absolutely no discussion that we web workers embed true inclusive design into our digital products. (Both inclusive design and accessibility are user-centered approaches that seek to design products and services that meet the needs of all users.)

It is essential to prioritize accessibility in all stages of our product development process when creating web solutions. By doing so, we can avoid the higher costs of retrofitting accessibility at a later stage, which also carries the added legal risk of potential lawsuits. Also, accessibility is not a feature to be added separately (see also other accessibility myths).

Notice: From now on I will use the term a11y, a numeronym and shorthand for accessibility.

How to start

Ok, with the hope that most what has been written in the intro part is known to you as a developer already, the main question is:

How you can start doing it “right”?

This article aims to guide frontend developers to establish a baseline for better a11y support in their projects, so that it becomes a natural part of the project work.

Topics overview

How easy your developer path is for a better a11y support depends highly on the maturity of accessibility in your organisation, so some of the following topics might be easier to address, some might be trickier.

1. Update your a11y knowhow

The first step might be to bring your own knowledge around a11y up to date. This is enables you to implement the appropriate bits and pieces properly and regularly educate other team members who might not so familiar with all of the aspects.

There are so many good resources out there, but these should get you started:

Courses:

2. Get involved early

Frontend engineers should be involved early on in projects to have an eye on a11y topics right from the beginning to reduce implementation challenges as early as possible. Although I would assume most of us are working in agile environments and are involved early, it still may occur that you feel included or briefed too late, for example when design work has been started already.

In bigger companies it might be even more important to raise this awareness towards managers. For them there is a good explainer on accessibility here, too.

3. Identify project’s a11y requirements

In a project you join, you should ask if specific A11y requirements exist or have been communicated and documented, for example

4. Enforce WCAG Level A support in MVP

Getting WCAG Level A compliance is the absolute minimum implicit goal to aim for, even if no explicit a11y requirements have been documented in the previous step.

If this isn’t met, assistive technology may not be able to read, understand, or fully operate the page or view. Level A addresses access barriers that make it otherwise impossible or extremely difficult for people with disabilities to interact with something.

Level A in a nutshell means:

  • Support for keyboard usage incl. recognisable focus indicators and logical tab focus order
  • Respecting and reacting on browser and operating system settings, e.g. font sizes, zoom, contrast
  • Allowing screen readers to read out content loud based on correct semantic structures and wisely used ARIA attributes
  • Enabling content navigation via voice

Try to prevent to completely skip a11y support in MVPs: By fully ignoring it, and trying to add it later (e.g. as part of “reduce tech debt” plannings) it will be decoupled from the core product and more likely be seen as a feature to potentially be prioritised down.

Even if you cannot achieve 100% level A compliance immediately in a MVP, at least try to get there as early as possible.

Depending on the a11y requirements identified in step 3 you might need to achieve level AA at some point. This might be already enough of a challenge in complex project environments especially when a11y hasn’t yet received broad awareness among stakeholders and all members of a product team. So it is recommended to focus first on a solid support for level A and then go from there.

5. Put a11y into acceptance criteria

During backlog refinement or sprint planning sessions, before starting any frontend coding, the whole team should collaboratively discover and document a11y requirements in the form of acceptance criteria. A11yBID might be a good process to apply:

“A11yBID” is an extension of Behavior Driven Development (BDD) and “is a powerful agile development process that can help teams shift accessibility left and reduce future costs of remediation. Teams can use it to efficiently discover and formulate quality accessibility requirements and document them in a human-friendly format that’s also testable before development even starts.”

Read more: Collaborative planning, the forgotten step of accessible development

6. Assess current a11y state

If you join an existing project, this guide might help you “to assess the accessibility of a web page. With these simple steps, you can get an idea whether or not accessibility is addressed in even the most basic way.”

A good first indicator is also when you (try to) use the application purely with a keyboard. If you have troubles interacting with it in the intended way and/or if you don’t recognise focus outlines when using the tab key, this gives a hint where to start fixing (see next step).

Running audits with tools like Lighthouse or axe DevTools provide first insights quickly, too.

7. Team up with designers

The times should be over that design assets are “thrown over the fence” in order for frontend developers to implement the UI for the web. Instead, a constant iterative collaboration together—and as often as possible in the browser as user’s medium—is the modern and most efficient way to develop an innovative digital product.

Within that team work it is important to steadily align with designers about the following topics:

  • Raise awareness on accessibility for UX and UI designers as a11y support is not the job of developers only
  • Agree on a joint UI component system (e.g. Ionic or others which provide good a11y support) and commit together to stick to their default components and functionalities
  • Participate in the development and maintenance of a design system
  • Analyse existing UI elements and agree to leave out troublesome UI components (like text inputs, time inputs, date-picker, tooltips) at least in the first or early project stage(s), strive for simple to use UI elements - if some more complex elements are absolutely needed then you should clearly communicate implications on higher coding and testing efforts to make and keep them accessible over the product lifecycle

Use this reference of accessible HTML content patterns “as a starting point when creating your base markup and styling for a stable, progressively enhanced foundation to your site or app, or cherry-pick as needed.” At a later stage of the project, progressively enhance the UI when at least WCAG level A has been reached.

You might find these links helpful to give to designers:

8. Setup tooling

There are a few easy steps to incorporate a11y testing right from the start in the frontend stack, manually and automatically.

Regular manual testing

Automated testing

Automated a11y testing can never replace manual testing, but can identify common failures against WCAG success criteria fast during the development.

So, start with automation! It’s easy to set up:

  • If you use Jest for unit tests, we found jest-axe easy to configure and perfect to check against a11y violations as part of each unit test. It is best practice to run tests in the CI/CD pipeline, so these a11y checks are automatically part of pipeline runs then.
  • And if you use React and eslint, we can also recommend eslint-plugin-jsx-a11y for static code analysis of your files.

By adding both libraries to unittest- and linting stage you get into a steady a11y awareness on code-level. With that you can focus on the more obvious issues first and on the more tricky ones afterwards, which anyway cannot fully be detected via automation.

And as you attach a11y testing to the (hopefully) existing testing and linting workflow, a11y in general isn’t separated into its own topic, which otherwise might be perceived as optional to tackle with low priority.

Having a solid tooling in place, you then can add monitoring and do a11y audits regularly.

More tools

Conclusion

Independent of the accessibility maturity of a frontend developer’s environment, concrete steps can be taken as a developer to improve accessibility support in digital products. It may take a longer breath but I hope this article could give motivation, inspiration and helpful further links to take action. Because accessibility is good for all of us.