Website accessibility: how to make your site usable by everyone

An accessible website is one that people with visual, hearing, motor and cognitive impairments can use: by keyboard, with a screen reader, with enlarged text. The foundation is correct HTML markup, sufficient contrast, labels for fields and images, and working without a mouse. Most of these rules cost almost nothing if built in from the start.

Here is why accessibility matters to a business, which requirements matter most and how to test a site.

Why does accessibility matter to a business?

Accessibility matters because some customers simply cannot use an inaccessible site — so they cannot buy, book or send an enquiry. In several jurisdictions it is also a legal requirement: in the European Union, for example, the European Accessibility Act has applied since June 28, 2025 to many digital products and services, including online shops.

Accessibility also helps people without disabilities:

• someone with an arm in a cast uses the keyboard;
• bright sunlight calls for high contrast;
• a noisy place calls for video captions;
• older users need larger text and clear navigation;
• search and AI crawlers understand semantic markup better.

Which accessibility requirements matter most?

The key requirements are set out in WCAG, the Web Content Accessibility Guidelines; the current version is WCAG 2.2, and level AA is the target for most sites. In practice, a few basic rules cover most problems.

Requirement	What to check	Typical mistake
Semantic markup	Heading levels, lists, real buttons and links	A div button with a click handler
Text alternatives	Meaningful images have alt text	Images of text with no description
Contrast	Normal text at least 4.5:1 against the background	Light grey text on white
Keyboard access	Everything reachable with Tab, focus visible	Focus outline removed
Field labels	Every form field has an associated label	Placeholder instead of a label
Error messages	Errors are described in text and tied to the field	Errors shown only in red
Zoom	The site works at 200% zoom	Text is clipped or overlaps

The full list of criteria is in the W3C's WCAG 2.2 specification.

Photo: Unsplash

How do you write accessible markup?

Accessible markup starts with the right HTML elements: a button is a button, a link is an a, a form field is an input with an associated label. Native elements already work with keyboards and screen readers; home-made ones have to be fixed up by hand.

<!-- Bad: not keyboard-operable, a screen reader will not know it is a button -->
<div class="btn" onclick="submitForm()">Send</div>
<input placeholder="Phone">

<!-- Good: a real button and a field with a label and an error description -->
<label for="phone">Phone</label>
<input id="phone" type="tel" autocomplete="tel" aria-describedby="phone-error" aria-invalid="true">
<p id="phone-error">Enter the number in the format +44 7700 900000</p>
<button type="submit">Send</button>

Rules for interactive components

• a modal traps focus inside and returns it to the trigger button on close;
• dropdown menus and tabs are operable with arrow keys and Escape;
• ARIA attributes supplement markup, they do not replace the right elements;
• animations are disabled when the user has chosen reduced motion in their system settings.

How do you test a site's accessibility?

Test accessibility with a combination of automated tools and manual checks: automation finds some problems — contrast, missing labels, markup errors — but keyboard and screen reader use has to be walked through by hand.

The testing routine:

1. Run an automated check — Lighthouse or axe — on key page templates.
2. Go through the main flows using only the keyboard: menu, enquiry form, cart, payment.
3. Check pages with a screen reader — VoiceOver on macOS and iOS or NVDA on Windows.
4. Zoom to 200% and check nothing is clipped.
5. Add automated accessibility checks to CI so new errors do not creep in.

Accessibility pairs well with other UI quality checks such as speed — see Core Web Vitals.

How much does it cost to make a site accessible?

If accessibility is built into design and development, it barely adds to the budget: it is the same interface elements, done correctly. The expensive part is retrofitting an existing site where interactive elements are built from the wrong blocks and the design ignores contrast.

What keeps costs down:

• a design system with tested accessible components;
• contrast checks at the design stage;
• automated checks in CI from day one;
• training the team on basic rules — they quickly become habit.

In short

• An accessible site works by keyboard, with a screen reader and when zoomed; in the EU it is also a legal requirement.
• The target is WCAG 2.2 level AA: semantics, contrast, labels, focus and clear errors.
• Use real HTML elements; ARIA is a supplement, not a substitute.
• Test with automation, the keyboard and a screen reader, and add checks to CI.
• Accessibility built in from the start costs little; retrofitting a finished site is expensive.