The Workbench Accessibility

Accessibility-First: What It Actually Means in Practice

Most developers treat accessibility as a checklist. Here's why that's backwards — and what it looks like to treat it as a design constraint from the very first commit.

The Checklist Problem

WCAG compliance is often treated as a checklist. You build the thing, then you run an audit, then you fix the failures. This approach has two problems.

The first is that it’s expensive. Retrofitting accessibility into an existing component — especially one built with non-semantic HTML or custom interaction patterns — often means rebuilding it. The later you catch it, the more it costs.

The second is that passing an audit is not the same as being accessible. Automated tools catch around 30–40% of real accessibility issues. The rest require human judgement, user testing, and an understanding of how assistive technologies actually work.

What Accessibility-First Looks Like

Accessibility-first means the design conversation starts with: who uses this, and how? It means keyboard navigation is considered before the hover state. It means the colour palette is chosen with contrast ratios in mind, not audited afterwards. It means <button> is used where the element is interactive, not <div onClick>.

Practically, it means:

  • Semantic HTML always. <nav>, <main>, <article>, <section> — not nested <div>s with classes.
  • Focus management is designed, not inherited. When a modal opens, focus moves to it. When it closes, focus returns to the trigger.
  • ARIA is the last resort, not the first. The goal is HTML that communicates intent without needing to annotate it.
  • Motion is a choice. Any animation respects prefers-reduced-motion. Always.

The Business Case

Accessible sites tend to perform better. They’re faster (semantic HTML is lightweight). They’re more findable (screen reader-friendly markup overlaps heavily with what search engines parse). And they’re usable by a wider audience — not just people with permanent disabilities, but anyone using a phone in bright sunlight, a keyboard without a mouse, or a slow connection.

Accessibility isn’t a cost. It’s a quality signal.

Where We Are

Every Hyperwoven project starts with a WCAG 2.2 AA target. That’s the legal minimum in most UK contexts, but it’s also a meaningful threshold — it covers the majority of use cases and is achievable without specialist tooling.

Where clients come to us with existing sites, we offer audits that go beyond automated scanning: manual keyboard testing, screen reader walkthroughs, and a prioritised remediation plan that distinguishes critical failures from quality improvements.

More from The Workbench

Build logs, accessibility notes, and thinking out loud.

View all articles