Accessibility

Accessible by design,
and kept that way

We audit your website, app or product against WCAG, make the fixes in your code and add checks to every release, so it stays usable for the people who rely on it.

Thanks, we’ll be in touch soon.

{{ heroStatus }}

{{ heroSay }}

You’re in good company

A few of the companies we’ve worked with.

{{ wallSay }}

Barriers you can’t see from your own screen

It’s easy to check a product only with a mouse, a large screen and good eyesight. People who move through it by keyboard, listen to it with a screen reader, zoom in to read it or speak commands to it can meet a different product: a button with no name, a form they can’t finish, a menu they can’t leave. None of it shows on the screen you test with.

One standard to measure against

The Web Content Accessibility Guidelines (WCAG), published by the W3C, describe how to make web content more accessible, as testable success criteria at three levels: A, AA and AAA. We audit against the current version at level AA, unless you need another, and report each issue against the criterion it fails, so your team can check every finding for itself.

From WCAG 2.2

4.1.2 Name, Role, Value

Level A
What it asks
Every control, such as a button, a link or a form field, can tell assistive technology what it’s called and what kind of control it is. Whatever a person can change, assistive technology can change too, and it’s told when something changes.
How it’s checked
Each control is checked for what assistive technology receives: its name, its role and, where it has one, its state, before and after it changes. A menu button with no name fails it.

What we do

From the first audit to keeping it fixed.

Audits

Your key journeys checked against WCAG by people, with automated scans for the rest. Each issue comes with where it is, who it affects and how to fix it.

  • Fixes in your code

    The changes made in your codebase, or alongside your team as they make them, each one tested.

  • Design reviews

    Designs checked before they’re built: contrast, focus, structure, labels and motion.

  • Accessible components

    Buttons, menus, dialogs and forms built to work with a keyboard and a screen reader, so every page that uses them starts from accessible parts.

  • Checks in every release

    Automated checks in your pipeline that catch the issues a tool can find before they ship, and a short manual check for what tools can’t judge.

  • Testing with assistive technology

    Keyboard only, screen readers and zoom, on the browsers and devices your users have.

Tools find some issues, people find the rest

Automated scanners are quick, and they can catch issues such as missing text alternatives or low contrast. Whether a label makes sense, the focus moves in a sensible order or a page reads aloud the way it looks takes a person who knows how people use assistive technology. So every audit combines both, and says what was tested and how.

Kept accessible in every release

Accessibility can slip back when it’s fixed once and then left. We add checks to your pipeline that stop a known issue from returning, make accessible components the default, and add a short manual check to your release routine, so new work is checked as it’s built instead of waiting for the next audit.

Start with the journeys that matter

We begin with what people most need to do in your product, such as signing up, buying or getting help, and audit those journeys first. You get the issues ranked by how much they get in people’s way, the worst of them fixed, and checks that help keep them fixed, before deciding how far to take it.

Questions worth asking

Which version of WCAG do you audit against?

The current one, WCAG 2.2, at level AA, unless you need another. W3C designed it so that content that meets WCAG 2.2 also meets 2.1 and 2.0, the versions some rules still name.

Do we have to meet WCAG?

It depends on who you serve and where. In the US, the Department of Justice’s rule for state and local governments under the Americans with Disabilities Act currently names WCAG 2.1 at level AA for their websites and mobile apps, and the Section 508 standards name WCAG 2.0 at level AA for the technology federal agencies build, buy and use. The EU has its own rules for some products and services. Your legal team decides what applies to you; we show what the standard asks and help you meet it.

Can a tool or plugin make our site accessible?

Tools help find some issues, but on their own they can’t tell whether a product is accessible. We make the fixes in the code itself, so they stay part of the product.

What does an accessibility audit cost?

It depends on which journeys we audit, the platforms they run on and how much needs fixing in your code. The first call is free. Your proposal sets out the scope, the price or rate, and how you pay, before any work starts. Pricing →

Let’s design it better

Tell us which parts of your product matter most and who relies on them. We’ll suggest where to start.

Thanks, we’ll be in touch soon.

{{ ctaStatus }}