WCAG 2.2 AA and the public sector accessibility regulations: a practical checklist
A practical checklist for building public sector services that meet WCAG 2.2 AA, from semantic HTML and keyboard access to testing, audits and statements.
Onarvo Team
Public sector websites and apps have to be usable by everyone. In the UK, the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 require public bodies to make their sites and apps accessible and to publish an accessibility statement. In practice, the benchmark is the Web Content Accessibility Guidelines at level AA, and WCAG 2.2 is the current version.
This article is a working checklist from a delivery team's point of view. It is not legal advice, and it is not a substitute for the guidelines themselves. It is the set of habits that make accessibility achievable rather than a scramble before launch.
Build it in from the start
Accessibility is far cheaper to build in than to bolt on. Retrofitting a finished service often means reworking components, content and sometimes whole journeys.
From the first sprint:
- Include accessibility acceptance criteria in user stories
- Use a component library that has already been tested for accessibility
- Involve content designers, because plain, well-structured content is part of accessibility
- Include disabled people in user research, not only in final testing
Use semantic HTML
Most accessibility comes for free when the right elements are used for the right job. Headings that are real headings, lists that are real lists, buttons that are buttons and links that are links.
Checklist:
- One clear page title and a logical heading order
- Landmarks for header, navigation, main content and footer
- Native form controls wherever possible
- ARIA used only where native elements cannot do the job, and tested when it is
Make everything work with a keyboard
Every interactive element must be reachable and usable without a mouse. That includes menus, modals, date pickers, accordions and anything custom.
- Tab order follows the visual and logical order
- No keyboard traps: users can always move on
- A skip link lets users bypass repeated navigation
- Modals move focus in when they open and return it when they close
Keep focus visible
Keyboard users need to see where they are. Never remove the browser focus indicator without replacing it with something at least as clear. Test focus styles against every background colour they might appear on.
Check colour contrast
Text and important interface elements need enough contrast against their background, and information must never be conveyed by colour alone. Check contrast during design, not after build, and include states such as hover, focus, disabled and error.
Design forms and errors carefully
Forms are where many services fail users. Good practice includes:
- Visible labels associated with every field, not placeholder text alone
- Clear hints for expected formats
- Error messages that say what went wrong and how to fix it
- An error summary at the top of the page that links to each field
- Errors announced to screen reader users
The new criteria in WCAG 2.2
WCAG 2.2 added several success criteria. Described in principle, the ones at A and AA level are:
Focus not obscured
When an element receives keyboard focus, it should not be hidden behind sticky headers, cookie banners or other overlapping content.
Target size
Interactive targets should be large enough, or spaced far enough apart, to be activated easily by people with limited dexterity. Small icon buttons placed close together are the usual problem.
Dragging alternatives
Any action that relies on dragging, such as reordering a list or moving a slider, should also be possible with a single pointer action like a click or tap.
Accessible authentication
Signing in should not depend on a cognitive test, such as remembering a password without support or solving a puzzle, unless an alternative or assistance is provided. Allowing password managers and paste is a simple step towards this.
Consistent help
Where help options such as contact details or a chat link appear on multiple pages, they should appear in the same relative place each time.
Redundant entry
Users should not have to re-enter information they have already provided in the same process. Either fill it in for them or let them select it.
Test automatically, then manually
Automated tools are useful but only catch part of the picture. We use both.
- Automated checks in CI: run accessibility linting and automated scans on every build, so regressions are caught before they are merged
- Manual testing: keyboard-only walkthroughs, zoom and text resizing, reflow at narrow widths and checks on content
- Screen reader testing: test key journeys with more than one screen reader and browser combination, on desktop and mobile
Record what was tested, how and with what result. That evidence feeds directly into your accessibility statement.
Commission an independent audit
Before launch, and after significant changes, an independent accessibility audit gives an objective view. Auditors often find issues that a team close to the work has stopped noticing. Plan time to fix what is found, and retest.
Publish an accessibility statement
The 2018 regulations require public bodies to publish an accessibility statement. It should set out how accessible the service is, list known issues and any content that is not yet accessible, explain how users can report problems or request information in another format, and describe the enforcement procedure.
Treat the statement as a living document. Review it when the service changes and when issues are fixed.
How we work
Accessibility is part of how our software engineering team builds services, not a separate phase. We build to WCAG 2.2 AA from the first sprint and plan for independent audit before launch.
Talk to us
To see how we approach public sector delivery, visit our public sector page, or contact us to discuss your service.