Making your site work for everyone

One in five people in the UK has a disability. That's not a niche audience — it's a fifth of every market. And yet the majority of websites still fail basic accessibility requirements that have been legally mandated for public-sector organisations since 2018, and that the Equality Act has required of private organisations for even longer.

The accessibility problem on the web isn't primarily technical. The tools and standards to build accessible sites exist and are well-documented. The problem is that accessibility is treated as a post-launch audit item rather than a design and development discipline. Here's how to change that, platform by platform.

Start with what breaks most often

In every accessibility audit we run, the same issues appear regardless of the platform. They are not subtle edge cases. They are the core building blocks of an accessible experience, and they fail because accessibility isn't built into the default workflow for most CMS themes and templates.

• Images without alt text, or with alt text copied from filenames
• Form inputs without associated labels (relying on placeholder text only)
• Insufficient colour contrast ratios — particularly on grey-on-white text
• Interactive elements that cannot be reached or operated by keyboard
• Modal dialogs that don't trap focus and don't restore it on close
• Pages with no skip-to-main-content mechanism for keyboard and screen reader users

The WCAG 2.2 AA additions that catch people out

WCAG 2.2 added nine new success criteria, three of which cause the majority of failures in our audits:

2.4.11 Focus Appearance

A keyboard focus indicator must now be visible, have a minimum area (the perimeter of the focused element by 2 CSS pixels), and have a contrast ratio of at least 3:1 between its focused and unfocused states. Most CMS themes use either a browser-default outline (fine in some browsers, invisible in others) or suppress it entirely with outline: none. Both fail.

2.5.7 Dragging Movements

Any functionality that requires a dragging motion must also have a single-pointer alternative. Sliders, drag-to-reorder interfaces and swipeable carousels are common offenders. The fix is usually to add keyboard arrow-key control and visible increment/decrement buttons.

2.5.8 Target Size (Minimum)

Pointer input targets (buttons, links, form controls) must be at least 24 × 24 CSS pixels. This catches icon-only buttons, close buttons on modals, and in-text links where the clickable area is just the text itself. Note: the target size includes the spacing around an element if that spacing is part of the interactive area.

Making it stick: accessibility as process, not project

One-off audits fix current failures. They don't prevent new ones. The only way to maintain accessibility over time is to make it part of your editorial and development process — which means building it into your CMS workflow.

• Add alt text fields to every image component in your CMS, and make them required
• Include colour contrast checking in your design review process
• Add automated accessibility tests (axe-core, Pa11y) to your CI pipeline
• Include a keyboard navigation check in your manual QA checklist
• Train content editors on what makes alt text useful, and what makes it harmful