Accessibility is a habit, not a checkbox (and now the law)

Ask a room of website owners what accessibility means and you'll usually get one of two answers. Something about screen readers, or something legal wants us to sign off on. Both are true, and both miss the point.

Accessibility is about whether your website works for the people who show up. All of them.

Who accessibility is actually for

The World Health Organization estimates that 1.3 billion people live with a significant disability. That alone should settle the question. But the group who benefit from an accessible website is far larger, because ability isn't a fixed property of a person. It changes with situation and time:

Design for the first group and the other two get a better website for free. Good contrast helps the person with low vision and also the person in the sun. Captions serve the deaf visitor as well as the commuter without headphones. Keyboard navigation helps someone who can't use a mouse, and the power user who simply won't.

If you've been treating accessibility as optional, the law has moved on:

Outside the EU the wording differs but the destination doesn't: the ADA and Section 508 in the US, the Public Sector Bodies Accessibility Regulations in the UK, the Accessible Canada Act and Ontario's AODA, the Disability Discrimination Act in Australia. Accessibility law goes global walks through each of them.

WCAG, the Web Content Accessibility Guidelines, is the shared measuring stick behind all of it. It's a long document, but its spirit fits in one sentence. Content should be perceivable, operable, understandable and robust for everyone.

What automated testing can and can't do

Automated testing does not catch every accessibility problem, whatever other tools may imply. No tool can tell you whether your alt text is meaningful, only whether it exists. No tool can judge whether your page makes sense read aloud.

What automated testing does brilliantly is the other part:

The reasonable setup uses both. Automated, continuous auditing as your safety net, and periodic human review (ideally involving people who actually use assistive technology) for the judgment calls. That's people before tools, applied to accessibility.

Continuous matters more here than anywhere, because accessibility has a cruel property. The people it fails are the least likely to file a bug report. A visitor who can't get past your cookie banner with a keyboard doesn't email you. They leave. Which means accessibility regressions can sit unnoticed for months while every analytics dashboard looks normal. A one-off accessibility audit is a photograph. Your website is a video. Continuous testing of every page, after every release, is the only way to know the photograph is still true.

Where to start with WCAG

  1. Get a baseline. Find out where you actually stand across the whole site, not just the homepage. (Our baseline report and Webperf Audit were built for this.)
  2. Fix templates before pages. One heading-order fix in a template can repair hundreds of pages at once.
  3. Watch for regressions. Automated tests after each release mean a broken label is a ticket this week, not a legal exposure next year.
  4. Bring in real people. When the mechanical issues are handled, usability testing with assistive-technology users will teach you things no score can.

Accessibility done this way stops being a compliance scramble. It becomes part of how you ship, which is what it should have been all along.


Automated WCAG checks run on every page in every plan. Compare them, or ask us at hello@webperf.cloud where your site stands today.