Accessibility Policy

Accessibility is standard practice here, not an afterthought. We build websites for a living, so the things we make need to work for everyone. That means following established guidelines, testing with real assistive technology, and treating accessibility as part of the job — not a box to tick at the end.

What guides us

We build to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. This is the current international standard and the benchmark used across UK public and private sector work.

We also work within the Equality Act 2010, which requires reasonable adjustments so that disabled people are not disadvantaged when using digital services. For clients in the public sector, the Public Sector Bodies Accessibility Regulations 2018 apply too, and we help those clients meet their obligations.

What we do in practice

WCAG 2.2 is built around four principles: content should be perceivable, operable, understandable, and robust. Here is what that looks like in our day-to-day work:

• Every image, video, and non-text element gets a meaningful text alternative.
• All functionality works with a keyboard alone — no mouse required.
• Touch targets are large enough to use comfortably on mobile.
• Focus indicators are always visible and never hidden behind other content.
• Colour contrast meets or exceeds AA ratios for both text and interface elements.
• We use semantic HTML and proper heading structure so screen readers can make sense of a page.
• Forms include clear labels, helpful error messages, and do not ask people to re-enter information unnecessarily.
• Authentication flows avoid reliance on cognitive function tests where possible.
• We do not use content that could cause seizures or physical reactions.

How we test

Automated tools catch some issues, but not all. We combine automated scanning with hands-on manual testing:

• Screen reader testing with VoiceOver (macOS/iOS) and NVDA (Windows).
• Keyboard-only navigation across all interactive elements.
• Browser accessibility audits (Lighthouse and axe DevTools).
• Testing across devices, browsers, and viewport sizes.
• Colour contrast checking against WCAG AA thresholds.

We do this on our own site and on every client project we ship.

Client work

We build WordPress websites on monthly retainers, embedded inside our clients’ teams. Accessibility is part of every build, not something bolted on later. When we take on an existing site, we flag accessibility issues early and work through them as part of the retainer.

If a client’s site needs to meet public sector regulations or serve users in the EU (where the European Accessibility Act applies from June 2025), we advise on what’s required and build to that standard.

Communication and meetings

We work remotely, embedded in our clients’ Slack workspaces and meeting schedules. All our meetings happen over video call — Zoom, Teams, Google Meet, or whatever the client uses. If you need captions, a transcript, or a different format for any meeting or document, just let us know and we will sort it.

We use plain English in everything we write — emails, Slack messages, documentation, and the products we build. Clear language is an accessibility feature.

In-person meetings

On the rare occasion we meet in person, we will always check that the venue works for everyone attending. If you have any access requirements, tell us beforehand and we will make sure they are met.

Feedback

If you find an accessibility problem on our site, or with anything we’ve built, we want to hear about it. Get in touch:

• Email: [email protected]
• Phone: +44 (0)7709 125 335

We will acknowledge your message within five working days and aim to resolve any issues as quickly as we can.

Review

We review this policy and the accessibility of our own site at least once a year. This policy was last reviewed in April 2026.