Accessible public digital services: what to check on your website and online platforms
Public sector websites in the EU have to be accessible to people with disabilities. The Web Accessibility Directive requires it, and the practical work comes down to four areas: online forms and payments, downloadable documents, booking systems, and site navigation. This guide explains what to check in each one and how to fix it.
Most interactions with the state now start online. People apply for permits, pay local taxes, download certificates and book appointments without ever visiting an office. That only works if everyone can use these services. For people with visual, hearing, motor or cognitive disabilities, and for many older people, a badly built public platform is a locked door. And unlike an online shop, a city hall or a public hospital has no competitor to switch to.
Why is accessibility mandatory in the public sector?
In the EU, Directive (EU) 2016/2102, the Web Accessibility Directive, requires public sector bodies to make their websites and mobile apps accessible. Each member state has turned it into national law, with its own monitoring body. It covers central and local government, and also many bodies governed by public law, such as public hospitals and universities.
The directive sets three ongoing duties: meet the accessibility requirements, publish an accessibility statement with a way for people to report problems, and give users a route to complain if they get no answer. National authorities check websites regularly and report the results to the European Commission.
The technical reference is the European standard EN 301 549, which uses the WCAG 2.1 level AA success criteria for web content. The new edition of the standard, published in 2026, moves to WCAG 2.2, so it makes sense to test against WCAG 2.2 already. Our guide to EN 301 549 v4.1.1 explains what changed.
The European Accessibility Act is a separate law. It covers certain products and services, mostly from private companies, and is not the main framework for public sector websites.
What should you check on a public sector website?
Public platforms often combine complex forms, databases, dynamic content and a huge number of downloadable documents. In practice, most barriers show up in four places.
1. Online application forms and payments
Filing a declaration or paying a tax means filling in several interactive fields.
- Barrier: fields without proper labels, or error messages that are unclear, block people who rely on a screen reader.
- Fix: give every field a label that is linked to it in the code, and explain errors in text that the screen reader announces, not only with a red border.
2. Public documents and downloadable forms (PDF)
Council decisions, standard forms and guides are often uploaded as scanned PDF files.
- Barrier: a PDF saved as an image can't be read by assistive technology, so the public information inside it is out of reach.
- Fix: publish structured, tagged PDFs that work with a keyboard. Our guide shows how to check and fix a PDF.
3. Appointment booking and interactive calendars
Systems for booking a slot to pick up documents often use visual date pickers that are hard to operate.
- Barrier: if the calendar can't be used with the keyboard alone, people with motor disabilities and screen reader users can't finish the booking.
- Fix: build booking flows that work fully from the keyboard, with a clearly visible focus indicator.
4. Navigation and access to public information
Crowded menus and a missing heading structure make it hard to find anything quickly.
- Barrier: an overloaded homepage without landmarks forces keyboard and screen reader users through the same menus on every page.
- Fix: use headings from H1 to H6 in a logical order, landmark regions, and a "Skip to main content" link.
How do public bodies meet WCAG in practice?
1. Automated scanning and a first technical review
Start with an automated check of the code to catch the most common errors across hundreds of pages:
- Color contrast: text that doesn't stand out enough from its background.
- Missing alt text: images, coats of arms and logos without a text description.
- HTML structure: errors in headings, lists and page structure that affect the whole site.
You can start with a free scan of a page. An automated scan gives you a first overview, but many WCAG criteria can't be checked by software. For the full picture you need an accessibility audit by experts.
2. Manual testing with assistive technology
No automated tool can reproduce what a real person goes through. Manual testing checks how the interface behaves in actual use:
- Keyboard navigation: going through every step of an application without a mouse.
- Screen reader testing (NVDA, JAWS, VoiceOver, TalkBack): checking how content is read out and whether forms give clear instructions.
- Transparency: writing and publishing an up-to-date accessibility statement, as the directive requires.
3. Fixing issues in the code
Real accessibility needs changes in the platform itself:
- Semantic HTML and ARIA: buttons, menus and dialogs are built so that assistive technology recognizes them correctly.
- Visual flexibility: text can be enlarged to 200% without losing content or functions, and without elements overlapping.
Fixes in the code, followed by re-testing, solve the cause of the problem. See what you get after an evaluation on our accessibility audit report page. Because public websites change every week, recurring accessibility monitoring helps you catch new errors after content updates.
Make digital public services work for every citizen
Online platforms are now the main point of contact between citizens and the state. Investing in accessibility means services that more people can use on their own, fewer requests at the counter, and equal access for everyone.
Talk to an expert about evaluating your institution's digital services
Frequently asked questions
Which law makes public sector websites accessible in the EU?
Directive (EU) 2016/2102, the Web Accessibility Directive. It applies to websites and mobile apps of public sector bodies, and each member state has its own national law that implements it. Check the national law and the monitoring body in your country for the details that apply to you.
Which WCAG level do public sector websites need to meet?
The directive refers to the European standard EN 301 549, which uses the WCAG 2.1 level AA success criteria for web content. The new edition of the standard, published in 2026, moves to WCAG 2.2, so testing against WCAG 2.2 now is a good idea.
Is an automated scan enough for a public website?
No. A scan finds some errors quickly, like low contrast or images without alt text. Keyboard navigation, reading order and clear form instructions can only be checked by people, using a keyboard and screen readers.
Sources