Accessibility tooling for web developers

Posted on

Table of contents

Introduction and Summary

This article describes how using accessibility (a11y) guidelines and tooling can help make optimal web development decisions and what tools support the development process.

This post does not include concrete tool setup or usage instructions.

The post is aimed at web developers who have little to no accessibility tooling knowledge and/or need a solid foundational web development skill to build on top of.

This post assumes that you have basic understanding of web development.

No prerequisite reading required.

Summarized key points for the busy:

  • Making websites accessible can possibly attract a wider audience of people.
  • It is easier to advocate an engineering decision if an accessibility guideline supports it.
  • Accessibility linters are a low effort, easy set up way to help catch up to half of accessibility issues in source code during development.
  • Lighthouse accessibility auditing helps catch accessibility issues in a website as a whole.
  • Screen reader testing helps to catch accessibility issues that linter and lighthouse testing miss. This testing is best used when doubts arise during development and before releasing to the users.
  • Reading Web Content Accessibility Guidelines is a good way to gain expanded knowledge of a11y.
  • Before making development decisions asking “is this possible solution accessible” early could help pick an optimal solution saving time and energy.

Personal experience

“Is <div> a proper element for {some use case}?”

“Can a paragraph have a list nested inside?”

“Is it a good practice to do {some use case}?”

These are questions I used to ask myself after starting web development. After joining a design system team in a corporate company I used to work at accessibility became a job skill requirement. While learning accessibility I slowly went from often doubting development decisions to having a pillar I can always lean up against, which brought optimal decision making and in turn confidence as a developer.

The importance of accessibility in the digital world

Accessibility most often refers to the principles and guidelines that aim to enable digital platforms (e.g. mobile apps and websites) to be used by anyone regardless of ability or age. Accessibility:

  • Depending on country is required by law for public companies who have digital platforms.
  • Builds a good business case since about 1 in 6 people experience significant disability according to World Health Organization.
  • Helps with bringing more traffic to digital platforms by working hand in hand with Search Engine Optimization.
  • Is required on web developer and designer job postings.

In the engineering process, accessibility provides constraints on how to build web applications which saves energy by avoiding overthinking on for example what HTML elements to use. A quick test with automated a11y tooling and most common issues can be found. A longer test with a manual a11y testing tool and most hidden issues can be found. Fixing those issues brings confidence since then almost anyone, regardless of ability level, can use the website! Furthermore, making websites accessible makes them more compliant than 95% of websites on the internet (according to webaim WCAG Conformance statistics).

In a team context, upholding a11y may save time and money. In discussions about new features and bugs it is worth asking the question “is the possible solution accessible” which, if asked early, helps to rule out suboptimal ideas faster. Furthermore it is easier to advocate an accessibility based answer since if it’s not accessible it’s the same as ignoring the user experience of 1 in 6 people who may want to use the product.

Accessibility tooling for web developers

There are automatic and manual accessibility testing tools. Using automatic tooling is a very easy recommendation and can find up to half of possible issues depending on the website’s complexity. Manual testing requires more effort and knowledge in the beginning but can identify more hidden but just as important issues. These are the tools I personally have used throughout my career.

Accessibility linters

What it is - accessibility linters help with providing instant feedback when writing code.

Why use it - this is by far the easiest way to get quick accessibility feedback during development. It can be included in continuous integration pipeline, stopping builds from deploying in case any issues are detected.

When to use it - always when writing HTML.

It is also essential when working in a team to raise the compliance floor for everyone.

The most common a11y linting tool in web development is eslint with specific implementations for each frontend framework:

With these it is common to use an IDE extension such as https://github.com/microsoft/vscode-eslint for Visual Studio Code while WebStorm provides support out of the box.

Lighthouse auditing tool

What it is - lighthouse auditing tool helps by checking for accessibility issues on the fully rendered website.

Why use it - unlike the lint tools which run checks on the source code, lighthouse checks the fully rendered website which helps find more possible issues.

When to use it - after the linters pass successfully and usually right by the end of developing a feature.

Auditing with lighthouse is simple as some major browsers (e.g. Chrome, Edge) have it already integrated into developer tools while other browsers have plugins that can be installed. Using it is as simple as opening the developer tools window, navigating to lighthouse and pressing “Analyze”. The analysis output displays all issues found as well as everything that passed the audit which is a great learning opportunity.

Screen Readers

What it is - it’s a tool that people with physical disabilities use to navigate websites.

Why use it - this is by far the most useful test that can be made since it simulates a real person interacting with the website. It allows catching bugs which are not caught by linters and lighthouse.

When to use it - as the last step of feature development right before the whole feature is released for the users or during development when in doubt.

Common issues that are caught by screen readers that may be missed by linters:

  • Dynamic content inaccessible (e.g. popups/toasts not read, unable to navigate dropdowns).
  • Inconvenient navigation (e.g. headings used for styling instead of structural hierarchy).
  • Keyboard/focus traps (e.g. user unable to navigate outside of an element).

This way of testing is important when using frontend frameworks (e.g. React, Vue, Angular) since we often work on individual web components which are then integrated into whole web pages. Depending on how the individual components are developed, they may break accessibility in multiple ways.

Web Content Accessibility Guidelines

Web Content Accessibility Guidelines (WCAG) can be used to learn more about a11y but in a more abstract way. The guidelines document is intimidating due to the amount of text and I personally read it only when I aim to learn a11y in a more general way. I recommend the more approachable and engaging W3Cx Introduction to Web Accessibility course as a first step.

If I were to learn accessibility again

If I were to start over with zero accessibility knowledge, I would:

  1. Watch the W3Cx Introduction to Web Accessibility course for the general understand of what it is and why it is needed.
  2. Install linters with IDE extensions to get instant feedback during development.
  3. Occasionally run Lighthouse accessibility audit and read through the failed and passed audits for learning purposes.
  4. Learn to use screen readers and use them to test websites.
  5. Read WCAG for deeper understanding.

There is a lot to learn but a pragmatic learn-by-doing approach helps when energy and attention is limited.

Share this post: