When a ministry, a municipality or a public hospital buys your product, it does not only buy features. It buys an obligation of its own. Public bodies in the EU have to make their websites and mobile apps accessible, and say publicly how far they have got. If your product is part of what they put in front of the public, their obligation becomes your roadmap.
That obligation comes from Directive (EU) 2016/2102 of 26 October 2016, on the accessibility of the websites and mobile applications of public sector bodies. It is often called the Web Accessibility Directive. This guide covers what it asks of those bodies, in plain terms, with the source linked next to each legal fact.
It is not legal advice, and nothing here says whether your product, or your customer’s site, meets the law. That judgement belongs to you, your customer and your advisers. If you sell to consumers rather than public bodies, the law to read is a different one, covered in The European Accessibility Act, for product leaders.
It applies through national law
The Directive is addressed to Member States, and each one carries it into its own law. Under Article 12, the national laws were due by 23 September 2018. The same article staged when they apply: to websites of public sector bodies not published before 23 September 2018, from 23 September 2019; to all other websites of public sector bodies, from 23 September 2020; and to their mobile applications, from 23 June 2021.
Article 2 allows Member States to go further than the Directive. So the text your customer works to is their country’s law, which may differ in its details. EUR-Lex lists the national measures each country has reported. When a tender cites accessibility, read the national rule it points to, not only the Directive.
Who counts as a public sector body
Article 3 defines a public sector body as the State, regional or local authorities, bodies governed by public law, and associations formed by them. That reaches further than central government.
Article 1 leaves some out, such as the websites and apps of public service broadcasters and their subsidiaries. It also excludes some kinds of content, for example third-party content that is neither funded nor developed by, nor under the control of, the public sector body. Whether software a body buys and puts in front of the public counts as its own content, or as third-party content, is a question for your customer and their advisers. Don’t assume the answer in a sales conversation.
What it asks: four principles and a standard
The core requirement is short. Article 4 asks Member States to ensure that public sector bodies make their websites and mobile applications more accessible “by making them perceivable, operable, understandable and robust”. Those are the four principles that organise the Web Content Accessibility Guidelines. What the latest version adds is covered in WCAG 2.2, for product leaders.
The detail sits in a standard. Under Article 6, content that meets harmonised standards whose references are published in the Official Journal is presumed to conform to those requirements. The Commission published that reference in Implementing Decision (EU) 2018/2048 of 20 December 2018, which first listed EN 301 549 V2.1.2 (2018-08). The decision has since been amended by Implementing Decision (EU) 2021/1339 of 11 August 2021. The consolidated version on EUR-Lex, checked when this was written, lists EN 301 549 V3.2.1 (2021-03). Check the current version before you put a reference in a proposal.
There is room in the text. Article 5 says public sector bodies apply the requirements to the extent that they do not impose a disproportionate burden. The body makes that assessment itself, and if it relies on it, it explains in its accessibility statement which requirements it could not meet.
The accessibility statement
This is the part your customer publishes, and the part that names your product’s gaps in public.
Article 7 asks public sector bodies to provide and regularly update “a detailed, comprehensive and clear accessibility statement” on their compliance with the Directive. For a website, it is published on the website, in an accessible format. For a mobile app, it is available on the website of the body that developed the app, or alongside the other information given when the app is downloaded.
The statement includes three things:
- an explanation of the parts of the content that are not accessible, the reasons, and accessible alternatives where appropriate;
- a description of a feedback mechanism, and a link to it, so people can report a failure and ask for information that was left out;
- a link to the enforcement procedure that Article 9 asks each Member State to provide.
The statement follows a model. The Commission set it out in Implementing Decision (EU) 2018/1523 of 11 October 2018. In the model, the body declares its site or app “fully compliant”, “partially compliant” or “not compliant” with the standard it names. It then lists the content that is not accessible and why, says when the statement was prepared and last reviewed, and gives feedback, contact and enforcement details.
What this means when you sell to public bodies
Expect the statement to be about you. If your product is a large part of what the public sees, your gaps become lines in your customer’s statement. A buyer who has to write “partially compliant” will want to know what you are doing about each one.
Know your own gaps before the buyer asks. A short, honest list of what does not yet work with a keyboard or a screen reader is more useful to a public buyer than a general assurance. It is also the starting point for your roadmap.
Start where people complete something. Applying, booking, paying, signing in and finding information carry most of what the public comes to do. Those journeys are where an inaccessible part costs a citizen the most.
Make new work meet the level from the start. Every release can add something that later lands in a statement. Holding new features to the level your customer works to stops that list from growing.
Keep your documentation and your product in step. If you describe your product’s accessibility to a buyer, that description has to stay true as the product changes.
Leave the legal questions to the advisers. Scope, the national rule and the disproportionate burden assessment are for your customer and the lawyers to answer. You can choose the direction of the product.
Settle those choices once and hold them, and the next tender reads less like a test and more like a description of the product you already have.
Where we come in
We do not give legal advice, we make no promise about compliance, and we do not tell anyone their product is ready for a tender. That judgement stays with you, your customer and your advisers.
Our own website is the example we can point to: This website is held to WCAG 2.1 level AA on every page.
On your product, we can take on the work itself, described in Make your product accessible: making the journeys that matter usable with a keyboard and a screen reader, and holding new work to the level you choose. The work lands in your own code repository. The code we build for you is yours. You decide what ships. Nothing reaches your users without your approval.
It starts with a conversation, with no obligation.
