What Does It Mean for a Website to Be Accessible?
A website is accessible when people can perceive, understand, navigate, and interact with it regardless of disability, device, or assistive technology. That means the content is available to screen readers and keyboard-only users, the layout holds up under zoom and different viewports, and the code follows recognised standards such as the W3C's Web Content Accessibility Guidelines (WCAG). Accessibility is not a separate "disabled version" of a site — it is a quality of the main site, and it benefits every visitor, not only those with a diagnosed impairment.
The four principles behind accessible design
WCAG organises accessibility around four principles, usually abbreviated as POUR. Each one answers a different question about whether a real person can use the page.
| Principle | What it asks | Typical failure |
|---|---|---|
| Perceivable | Can the user take in the content through at least one sense? | Text baked into images with no alternative; low colour contrast |
| Operable | Can the user drive the interface with the input method they have? | Keyboard traps; controls that only respond to a mouse |
| Understandable | Can the user predict what the interface does and recover from errors? | Vague link text; forms that reject input without explanation |
| Robust | Does the site work with a range of browsers and assistive technologies? | Markup that only renders correctly in one browser |
These principles are the reason accessibility work overlaps so heavily with clean, standards-compliant front-end development. A site built to W3C standards tends to be more accessible, more future-proof, and easier to maintain, because it relies on documented behaviour rather than browser-specific workarounds.
Who actually benefits
The common assumption is that accessibility serves a narrow group. In practice the audience is much wider:
- People using screen readers or refreshable braille displays, who depend on meaningful headings, alt text, and correctly labelled form fields.
- Keyboard-only users, including people with motor impairments and power users who simply prefer the keyboard.
- People with low vision, who zoom, increase contrast, or override fonts and colours.
- People with cognitive or learning differences, who benefit from plain language, consistent navigation, and clear error messages.
- Temporary and situational users — someone with a broken wrist, a noisy environment, a slow connection, or a small screen.
That last group is why accessibility is often described as a spectrum rather than a binary. Almost everyone moves in and out of it.
Common accessibility failures to look for
Most inaccessible sites fail in a small number of predictable ways. These are worth checking first because they affect the largest number of users:
- Insufficient colour contrast between text and background, making content hard to read in bright light or for users with low vision.
- Missing or unhelpful alt text on images, so screen reader users hear a filename or nothing at all.
- Keyboard traps, where focus moves into a component — a modal, a video player, a custom dropdown — and cannot get out.
- Links and buttons that only say "click here" or "read more", which are meaningless when read out of context in a list of links.
- Form fields without visible, programmatically associated labels, so users cannot tell what to type.
- Content that depends on colour alone to convey meaning, such as a red border being the only error indicator.
- Headings used for visual size rather than structure, which breaks the outline screen reader users navigate by.
How to audit and improve a site
A practical accessibility pass combines automated checks with human testing. Automated tools catch roughly a third of issues, so they are a starting point, not a verdict.
- Run an automated audit on key templates — home, product, checkout, contact — to flag contrast, missing alt attributes, and structural errors.
- Navigate the whole site with the keyboard only. Tab through every interactive element and confirm focus is always visible and never trapped.
- Test with a screen reader on at least one common combination, and listen to whether headings, links, and form labels make sense without the visual layout.
- Zoom to 200% and reflow the page to check that content does not overlap or disappear.
- Check colour contrast against the WCAG minimum ratios for normal and large text.
- Fix issues in priority order: blockers that prevent task completion first, then comprehension problems, then polish.
- Re-test after changes, because accessibility fixes frequently introduce new focus or labelling problems.
For organisations that need a defensible record, a formal accessibility audit presents findings in plain language suitable for a board or non-technical stakeholder, rather than as a raw list of code defects.
Why it matters beyond ethics
There are two practical drivers. The first is reach: an inaccessible site silently turns away customers, and for ecommerce that means abandoned baskets at the exact point of payment. The second is legal. In the UK, accessible web design is discussed in relation to the Disability Discrimination Act (DDA) and the duty not to discriminate against disabled people in the provision of services — which is why accessibility audits are often framed against the DDA for UK organisations. Requirements and enforcement vary by sector and jurisdiction, so treat this as a general orientation rather than legal advice, and confirm your specific obligations before relying on them.
The business case and the standards case point the same way: build to W3C standards, test with real assistive technology, and treat accessibility as an ongoing property of the site rather than a one-off project.