Accessibility Approach

How we design and build for everyone

Effective date:

July 2, 2026

Contents

Our Position on Accessibility

Accessibility is not a feature we add at the end. It is a design constraint we work within from the start, like performance or security. When we treat it as a bolt-on, we produce work that fails audits, frustrates users, and costs more to fix. When we treat it as a default, we tend to produce better work for everyone.

Our target is WCAG 2.2 Level AA. That is the standard referenced in most legal frameworks in the US, UK, EU, and Australia. We do not pursue AAA compliance across the board, though specific components may meet it incidentally.

This document describes how we interpret those guidelines in practice — what we actually do, in what order, and why.

‍

Who We Are Designing For

Roughly one in five people in most countries has some form of disability. That number rises when you factor in temporary situations: a broken arm, recovery from eye surgery, a bright outdoor screen, or a loud environment where no one can listen to audio.

The groups we think about most directly when making accessibility decisions:

  • People who are blind or have low vision and use screen readers or magnification
  • People who are Deaf or hard of hearing and rely on captions, transcripts, or visual cues
  • People with motor impairments who navigate using keyboards, switch devices, or voice control
  • People with cognitive disabilities who benefit from consistent layouts, plain language, and predictable interactions
  • People in temporary situations that create the same constraints as a permanent disability

These groups are not edge cases. They are users. Designing for them generally makes the product cleaner for everyone else too — plainer copy, fewer unnecessary interactions, faster keyboard navigation.

‍

Standards and Legal Context

WCAG 2.2 Level AA

The Web Content Accessibility Guidelines are published by the W3C and organized around four principles, often called POUR: Perceivable, Operable, Understandable, Robust. Each principle breaks into specific success criteria at three levels: A (minimum), AA (standard), and AAA (enhanced).

We target AA. In practice, that means things like sufficient color contrast, keyboard accessibility for all interactive elements, visible focus states, descriptive link text, and form inputs with proper labels.

Legal Landscape

In the United States, the ADA and Section 508 apply depending on the type of organization and product. The EU Web Accessibility Directive and the European Accessibility Act (EAA, applying from June 2025) set similar or stricter requirements across member states. The UK Equality Act covers private sector digital products in most cases.

The honest summary: most digital products serving the public face real legal exposure if they are not broadly accessible. Courts have consistently interpreted WCAG AA as the relevant benchmark in settlement agreements and rulings.

‍

Accessibility in the Design Phase

Most accessibility failures originate in design, not development. If a component has no keyboard interaction model, no visible focus state, and insufficient contrast in the mockup, the developer is being asked to solve a design problem in code. That rarely ends well.

Color and Contrast

Text at normal size needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt regular or 14pt bold and above) requires 3:1. UI components and graphical elements that carry meaning need 3:1 against adjacent colors.

We check contrast during design, not after. Tools like the Figma Contrast plugin or Stark make this fast. The goal is to resolve contrast issues before any design is handed off.

Focus and Interaction States

Every interactive element needs a visible focus state. Not 'the browser default', which is often inadequate. A designed focus ring: typically a 3px solid outline with a 2px offset in a color that contrasts against both the component and page background.

If a designer does not specify focus states, we ask for them. We do not invent them in development without design input.

Typography and Layout

Body copy should be set at a minimum of 16px. Line height between 1.4 and 1.6 for paragraph text. Line lengths between 60 and 80 characters for comfortable reading. These are not accessibility requirements strictly speaking, but they affect readability for people with dyslexia and cognitive disabilities.

Layouts should reflow usably at 400% zoom. If a layout breaks at that zoom level, it will also break for users who rely on browser zoom.

Motion and Animation

Any animation that is non-essential should respect the prefers-reduced-motion media query. Flashing or strobing content above 3 Hz can trigger seizures and is a hard no under WCAG 2.3.1.

‍

Accessibility in Development

Semantic HTML First

Most accessibility problems come from ignoring or overriding the browser's built-in semantics. A button that is actually a div, a list rendered as separate spans, a heading that is just bold text — these all break screen reader navigation and keyboard access.

Use the element that matches the meaning. If something is a heading, use h1 through h6 in correct hierarchical order. If something is a list, use ul or ol. If something is a button, use button. The browser provides a great deal of accessibility behavior for free this way.

ARIA: Use Sparingly

ARIA (Accessible Rich Internet Applications) exists to bridge gaps where native HTML does not cover a pattern. It should not be used to paper over semantic mistakes. The first rule of ARIA is not to use ARIA if a native element can do the job.

Where ARIA is genuinely needed — custom disclosure widgets, comboboxes, live regions — use established patterns from the ARIA Authoring Practices Guide rather than inventing from scratch.

