Design

Designing Accessible Websites: A UK Legal and Practical Checklist

September 30, 2026

Designing Accessible Websites: A UK Legal and Practical Checklist

Accessibility rarely fails because nobody cared. It fails because a deadline arrived, the design looked fine on a large monitor, and nobody tabbed past the cookie banner. The cookie banner is often the first clue: it may look neat, sit politely in the corner, and accept a click from a mouse. But if it traps keyboard focus, if its close button is invisible against the background, or if it can only be dismissed by dragging a slider, a disabled user may never reach the page underneath. That is not a moral failure. It is a process failure.

In the UK, that process failure can also become a legal problem. The Equality Act 2010 requires service providers, employers, educators and public bodies to make reasonable adjustments for disabled people. For public sector websites and apps, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 add specific duties: meet WCAG 2.1 AA, publish an accessibility statement, and be ready for monitoring. Many teams now aim for WCAG 2.2 AA as the practical target. The goal is not to pass an audit once. The goal is to build accessibility into design, content, code, testing and governance.

Why accessibility fails in practice

Most accessibility problems are not exotic. They are ordinary decisions made under pressure. A designer removes focus outlines because they look “ugly”. A developer uses a div as a button because it is quicker to style. A content editor writes “click here” because the surrounding paragraph makes sense to a sighted reader. A product manager postpones captions because the video is “just a nice-to-have”. Each choice seems small. Together they create barriers.

Common failure points include:

Keyboard traps, especially in cookie banners, modals, chat widgets and date pickers.
Missing or low-contrast focus styles, so keyboard users cannot tell where they are.
Poor colour contrast between text and background, including placeholder text and disabled states.
Images without useful alternative text, or alt text that repeats the caption.
Headings used for size rather than structure, making screen reader navigation confusing.
Forms without labels, vague error messages, or errors that are only shown in red.
Content that only works with a mouse, such as hover menus, drag-and-drop, or swipe-only carousels.
Motion and animation that cannot be paused, stopped or hidden.

None of these are rare. They are the everyday symptoms of building for a narrow idea of “normal” use.

The UK legal picture: what actually applies

The legal landscape is broader than many teams assume. The Equality Act 2010 applies across Great Britain and covers services, employment, education and public functions. It does not mention websites by name, but the duty to make reasonable adjustments does. If a disabled person cannot use your service because of an inaccessible website, you may be failing to make a reasonable adjustment. There is no fixed checklist in the Act, but WCAG 2.1 or 2.2 AA is widely used as the benchmark for what is reasonable.

For public sector bodies, the 2018 Accessibility Regulations are more prescriptive. They apply to websites and mobile apps provided by public sector bodies, with some exceptions. They require compliance with WCAG 2.1 AA through the harmonised European standard EN 301 549. They also require a published accessibility statement. That statement must explain how accessible the site is, how to report problems, and how to contact the body. If a public sector body claims “disproportionate burden” for some content, it must document why and still meet the rest.

Private sector organisations are not exempt. The Equality Act still applies. A bank, retailer, university, charity or hotel that offers services online should treat accessibility as part of customer service. Procurement is another pressure point: public sector buyers increasingly ask suppliers to demonstrate accessibility, and a voluntary accessibility statement can be a competitive advantage.

Accessibility is not a separate project bolted on at the end. It is a quality standard for the whole product.

A practical checklist for design and delivery

Use this as a working checklist, not a one-off audit. The best results come when accessibility is part of discovery, design, build, content and testing.

1. Structure and content

Use one clear page title and a logical heading order. Do not skip from h2 to h4 just to get the size you want.
Write link text that makes sense out of context. “Read the accessibility statement” beats “click here”.
Give every meaningful image useful alt text. Mark decorative images as decorative.
Provide captions for videos and transcripts for audio. Do not rely on auto-captions without checking them.
Use plain English, short sentences and descriptive labels. This helps everyone, including people with cognitive disabilities, dyslexia or limited English.

2. Keyboard and focus

Make every interactive element reachable and operable with a keyboard.
Keep a visible focus indicator. Never remove it without replacing it with something stronger.
Provide a skip link so keyboard users can bypass repeated navigation.
Check that cookie banners, modals and menus do not trap focus. Focus should move in, stay within the component while open, and return when closed.
Do not rely on hover alone. Any hover action should also work on focus and tap.

3. Flexible build

Use semantic HTML first: buttons for buttons, links for links, labels for inputs, lists for lists.
Associate every form field with a visible label. Show errors in text, not just colour, and explain how to fix them.
Use ARIA sparingly and correctly. Bad ARIA is often worse than no ARIA.
Support zoom and reflow. Content should remain usable at 200% zoom and at 400% without two-dimensional scrolling.
Meet contrast requirements for text, icons, focus states and meaningful graphics.
Make touch targets large enough. Small close buttons and tiny pagination dots are common failures.
Respect reduced motion preferences. Allow users to pause, stop or hide moving content.

4. Testing with tools and people

Run automated tools, but treat them as a first pass. They catch only a minority of issues.
Test with a keyboard only. Unplug the mouse and try to complete the main tasks.
Test with a screen reader such as NVDA, JAWS or VoiceOver.
Test at high zoom, with high contrast settings, and with different viewport sizes.
Include disabled users in research and usability testing. Lived experience finds problems that checklists miss.

Accessibility statements and ongoing governance

For public sector bodies in the UK, an accessibility statement is a legal requirement. It should be easy to find, written in plain language, and honest about known gaps. It should include a contact route for reporting problems and information about the enforcement procedure. A statement that claims “fully accessible” while obvious barriers remain damages trust and can attract complaints.

Private organisations should consider publishing a voluntary statement too. It signals maturity and gives users a way to report issues. More importantly, accessibility needs governance. That means: