The European Accessibility Act, and the evidence Watchdog gives you

Who this is for: product, engineering and compliance leads at companies whose website, app or online shop serves consumers in the EU, and at companies that build software for public bodies. It covers what the Act asks for, what Watchdog checks at every survey, how you declare and sign, and the report you hand over.

The European Accessibility Act is Directive (EU) 2019/882. It sets common accessibility requirements across the EU for products and services that people use every day, so that people with disabilities can use them too. Each member state has written it into its own law, and those laws have applied since 28 June 2025.

It covers products such as computers and their operating systems, smartphones, payment terminals, cash machines, ticket machines and e-readers. It also covers services sold to consumers: online shops, consumer banking, e-books, electronic communications, access to audiovisual media, and the websites, apps and e-tickets of passenger transport. For a company whose product is software, the part that usually matters is the service, meaning the website or app through which consumers buy, bank, book or read.

Each member state sets its own penalties, which the directive requires to be effective, proportionate and dissuasive, and national authorities check that products and services comply.

Four questions settle most cases before any measurement is worth doing. The first is who the service is for. The Act covers services provided to consumers, meaning people acting outside their trade or profession. Software used only inside a company, or sold only to other businesses, is outside it. An online shop or an app is inside it as soon as consumers can buy, bank or book through it.

The second is the size of the company. A company providing services with fewer than 10 employees, and an annual turnover or balance sheet of no more than €2 million, is exempt from the requirements for services.

The third is what content the Act leaves out. On websites and apps it does not cover:

• video and audio published before 28 June 2025
• office documents published before 28 June 2025
• online maps, as long as the essential information is also given in an accessible way
• content from third parties that the company has neither paid for, developed nor controls
• archives that have not been updated or edited since 28 June 2025

The fourth is whether meeting a requirement would fundamentally change the product or service, or place a disproportionate burden on the company. A company that relies on this must assess it against the criteria in the Act, document the assessment, keep it for five years and tell the authorities. A service provider must renew the assessment at least every five years. A company that has received outside funding to improve accessibility cannot rely on the burden argument.

Public bodies’ own websites and apps fall under a separate law, the Web Accessibility Directive, which points to the same standard, EN 301 549. Companies that build software for public bodies often meet that standard through the buyer’s tender requirements.

The Act sets its accessibility requirements in its first annex. For websites and apps they come down to four principles: people must be able to perceive the content, operate it and understand it, and the content must work with the assistive technology they use, such as screen readers.

The Act leaves the technical detail to a European standard. A product or service that meets a harmonised standard cited in the EU’s Official Journal is presumed to meet the requirements. For websites and apps that standard is EN 301 549, whose web part is built on the Web Content Accessibility Guidelines (WCAG) from the W3C, at level AA.

EN 301 549 is changing version. Version 3.2.1 from 2021 is based on WCAG 2.1 and is the reference used today. Version 4.1.1, published in September 2026, moves to WCAG 2.2 and adds the requirements WCAG 2.2 introduced. It becomes the reference once the European Commission cites it in the Official Journal. Working to WCAG 2.2 now prepares you for both.

There is no certificate to buy. A service provider explains how its service meets the requirements in information it publishes, usually in its terms and conditions or an accessibility statement, and keeps that information available for as long as the service runs. A manufacturer documents its product, assesses it itself, signs an EU declaration of conformity and puts the CE mark on the product. Either way the company makes the declaration, and the national authorities check it.

Much of WCAG can be read from your code, and section 4 shows how much of it Watchdog checks for you at every survey.

As soon as a survey finds web pages in a repository, Watchdog grades their accessibility as part of the score and switches WCAG on for that repository, asking you once whether to keep it. From then on, every survey reads your web code for the problems that stop people from using your product:

• images, video and other content without a text alternative
• form fields, buttons and links without a name a screen reader can read out
• pages without a language, a title, a clear heading order or a main area, and pages that block zooming
• elements that can be clicked with a mouse but not reached with a keyboard
• incorrect use of the attributes that screen readers rely on (ARIA)
• focus outlines removed without a replacement, animation that ignores the user’s setting for reduced motion, and colour pairs in your stylesheets with too little contrast
• whether your team’s own tools check accessibility, through a lint rule set over the markup and accessibility tests in your build pipeline

