← Back to Blog
AccessibilityWCAGUX

WCAG 2.2 Accessibility: Beyond Compliance

7 min read

WCAG 2.2 Accessibility: Beyond Compliance

Accessibility is easy to treat as a checklist. It's harder — and more useful — to treat it as a design principle.

Working at RNID, an organisation focused on hearing loss and tinnitus, accessibility isn't abstract. It directly affects the people using the products you build. That context changes how you think about it.

Why It Matters in Practice

The People Using Your Product

Real users I've thought about:

  • Screen reader users navigating forms and content
  • People with hearing loss accessing audio and video content
  • Users with motor disabilities relying on keyboard navigation
  • People with cognitive disabilities processing complex information

Accessible design isn't a special case — it's just good design for everyone.

The Business and Legal Reality

  • Legal requirements exist in public sector and many other contexts
  • A site that's difficult to use for disabled users loses those users
  • Semantic HTML and good structure also helps SEO

Practical WCAG 2.2 Implementation

Semantic HTML Is the Foundation

Avoid this:

<div onClick={handleClick}>Click me</div>

Prefer this:

<button type="button">Submit Form</button>

Native elements give you keyboard navigation, screen reader context, and correct semantics for free.

Colour Contrast

WCAG AA requires:

  • 4.5:1 for normal text
  • 3:1 for large text and UI components

Test with tools like Lighthouse or the WebAIM Contrast Checker.

Keyboard Navigation

Every interactive element must be:

  • Reachable via Tab
  • Actionable via Enter or Space
  • Visibly focused — focus indicators must be clear
  • Logically ordered — the tab sequence should make sense

The simplest test: unplug your mouse and try to use the site.

ARIA — Carefully

The first rule of ARIA is: don't use ARIA if native HTML works.

That said, there are places where it genuinely helps:

<div role="alert" aria-live="polite">
  Form submitted successfully
</div>

Screen readers will announce live regions automatically. Use this for dynamic content updates.

Forms and Error Handling

Accessible forms need:

  • Labels connected to inputs (programmatically, not just visually)
  • Clear and specific error messages
  • Hints where the format is important
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-hint"
/>
<span id="email-hint">We'll only use this to respond to your message.</span>

Testing Strategy

Automated tools catch roughly 30% of accessibility issues. The rest requires:

  • Testing with screen readers (NVDA, VoiceOver, JAWS)
  • Keyboard-only navigation testing
  • Testing at 200% zoom
  • Ideally, feedback from real users

Tools are a starting point, not an endpoint.

Common Mistakes

Hiding content incorrectly:

/* This is visible to screen readers */
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
}

Don't use display: none if you need screen readers to access the content.

Missing skip links:

<a href="#main-content" class="sr-only focus:not-sr-only">
  Skip to main content
</a>

Keyboard users shouldn't have to tab through every navigation link on every page.

The Mindset

Instead of asking "how do we make this accessible?" try asking "how do we make this work for everyone?"

Accessibility constraints often lead to better design generally:

  • Clear labels help all users
  • Keyboard navigation is faster for power users
  • Captions help in noisy environments
  • High contrast helps in bright sunlight

Closing Thoughts

Building accessible software is:

  • Required in many contexts
  • The right thing to do in all of them
  • Better for everyone when done properly

Start with semantic HTML. Test with real tools and real people. Treat it as a quality standard, not a compliance exercise.

Questions about accessibility implementation? Happy to discuss practical approaches.

← Back to Blog