What if the web was inaccessible to everyone?

  • user
  • date
    October 09, 2023
What if the web was inaccessible to everyone?

Picture the scene:

Your friend sends you a link to their new favourite ecommerce store (not built by San Digital), you have to buy their Products™!

You arrive on the landing page but all you see is some small text that says "hero image" and trying to press anything on your phone screen has no effect.

It's probably just your old phone that's the problem. You load the web page on your (less convenient) computer and press on. You need a Product™.

Scrolling down you see a list of buttons that say "Buy" and underneath them a list of poorly photographed Products™, if you squint it looks like the 7th one on the list is the one you wanted so you go back, count to the 7th "Buy" button and click it. Nothing happens.

Did it work? You can't click on anything again! You scroll back to the top of the page to find some and text asking about cookies and after scrolling around figure out that the button to "Accept all" was somewhere else on the page. You scroll back and find a basket button.

Great! Looks like it was added to basket after all, you're so close you can touch/taste/feel Product™!

But what's this? A list of input text fields without labels?

A slider? What on earth is that for?

You wonder if it’s just easier to ask your friend to order it for you and avoid this despair.

Everyone deserves to be able to access the same resources - independently and without frustration. Buses have low floors to make them easier to board, road crossings have tactile pavements, TV shows have captions, and websites should be accessible.

accessibility symbol


Regardless of any disabilities, a person should be able to do what they need to, with a similar amount of time and effort as anyone else. The first step to achieve this is to understand the problems you are trying to solve. Luckily there is a technical standard to help with this, WCAG. It contains guidelines which are grouped into levels to achieve a consistent standard of accessibility.


The WCAG standard defines three compliance levels, for minimal, acceptable and optimal compliance (A, AA, AAA respectively). For your site to be compliant it needs to follow all the guidelines for a given level, as well as the level below it. If your website doesn’t meet any level of compliance it is impossible or exceedingly difficult to use for some users.

  • A - To achieve this level you need to not use any elements that actively make your website inaccessible. Keyboard navigation, non text content alternatives and video captions need to be available.
  • AA - This should be the goal for most companies, an acceptable level of compliance that is usable for most people by adding some basic accessibility support. This level includes alt text for images, suitable color contrast and labels for form fields.
  • AAA - This is the ideal, generally it’s not recommended to set as a policy since achieving everything it includes is not practical for some forms of content. It includes sign language interpretation for audio and video content, higher color contrast and context sensitive help.

If you’re less interested in the details of how to achieve accessibility but still want to understand it from a product or design perspective there is plenty of content out there for you too.

POUR: The Principles of WCAG

Image of a someone pouring coffee into someone elses mug

To make accessibility guidelines less abstract and easier to understand it’s a good idea to review the foundations that the guidelines are organised around.

  • Perceivable - Content and UI needs to be presentable to the user, and can’t be invisible to all of their senses.
    • Text alternatives for images, clear boundaries between content and backgrounds.
  • Operable - The user needs to be able to use the web page regardless of abilities.
    • Functionality and navigation is available from the keyboard, and no time limits on interactions.
  • Understandable - Information and operation of the UI should be clear.
    • The web page should be easy to read, predictable and intuitive to use and offer guidance to the user if required.
  • Robust - A wide range of assistive technologies and user agents should be supported
    • If someone uses a screen reader they should be able to navigate your web page, and as these technologies evolve they should continue to be supported

I need to understand all that?

The WCAG specification can be overwhelming and identifying parts of your website isn’t easy even if you know what you’re looking for - it can be hard to tell where to start.

The good news is there are plenty of tools which fit into whichever trophy or pyramid you use to decide how to test your codebase. While a tool won’t solve all of your problems there’s no excuse for letting easy-to-resolve accessibility issues through to production because you have no way of testing for them.

Eslint jsx a11y plugin is a static code analysis tool, the best time to find out about accessibility issues is as soon as you make them. Add this plugin to your project and VS Code will immediately highlight issues in your webpages without any extra testing effort. Since this is a code analysis tool there is a limit to what it can pick up (For example custom components can cause some confusion - is it a button? Is it an image?), but it’s low effort to add to a project and configure.

For more reliable insight into accessibility on your web page you’ll want to test the rendered output. The WAVE browser extension provided by Webaim is perfect for some quick manual testing of a web page. Install it then right click the page you want to test to “WAVE this page” and you’ll get a list of accessibility errors and alerts, along with references explaining what the issues are and why and how to fix them. It helps with testing page structure and order for page navigation, and contrast and styling for harder to spot accessibility issues.

Example of a WAVE run on an example of bad accessibility provided by Imperial College London

If you are lucky enough to be in a position where you have automated testing as part of your development and deployment workflow you can include Axe (An accessibility testing engine) plugins for Jest or Cypess. Axe gets injected to your web page at the start of a test, and you can configure which rules you want to run and Axe will fail any test that violates those rules.

There are more issues these tools can’t fix - if your images have poor contrast and labels or alt text that is just unhelpful then your website isn’t actually any more accessible than if they weren’t there.. In fact it could be less! Automated testing for these types of problems aren’t widely available (yet, someone must have started making a ChatGPT powered accessibility context validator) so you need to be aware of the “why” behind these accessibility guidelines to ensure you are helping, not hindering. The UK Government has some great resources on this kind of thing.

The barrier for entry to accessibility testing has never been lower, like your website after you start using these tools.

Get in touch

Let’s do something great