Every problem is listed with where it was found and ranked with the rest of the survey, so your team or your coding agent can fix it, and the next survey shows whether it is gone. The engineering report also shows which WCAG criteria each check gives evidence for.

When Watchdog can start a copy of your product in its own sandbox, it also checks the pages as a browser shows them: contrast as it actually appears on screen, the order in which keyboard focus moves, and states that only exist once the page runs. It adds what it saw to the survey.

Watchdog lists the criteria that depend on meaning for a person at your company to judge, such as whether an image description says what the image shows, or whether an error message tells people how to put the mistake right. For EN 301 549, it lists the parts outside the web, such as hardware, documents and support services, in the same way.

You declare on the repository’s Compliance tab, in three steps. First you write the scope: which pages and parts of the product the declaration covers, and what it leaves out.

Then you answer every WCAG criterion as conforms, does not conform or not applicable. Beside each criterion the form shows whether a check, the running product or a person’s judgement decides it, and Watchdog’s survey gives you the findings to answer from. A criterion that does not conform, or does not apply, needs a note that explains it, and the note is printed in the report.

Last, a named person at your company signs with their name and role. Signing becomes possible once every criterion is answered and every gap or exclusion is explained. It freezes the answers and the version of the standard, and seals them with a fingerprint of the exact content (SHA-256), so any change made afterwards shows. A declaration can conclude that the product does not yet fully conform, and the report then shows exactly where.

When the product changes, you sign a new declaration. It replaces the current one, and the old one stays in the history. You can also withdraw a declaration, with a reason. For a product built from several repositories, the product’s compliance report holds the same declaration for the whole product. There, a criterion Watchdog caught failing stays open until a survey shows it fixed, and nobody can tick it off by hand.

A signed declaration becomes a conformance report (ACR) that you can open, print or save as a PDF from your browser, ready for a customer, a buyer or an authority. It is your company’s own declaration, which is what the Act asks for, and it holds:

• the standard and its version, such as WCAG 2.2
• who signed, their role, the date, and the fingerprint (SHA-256) that shows the text has not changed since
• the scope you wrote
• every criterion with its answer, whether a check, the running product or a person decides it, and your note
• how many criteria conform, out of the total

Three lines from an example report:

The compliance report for a whole product comes in English and Danish.

A company that buys software, or has it built, can make accessibility part of the deal. In Assay, our product for people who buy software, the buyer sets acceptance criteria for the supplier’s code. For accessibility they can require that the web pages are graded for accessibility, set a minimum grade, and require a current signed WCAG declaration.

Assay then checks each repository against those criteria. A signed declaration counts as soon as it is on file, whoever at the supplier signed it. If none exists, the criterion shows as not met, with the reason.

1. Check whether the Act applies. Go through the four questions in section 2 for each website and app. If none of them is in scope, you need none of the rest.
2. Survey the code behind your website and app. Connect the repositories, and the first survey grades their accessibility, switches WCAG on and lists every problem it finds with where it was found. The first survey of every repository is free.
3. Fix what the survey finds, starting at the top of the list. Your team or your coding agent can work through the list, and the next survey shows what is gone.
4. Make your own tools check accessibility. An accessibility lint rule set and accessibility tests in your build pipeline catch new problems before they reach your users, and the survey shows whether both are in place.
5. Name the person who declares. Decide who judges the criteria that need a person and who signs the declaration, and write down the scope it covers.
6. Publish what the law asks for, and keep it current. Put the information on how your service meets the requirements in your terms and conditions or accessibility statement, and keep the signed conformance report ready for customers, buyers and authorities. Survey on a schedule, and sign a new declaration when the product changes.

Legal note. This guide explains the Act and what Watchdog checks and records. It is not legal advice, and whether the Act applies to a particular product or service is for you and your advisers to decide.