Designing for UK Accessibility Regulations: A UI Design Checklist for Public Sector Sites

Accessibility is not a final QA pass you bolt on the week before launch. On UK public sector work it is a design constraint from the very first sketch, and the choices made in wireframes are the hardest ones to unpick later. Get structure, contrast and control behaviour right early and the build stays cheap. Get them wrong and you will be rewriting templates in month three. What follows is a working checklist for designers, ordered roughly by when each decision lands.

What the regulations actually expect

Public sector bodies across the UK are covered by the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. In practice that means three things: meet WCAG AA — the level the regulations point to through the harmonised European standard, EN 301 549 — publish an accessibility statement, and give users a clear route to report problems.

Government guidance has moved towards WCAG 2.2 AA, so designing to the newer criteria is the safer bet. Underneath all of it sits the Equality Act 2010 and the public sector equality duty, which asks organisations to think about how services affect different groups. Enforcement falls to the Equality and Human Rights Commission in England, Wales and Scotland, and to the Equality Commission for Northern Ireland.

There are exemptions — disproportionate burden, certain third-party content, archived material — but they are narrower than teams often assume. If you are unsure how the rules apply to your organisation, take legal advice rather than a designer's guess.

Decisions that belong in the wireframe

Wireframes are where accessibility is won or lost, because they set the bones of the page. Before anyone opens Figma, agree these:

• Heading structure. One page heading, then a logical hierarchy beneath it. Never pick a heading level for its size; pick it for its meaning.
• Page titles that describe the page, not the section, and that appear before anything else in the reading order.
• A skip link to the main content, visible when focused, not hidden behind a logo.
• Focus order that matches the visual order. If your layout only makes sense left-to-right, it will not make sense in a screen reader.
• Language. Mark the page language, and mark any switch between English and Welsh in bilingual services.
• Content shape. If a page needs a wall of text to work, it needs splitting into steps instead.

Colour, contrast and visible focus

Text needs a contrast ratio of at least 4.5:1 against its background; large text (roughly 24px, or 19px bold) needs 3:1, as do interface components and meaningful graphics such as icons and chart lines.

Do not lean on colour alone to carry meaning. Error states need an icon and words. Chart series need labels or patterns. Links inside body text need an underline or another non-colour cue.

Then design the focus state properly, in the design file, rather than leaving it to the browser default. Focus indicators should be clearly visible and must never be obscured by sticky headers, cookie banners or chat widgets. A user tabbing through your service with no mouse should always be able to see where they are.

Text, zoom and reflow

Assume someone will zoom to 200 per cent, override text spacing, or read your service on a narrow phone. Layouts must survive all three without content being cut off or requiring scrolling in two directions.

Use relative units rather than fixed pixel heights, avoid tight hard-coded line heights, and keep body copy at a comfortable size — 16px minimum, larger for services used by older audiences. Never place essential text inside an image. And resist truncating important content with an ellipsis just to make a card look tidy.

Forms, errors and authentication

Forms are where most accessibility complaints originate, and most of them are design problems, not code problems.

1. Give every field a persistent visible label. Placeholder text is not a label.
2. Put hint text above the field and error messages below it, written in plain English: "Enter your date of birth", not "Invalid input".
3. Add an error summary at the top of the page that links to each problem field.
4. Do not ask for the same information twice in one journey.
5. Warn people before a session times out, and let them extend it.

On authentication, allow pasting into fields, support password managers, and avoid puzzles, memory tests or character-shuffling tasks. Cookie banners count as interface too: fully keyboard operable, no pre-ticked boxes, and a "reject all" button that is as easy to find and read as "accept all".

Components, targets and documents

Reach for 44 by 44 pixels for touch targets where you can; WCAG 2.2 sets a 24 by 24 minimum with spacing exceptions. Any interaction that relies on dragging — sliders, map pins, sortable lists — needs a single-pointer alternative.

For modals, keep focus inside while open, return it to the trigger on close, and let Escape dismiss. Carousels should not auto-advance without a pause control. Tabs and accordions need correct semantics as well as good looks.

Avoid PDFs as the only format for essential information. If a PDF is unavoidable, tag it properly and offer an HTML version. And check third-party widgets — maps, booking engines, chat tools — because the user journey is still yours to defend.

Making it stick

Annotate your wireframes with heading levels, alt text intent, focus order and error states, so the build starts from an accessible blueprint rather than a repair job. Build accessibility criteria into your design system and your definition of done, so each new component is checked once rather than audited repeatedly.

Test with keyboard only, then test with people who use assistive technology — local disability organisations and council access panels are often glad to help. Write the accessibility statement early rather than last, keep a log of reported issues, and treat every fix as a design change, not just a bug.

Photo: StartupStockPhotos / Pixabay