My interest in web accessibility didn't begin with a technical specification. It began with a conversation — or rather, with many conversations, over the three years I spent working at a special needs college.

I worked there not as a web developer but as a facilitator, and during that time I had the conversations that inspired me to make accessibility a priority.

Students told me about their experiences navigating the internet with screen readers — the frustration of a page that looked perfectly designed but was completely unreadable to them. The contact form that couldn't be submitted without a mouse. The image that was just a blank space without a description. The video that was silent for them with no captions. Websites that sighted, non-disabled users navigated without a second thought, but that was effectively not readable for people using assistive technology.

Those conversations changed how I thought about my work as a developer. I started talking with disabled people to build real first-hand expertise — not just the technical understanding of WCAG criteria, but the lived understanding of what inaccessibility actually costs people in their daily lives.

So let me try to explain what web accessibility actually means, why it matters far more than most people realise, and what it looks like in practice.

What is web accessibility?

At its simplest, web accessibility means building websites that can be used by everyone — including people with visual, auditory, motor, or cognitive impairments. That sounds obvious once you say it out loud. Of course a website should work for everyone. But the reality is that the vast majority of websites on the internet today don't.

The standard that defines what 'accessible' means is called WCAG — the Web Content Accessibility Guidelines, published by the W3C. The current version is WCAG 2.2. It organises requirements around four core principles: content must be Perceivable, Operable, Understandable, and Robust. Each principle contains specific, testable criteria rated at levels A, AA, and AAA. In the UK, the legal minimum — and the mandatory standard for public sector bodies — is WCAG 2.1 Level AA.

What does that look like in practice? Here are some of what meeting that standard actually requires:

• Every image has a text alternative (alt text) so screen reader users know what they're looking at

• Videos have captions for deaf and hard-of-hearing users

• The entire site can be navigated using a keyboard alone, without a mouse

• Text has sufficient contrast against its background so people with low vision can read it

• Forms are clearly labelled so users with cognitive impairments know what information is being requested

• Content doesn't flash or flicker in ways that could trigger seizures

• The site works correctly when text is enlarged up to 200% without loss of content or functionality

Who are we actually talking about?

This is the question I find most useful to ask, because 'people with disabilities' can sound abstract in a way that makes it easy to dismiss. So let's be specific.

In the UK, around 16 million people — roughly 24% of the population — have a disability of some kind. Approximately 2 million have a significant visual impairment. Around 11 million have some degree of hearing loss. Roughly 1.5 million have dyslexia that significantly affects how they read online. Around 10 million live with conditions that affect their ability to use a mouse precisely. Conditions like ADHD, autism, anxiety and depression affect how millions more process and interact with information online.

These aren't edge cases. When you build an inaccessible website, you are actively excluding a very large number of real people from using it.

There's also something worth noting: accessibility features benefit everyone. Captions are used by millions watching on mute on public transport. High contrast text is easier to read on a phone in bright sunlight. Keyboard navigation helps power users who prefer it. Good colour contrast helps older users whose vision has changed. Accessibility and good usability are, in the end, the same thing approached from different angles.

Is it a legal requirement?

In the UK, yes. The Equality Act 2010 requires that organisations make 'reasonable adjustments' to ensure their services are accessible to disabled people. This applies to websites. For public sector bodies — schools, academies, NHS trusts, local authorities — the Public Sector Bodies Accessibility Regulations (2018) make WCAG 2.1 AA compliance a direct legal obligation. The ICO and the Government Digital Service both have enforcement powers in this area. Within the EU the regulations are even stricter, every company that offers services or sells products online has to comply with WCAG 2.1 AA.

There have already been legal cases in the UK and many more in the United States and Europe where businesses have faced action over inaccessible websites. The regulatory direction of travel is clear: this is not going away.

Why do so many websites still get it wrong?

Because it was never a priority, and because many developers — including experienced ones — simply haven't invested the time to learn it properly. DIY website builders can produce sites that are partially accessible by default, but give users very little control over the things that matter most. Many templates have contrast issues baked in. Many plugins introduce accessibility failures silently.

For custom-built sites, accessibility requires specific knowledge at the code level. It's not something you can easily add on top at the end — it has to be considered at every stage of design and development. Semantic HTML structure, ARIA roles, focus management, form labelling — these require deliberate decisions throughout the build.

After 20 years of building websites, I can say that accessibility is one of the areas where experience and continuing professional development matter most. I've seen plenty of otherwise excellent developers produce inaccessible work simply because they haven't kept up with how requirements have evolved.

What should you do about it?

First, find out where you stand. A proper accessibility audit — not just an automated scan, but a manual review by someone who knows what they're doing — will tell you exactly what your website currently fails and why. Automated tools like WAVE or Axe catch perhaps 30–40% of actual accessibility failures. The rest require human judgement.

Second, make accessibility a requirement when briefing any new website build. Ask your web designer directly: are you building this to WCAG 2.1 AA? What's your process for testing? If they can't give you a clear answer, that tells you something important.

Third, understand that accessibility and good design are not in conflict. The best accessible websites are also the most usable, most clearly structured, and most effective at converting visitors. It's not about making compromises — it's about building properly on every level.