The Accessibility Requirements You're Responsible for as a Buyer
Since 2025, legal requirements for digital accessibility have covered many private services too, not just the public sector. As the buyer, you're responsible for making sure your website or app meets WCAG level AA. Write the requirement into the contract, set it early, and verify compliance at delivery – fixing it later gets more expensive.
Digital accessibility has gone from being an ambition for the public sector to becoming a legal requirement that affects a large share of the business world. As the buyer, you’re the one who bears responsibility for making sure the service you purchase actually meets the requirements. Here’s what you need to know to set the right requirements.
Who’s covered by the rules
For a long time, the clear requirements for digital accessibility mainly applied to the public sector. Since 2025, the picture has changed: many private services are now covered too, as a result of the Accessibility Act. That broadens the scope considerably.
In practice, this affects e-commerce, banking services, and a range of digital consumer services, among others. Exactly what’s covered depends on the nature and context of the service, and the line can be tricky to draw in individual cases. The sensible starting point is therefore to assume the requirement applies, and check your specific situation – not the other way around. Assuming you’re exempt is an expensive guess if it turns out to be wrong.
The point is that this is no longer a question just for public authorities. If you’re building a digital service aimed at consumers, there’s a good chance accessibility is a requirement you have to deal with.
The WCAG levels, plainly explained
The actual yardstick is called WCAG – an international standard for how websites and apps are made usable for people with disabilities. It has three levels, and it’s easy to get lost among them.
| Level | What it means |
|---|---|
| A | Basic – necessary but far from sufficient on its own |
| AA | The practical standard and the level legal requirements normally point to |
| AAA | Strictest – rarely realistic to achieve in full for an entire service |
In almost every context, it’s level AA that applies. When someone says a service should be “accessible,” in practice they almost always mean WCAG 2.2 level AA. A is too low, and AAA is rarely achievable everywhere. Aim for AA and be consistent.
Write the requirement into the contract
The single most important thing you can do as a buyer is to make accessibility an explicit requirement in the contract – not a hope, not a clause buried at the back, but a condition for accepted delivery.
Concretely, the contract should state that the delivery must meet WCAG 2.2 level AA, describe how that will be verified, and specify what applies if deficiencies are found. A requirement that isn’t written down is hard to enforce later, no matter how obvious it seemed at the outset. But if it’s in black and white that the AA level is part of what you ordered, you have something to stand on.
Set the requirement early. Accessibility affects fundamental design choices – color contrast, structure, how things are navigated – and those are expensive to redo late. If the requirement only comes up at final inspection, much is already set in stone, and the fix becomes needlessly costly.
How compliance is verified at delivery
Trusting that the vendor “thought about it” isn’t enough. Compliance needs to be verified, and that’s best done with a combination of methods, since no single one catches everything.
Automated tools are a good start – they scan the pages and find some errors automatically, quickly and cheaply. But they miss a large share of the problems, especially those about whether something can actually be understood and used. That’s why manual review against the WCAG criteria is also needed, along with testing with a keyboard and a screen reader, to catch what the tools don’t see.
A concrete example: an automated tool can confirm that an image has alt text, but only a human can judge whether the text actually describes the image in a meaningful way. So require both automated and manual verification, and ask to see the results before you approve the delivery. Want help setting requirements and verifying accessibility? It’s part of our services – get in touch and we’ll sort out what applies to you.
Frequently asked questions
Which businesses are covered by the Accessibility Act?
Since 2025, many private services are covered in addition to the public sector, which was already included. That covers e-commerce, banking services, and digital consumer services, among others. Exactly what's covered depends on the nature of the service, so check your specific situation – but assume the requirement applies rather than the reverse.
What do the WCAG levels A, AA, and AAA mean?
They indicate a level of ambition. A is basic and far from sufficient on its own. AA is the practical standard and the level legal requirements normally point to. AAA is the strictest and rarely realistic to achieve in full for an entire service. When someone says "accessible," they almost always mean WCAG level AA in practice.
How do I write the accessibility requirement into a contract?
State explicitly that the delivery must meet WCAG 2.2 level AA, and make it an accepted delivery requirement rather than a clause buried at the back. Describe how it will be verified and what applies if deficiencies are found. A requirement that isn't in the contract is hard to enforce later, no matter how obvious it seemed.
How is a delivery verified as accessible?
Through a combination: automated tools catch some errors automatically, but far from all of them. On top of that, manual review against the WCAG criteria is needed, along with testing with a keyboard and a screen reader. Automation alone gives false confidence – it misses exactly the problems that affect real users the most. So require both.
What happens if the service doesn't meet the requirements?
Insufficient accessibility is a regulatory violation and can lead to demands for corrective action and other penalties, while also shutting out some of your users. Building it right from the start is cheaper than fixing it later, because accessibility affects fundamental design choices that are expensive to redo late.