WCAG 2.2 AA by default
We target WCAG 2.2 AA as the baseline for every project. It is applied from the first commit, not added as a final check before launch.
Our Approach
Accessibility is how we build, not a policy we file away
Accessible design is part of how we design, build, and test every project. Not something added after launch.
Accessibility is about ensuring people with diverse abilities, technologies, and ways of interacting with the web can access the same information and complete the same tasks without unnecessary barriers.
AA
WCAG 2.2 conformance target on every build
100%
Manual keyboard testing is part of every accessibility review
Manual
testing on top of automated scans, because scanners alone are not enough
One barrier offline becomes another online
OFFLINE
Accessibility is a core priority for our team. One member of our team lives with a speech disfluency, an experience that has shaped how we think about communication, inclusion, and systems designed for diverse users.
ONLINE
While speech differences and web usability are different challenges, they share the same principle: people should not be excluded because a system failed to consider them. That principle shapes every project we take on.
We believe digital accessibility is a human right, and we treat every client project with the urgency that a rights-based approach demands.
Our technical principles
Accessibility is not a feature. It is a quality of the product itself. Users should not need to enable it, request it, or work around its absence.
Keyboard and screen reader first
We use keyboard navigation alongside screen readers including NVDA, VoiceOver, and TalkBack to verify critical user journeys.
Low-bandwidth inclusion
Lightweight, resilient pages that stay usable on slow connections and older devices. Access should not depend on owning the newest hardware.
Colour contrast
Text and interactive elements meet or exceed WCAG 2.2 AA contrast requirements across the colour themes used by the project.
Motion preferences
Animations and transitions respect the prefers-reduced-motion media query. Motion only plays when the user has not indicated a preference to reduce it.
Accessible forms
Every input is explicitly labelled. Error messages are associated with their fields. Validation does not rely on colour alone.
Focus management
Focus is placed intentionally on state changes, modal dialogs, and interactive content updates, so keyboard users always know where they are.
Alternative text
Every non-decorative image has accurate, purposeful alt text. Decorative images are hidden from assistive technologies with empty alt attributes.
Logical reading order
Content follows a meaningful sequence in the source code, so screen reader users encounter information in the same order as sighted users.
Responsive reflow
Content remains usable without horizontal scrolling when zoomed to 400%, in line with WCAG 2.2 requirements where reflow is expected.
Touch targets
Interactive controls are sized and spaced to reduce accidental activation across touch devices, in line with WCAG 2.5.8.
Consistent navigation
Navigation components appear in the same location and order across pages, so users do not need to relearn where controls are as they move through the site.
Technical Stance
Beyond automated scanners
Automated testing is valuable, but it cannot replace manual testing with assistive technologies. Passing an automated scan tells you very little about whether someone can successfully use your interface. So we do not stop there:
01Full screen-reader walkthroughs, page by page, with NVDA and VoiceOver
02Keyboard-only navigation tests: no mouse, no trackpad, every flow
03Zoom and magnification checks up to 400%, across breakpoints
How accessible design is built into our work
Our accessibility process
01Baseline audit across your highest-traffic and highest-risk flows
02Prioritized fixes, ranked by user impact rather than ticket count
03Handoff docs and training so your team can hold the line after we leave
What success looks like
01Conformance to WCAG 2.2 AA, verified manually, not just scanned
02Task completion verified through manual accessibility testing with assistive technologies
03Interfaces that remain usable across assistive technologies, input methods, and network conditions.
Built against the frameworks that matter
WCAG 2.2
Level AA, our baseline for every build
ARIA Authoring Practices
W3C guidance for correct ARIA widget patterns
HTML Living Standard
Semantic HTML and accessible document structure
ADA Title III
U.S. public accommodation requirements
EN 301 549
EU digital accessibility standard
Section 508
U.S. federal procurement standard
No website is permanently accessible. Accessibility requires continuous testing as browsers, assistive technologies, devices, and content evolve. We treat it as an ongoing engineering practice, not a one-time audit.
Need help improving accessibility?
We work with teams who need usable, inclusive interfaces, built to a standard you can verify, not a checklist you file away.
Talk to us