Keyboard Access

Every interaction available with a mouse must be available with a keyboard. Tab moves through focusable elements in DOM order. Arrow keys control grouped elements (tabs, menus, radio buttons). Enter and Space activate controls. Escape closes overlays.

Focus must be managed when content changes. If a modal opens, focus moves to it. When the modal closes, focus returns to the trigger element. This is not optional behavior — without it, keyboard and screen reader users lose their place in the page.

Images and Media

Informative images need alt text that communicates the content or function of the image, not a description of what it looks like. An image of a line chart showing revenue growth should not have alt text of 'chart.png'. It should describe the trend or, for complex data, reference a longer text description.

Decorative images that add no information should have an empty alt attribute (alt=''), which tells screen readers to skip them.

Video content needs captions. Audio-only content needs a transcript. Both need to be accurate — auto-generated captions alone do not meet the standard.

Forms

Every form input needs a label element associated via the for attribute and a matching id on the input. Placeholder text does not count as a label. Error messages need to be programmatically associated with the relevant input, not just displayed nearby.

Error messages should tell the user what went wrong and how to fix it. 'Invalid input' is not a useful error message. 'Email address must include an @ symbol' is.

‍

Testing

Automated Testing

Automated tools catch approximately 30–40% of WCAG failures. They are fast and cheap, so we run them — but they do not replace manual testing.

We use axe-core integrated into our development workflow. Developers run it locally. It runs in CI. Any failures block deployment. This catches missing alt text, contrast failures, missing labels, and a range of ARIA errors reliably.

Manual Keyboard Testing

Before any component or page ships, a developer navigates the full user journey using only a keyboard. The checklist is short but non-negotiable:

  • All interactive elements are reachable via Tab
  • Tab order follows a logical reading sequence
  • Focus is always visible
  • No keyboard traps (other than intentional ones in modals)
  • All interactions can be completed without a mouse

Screen Reader Testing

We test with NVDA on Windows using Firefox, and VoiceOver on macOS using Safari. Those two combinations cover the most common usage patterns in real-world data. JAWS on IE is no longer a meaningful target for most projects.

Screen reader testing is conducted at minimum on: the primary navigation, any modal or dialog, form flows, and complex interactive components.

User Testing with Disabled People

Automated and manual testing by non-disabled developers finds many problems. It does not find everything, and it does not tell us whether the solutions we have implemented actually work for real users.

Where project scope allows, we include participants who use assistive technology in usability testing. Specialist agencies can recruit these participants if we do not have them in our own research panel.

‍

Content Accessibility

Technical compliance does not equal an accessible experience. A screen reader can announce every element on the page correctly while the page remains incomprehensible.

Plain Language

Write at a reading level appropriate for your audience, but err toward simpler. Use short sentences. Prefer common words over technical ones where both work. Avoid idioms that do not translate well across cultures or for non-native speakers.

Aim for a Flesch-Kincaid reading level around 8th grade for general audience content. Not because users are incapable of reading more complex text, but because plain writing is faster to process for everyone.

Headings and Structure

Headings are the primary navigation mechanism for screen reader users. A logical heading structure — one h1 per page, then h2 for main sections, h3 for subsections — allows users to scan and jump to content without reading everything.

Do not choose heading levels for visual size. Set the size with CSS. Use the level that reflects the document structure.

Link Text

Links should make sense out of context. 'Click here', 'read more', and 'learn more' are all failures. Screen reader users can pull up a list of all links on a page; a list of twelve 'read more' links is useless.

'Download the 2024 annual report' is good link text. 'Download the annual report (PDF, 2.4 MB)' is better — the file type and size help users decide whether to follow the link.

‍

Maintaining Accessibility Over Time

A site that passes an audit today can fail one a year from now. New components get added. Third-party scripts update. Editors add content without considering accessibility.

Accessibility in the Definition of Done

Accessibility criteria belong in the acceptance criteria for every ticket that touches UI. Not as a separate checklist item that gets skipped when time is short, but as part of what done means. If a component does not pass keyboard testing, it is not done.

Regression Testing

Automated accessibility testing in CI catches regressions. Developers who introduce a new violation get immediate feedback, which is far cheaper than catching it in a QA cycle or audit.

Accessibility Statements

We recommend clients publish an accessibility statement that describes the standard they are targeting, how they have tested, known issues, and how users can report problems. This is a legal requirement in some jurisdictions and a reasonable expectation in most.

Audits

An internal audit once or twice a year, covering a representative sample of pages and user journeys, is enough to catch drift. External audits make sense before major launches or when there is legal pressure. We can scope and conduct these as part of a project or as a standalone engagement.

‍

Reference and Resources

The standards and tools we reference most often:

‍