Why does web accessibility matter?

The picture most people have of web accessibility is a blind person using a screen reader. It is real, and it is a small fraction of the subject.

Also shut out: someone with low vision zooming to 200%, someone who cannot tell red from green, someone who cannot use a mouse because of arthritis or a tremor, someone who processes information slowly, someone navigating one-handed because they are carrying a child in the other, and someone trying to read your site in midday sun. Accessibility is not a feature for a minority: it is the difference between your site working in perfect conditions and working in real ones.

What is WCAG, and which level do you need?

The rules of the trade are WCAG, maintained by the W3C, currently at version 2.2. They come in three levels:

• A — the minimum. Without it, some content is simply unusable.
• AA — the practical target, and the one nearly every regulation cites.
• AAA — demanding to the point that the W3C itself does not recommend applying it to a whole site.

When someone says “we are accessible”, the right question is “at which level, and on which pages”. The useful answer is almost always AA across the critical journeys: home page, contact form, product page, checkout.

And yes, there is a legal obligation in more places than people think. In the European Union, the European Accessibility Act has applied since June 2025 to a good part of ecommerce and digital services. In Colombia, public bodies have been subject to accessibility criteria for years through digital government regulation. And in the private sector, more and more tenders ask for it in writing.

The four principles, in plain language

WCAG is organised around four ideas. Translated into what they actually mean:

Perceivable. Information can be received through more than one channel. Alternative text on images, captions on video, sufficient contrast, and never relying on colour alone to communicate anything.

Operable. It can be used without a mouse. Everything clickable reachable by keyboard, in a logical order, with visible focus, no traps you cannot escape and no impossible time limits.

Understandable. It makes sense and behaves as expected. Declared language, labelled form fields, errors that explain what happened and how to fix it, navigation that does not move between pages.

Robust. It works with whatever assistive technology is in use. Semantic markup — a button that is a <button> — rather than a <div> with an onclick.

What do we check in practice?

The list we use, ordered by how many problems each point resolves:

1. Contrast. Body text, 4.5:1 against its background. Large text, 3:1. Field borders, meaningful icons and focus states, 3:1. It is the most commonly failed and the easiest to fix, because it is a number rather than an opinion — to check it we have the contrast checker, which also suggests the closest colour that does pass, transparency included.
2. Keyboard navigation. Walk the whole site with the tab key. If at any point you cannot see where you are, or you get trapped inside a menu, that is a failure — and it also hits people who use the keyboard purely out of habit.
3. Alternative text. One sentence describing the image. Empty (alt="") if it is decorative: that tells a screen reader to skip it, which is exactly right.
4. Heading structure. One h1, then in order, without skipping levels. It is the table of contents people navigate a site with when they cannot see it.
5. Labelled forms. Every field with its associated <label>. A placeholder is not a label: it disappears exactly when you start typing.
6. Colour never carries information alone. If the only clue that a field failed is that it turned red, anyone who cannot distinguish that red never finds out. Add an icon, a message, or both.
7. Motion and zoom. Honour prefers-reduced-motion, and keep the page working at 200% zoom without overflowing. Zooming in is the same as narrowing the window, so this and responsive design are the same problem solved once.

What almost nobody mentions

Here is the argument that convinces whoever the rest did not: almost everything accessibility demands is the same thing technical SEO and usability demand.

The semantic markup a screen reader needs is the markup that helps a search engine understand the page hierarchy. The alternative text describing an image is what makes it findable. A properly labelled form autofills better. High contrast reads better in sunlight. A 44-pixel touch target gets missed less often by a thumb.

You are not doing two jobs. You are doing one properly.

Where do you start when there is no budget for everything?

Three steps that fit in an afternoon and resolve most of it:

1. Run an automated checker — there are free ones, including inside the browser’s own tools. It catches between a quarter and a third of the problems, and they are the most mechanical ones.
2. Fix contrast across the whole site. It is systematic: change the colour tokens once and every page benefits.
3. Tab through your contact form and your checkout. If those two work without a mouse, you have covered what actually earns money.

What no automated checker can judge — whether the alternative text describes what matters, whether the reading order makes sense, whether the error message explains anything — still needs a person. But by that point you are no longer fixing: you are refining.

---

An accessible website is not a website with an add-on for a few people. It is a website built without assuming how whoever arrives sees, hears, moves or concentrates. And that is, precisely, the definition of being well made.