Why we treat it as part of the work
Accessibility is often handled as a last step: build the site, run a scan before launch, fix what the scanner flags. Automated tools catch only part of the problems, and by then many real issues are built into the design: a palette that fails contrast, navigation that doesn’t work with a keyboard, a form that makes no sense to a screen reader.
Building it in from the start costs less, and it helps everyone: clear structure, good contrast, captions and plain language make a site easier for someone on a phone in bright sun or reading in a second language. For public institutions and anyone serving the general public, it’s non-negotiable, and often a legal requirement.
The standard
The reference point is the Web Content Accessibility Guidelines (WCAG), published by the W3C. Accessibility laws and procurement requirements typically reference WCAG at level AA, often version 2.0 or 2.1. Version 2.2 is the current one, and what we audit against. The guidelines rest on four principles: content has to be perceivable, operable, understandable, and robust enough to work with assistive technologies.
Conformance is the floor. The goal is a site or product people with disabilities can actually use, which sometimes means going beyond the letter of a guideline.
How we build it in
Accessibility shows up at every stage:
- Content and structure: clear headings, meaningful link text, plain language and a logical reading order, set in the content model.
- Design: contrast checked in the palette, type that scales, designed focus states, touch targets big enough for real fingers, and nothing that relies on colour alone.
- Design system: components built accessible once, so every page that uses them inherits it.
- Development: semantic HTML first, ARIA only where it’s needed, full keyboard support, labelled forms with useful errors, and respect for reduced-motion settings.
- Media: captions and transcripts for video and audio, and alt text written for what an image means in context.
- Interactive and 3D work: an alternative route through any experience that can’t be made fully accessible itself.
- Testing: automated checks in the build, plus manual testing with keyboards and screen readers such as VoiceOver and NVDA.
Auditing an existing site or product
An accessibility audit combines automated scanning across the whole site with manual review of the templates and flows that matter most: navigation, search, forms, checkout or sign-up, and any interactive features.
The report is written to be acted on. Each issue is described in plain language: where it occurs, who it affects, which WCAG criterion it relates to, and how to fix it. Issues are ranked by impact, and since many trace back to a handful of templates or components, fixing those can clear many instances at once.
We can then fix the issues ourselves, work alongside your developers, or both.
Keeping it accessible
Sites drift: a campaign page skips the heading structure, a video arrives without captions. Accessibility holds up when it’s part of how an organization publishes, so we help set that up with checks in the build, accessible templates in the CMS, and short training for editors on what only people can get right, such as alt text and link wording.
AI tools help draft alt text and captions and flag likely issues in new content. A person still reviews what they produce, because accessibility is about meaning, and meaning depends on context.
What you receive
- An audit against WCAG 2.2 AA, combining automated and manual testing
- A prioritized report with plain-language descriptions and fixes
- Fixes to templates, components and content, by us or alongside your team
- Automated accessibility checks in the build process, and guidance for editors
- An accessibility statement for your site, where you need one