01 /Web Development
Accessibility Implementation
Making an interface work for people using a keyboard, a screen reader, magnification or reduced motion — and keeping it that way as the product changes. Retrofitting accessibility into a finished interface costs several times what designing to it would have.
What you get
Semantic markup and a working focus order
Landmarks, headings and controls that mean what they claim, with a tab order that follows the visual one. This is the foundation; assistive technology cannot repair markup that lies about its own structure.
Keyboard operability for every control
Everything reachable and operable without a pointer, including the components that usually break it: custom selects, modals, disclosure menus and anything that traps or loses focus.
Contrast and target sizes that hold up
Measured rather than eyeballed, including the states people forget — hover, focus, disabled and text over imagery. Alpha applied to text is the most common way a palette that passes on paper fails in practice.
Reduced-motion and zoom behaviour
Animation that respects the operating system preference, and layouts that survive 200% zoom and 200% text scaling without clipping content or hiding controls.
Patterns your team can reuse
The accessible versions of your components, documented, so the next feature inherits the behaviour instead of reintroducing the same problems.
How it runs
- 01
Find what is broken
A pass with a keyboard and a screen reader, plus measurement of contrast and target sizes. Automated tooling catches perhaps a third of real issues, so it is a starting point rather than the method.
You provide: Access to the application and its component source
We produce: A prioritised issue list with reproduction notes
- 02
Fix the components, not the pages
Most issues repeat because they live in a shared component. Fixing them at the component level resolves every instance at once and stops the same defect returning on the next page.
We produce: Remediated components
- 03
Verify with assistive technology
Re-tested the way it will actually be used rather than re-run through a checker, because a page can satisfy every automated rule and still be unusable with a screen reader.
We produce: Verification notes per issue
- 04
Document the patterns
Written guidance for the components your team will keep building with, so the work holds rather than decaying with the next few features.
We produce: Component accessibility notes
Where this stops
- Not a formal accessibility audit or a conformance statement. We do not issue a signed declaration of conformance, and if a procurement process requires an independent audit you need an accredited assessor rather than the team that did the implementation.
- Not legal advice on the European Accessibility Act. We can tell you what the technical standard asks for; whether your organisation is in scope, and whether any exemption applies, is a question for your own counsel.
- Not a promise that every automated checker will report zero issues. Checkers disagree with each other and produce false positives, and chasing a clean report is not the same as being usable.
- Not user testing with disabled participants. That is genuinely valuable and it is a research engagement with recruitment and consent obligations, run by people who do that work.
Related reading
- Accessibility
The European Accessibility Act and your website: what it actually requires
The Act has applied since June 2025. What it covers, which technical standard sets the bar today, and the accessibility failures no automated checker will ever find for you.
- EU regulation
The Cyber Resilience Act’s first deadline: what changes on 11 September 2026
From 11 September 2026, manufacturers must report an actively exploited vulnerability within 24 hours. Who that binds, what the clock actually demands, and what to have in place before it starts.
FAQ
Accessibility Implementation questions we hear often
Which standard should we build to?
Build to WCAG 2.2 AA. Note the nuance though: the harmonised standard cited for the European Accessibility Act is EN 301 549, whose current version points at WCAG 2.1 AA, so 2.1 is the yardstick that binds today. Building to 2.2 now means the later update costs you nothing.
How much does accessibility slow down delivery?
Very little when it is designed in, and a great deal when it is not. The expensive version is discovering after launch that a custom component cannot be operated by keyboard and has been reused on forty screens. Doing it at component level, once, is cheaper than any retrofit and it is why this is implementation rather than audit work.
Can automated tools do this instead?
They catch a meaningful minority of issues and they are worth running in CI. What they cannot assess is whether a label is meaningful, whether focus order makes sense, whether an error message explains the problem, or whether a flow is navigable by someone who cannot see the layout. Those need a person.
We already failed an audit. Can you fix the findings?
Yes, and that is a good starting point because the diagnosis already exists. We work through the findings at component level rather than page by page, which usually collapses a long list into a much smaller set of underlying causes. Re-verification against the original findings is part of the work.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.