Accessibility: Open to everyone.
People use the web in different ways. We consider those differences in design and code, then test the experience beyond how it looks on our own screens.
Join the waiting list
Nobody left
at the door.
A good fit when…
You need to understand barriers in an existing site or build inclusive behaviour into a new one.
What’s included
- Accessibility reviews and remediation plans
- Keyboard and focus behaviour
- Semantic structure and form improvements
- Testing across assistive workflows
Web accessibility audit and remediation
What we check, and how
A web accessibility audit from us starts in the code itself; the scanner report is the smallest part of it. Automated tools such as axe catch only part of the picture: they find missing alt text and contrast failures but cannot judge whether a heading order makes sense, whether focus moves correctly into a dialog, or whether a screen reader announces a form field the way a person would expect. So every audit combines automated checks with a manual pass: a full keyboard walk through every page (tab order, visible focus, no traps), a read of the accessibility tree against the visual layout, and testing with at least one screen reader on its actual interaction model, with the shortcuts and menus its users rely on.
What we measure against
We test against WCAG 2.2 at the AA level — the current W3C standard, including the newer success criteria on focus appearance and target size — and follow the W3C's own evaluation methodology rather than a proprietary checklist. Colour contrast is measured against the real, composited background of every surface it lands on, because a token that passes on white regularly fails on a tinted card or button.
What we build, not just report
- Semantic HTML first — landmarks, one heading per section, real buttons and links rather than styled divs — because native elements carry role, name and keyboard behaviour for free
- Keyboard and focus behaviour for every interactive component, including custom widgets, menus and dialogs
- Form labelling, error messaging and validation that a screen reader announces correctly the first time
Beyond the automated score
Accessibility work that stops at a passing automated score leaves out the people it's meant to serve — screen reader users navigate primarily by heading structure and landmarks, so a page that "passes" but reads as a wall of unlabelled sections has failed them regardless of the score. We close remediation with a written plan ranked by how much each fix matters to the people using the site, and we build the same discipline into interface work from the start so it doesn't need retrofitting later.


