Non-conformant is a permitted answer

Almost every compliance document is designed to assert conformance. The accessibility statement is not. It knows three levels, fully conformant, partially conformant and non-conformant, and the last one is a permitted answer. Choosing it fulfils the obligation, as long as you explain what does not work.

That inverts the usual logic. What is examined is not the result but the honesty about it.

What such a statement has to contain

The mandatory fields under the German BITV 2.0 are uncomfortably concrete. Besides provider, scope and conformance status, the statement requires a list of the non-accessible content and the alternatives offered for it. Plus a feedback contact with name, address and telephone number, a reference to the enforcement procedure, and two dates instead of one: when the statement was drawn up, and when it was last reviewed.

The second date is the awkward part. A statement from 2023 that was never touched again says more about an organisation than any conformance status inside it.

Which is why the statement needs substance behind it

Anyone required to name the non-accessible content has to know it first. The module therefore provides a path: create subjects, that is websites, web applications, documents or apps. On top of that an automated quick test that checks exactly the stored address and finds machine-detectable violations by analysing the page structure.

What the quick test explicitly cannot do

The scanner's header carries the sentence that makes the whole thing honest: deliberately not a complete test. Criteria such as contrast, keyboard operation or focus visibility need a rendered image or a human being. The automated part finds the common, unambiguously detectable barriers, and for the rest there is the guided manual audit against WCAG 2.2 with a configurable target level.

A tool that puts a green tick here has either not tested or not understood what needed testing.

A figure that deliberately does not collapse

The quick test produces a score, and a decision sits inside it that we like: repeat hits of the same check are capped. The code states literally that a page with eighty images lacking alternative text is not eighty times worse, the finding is the same. Without that cap a single image gallery would demolish any score and render the figure useless.

Barriers have a status, not just a date

Every finding is tracked as a barrier, with severity, the affected WCAG criterion and the snippet of the element complained about. A later run carries known findings forward and automatically marks vanished ones as resolved. That produces exactly what the statement needs: a list that changes, instead of boilerplate that stays put.

And the statement itself

It is derived from those results and served publicly, because it has to be reachable without signing in. From that follows a subtlety justified in the code: there is at most one statement per tenant plus one for the instance. The public page always serves the instance one, because at that point no tenant can be known.

More on the accessibility module page. Product-related context, not legal advice.