Skip to content

BITV assessment per EN 301 549 for websites and web applications of public bodies

Expert evaluation following the test procedures of the standard, conformance level AA: we assess every test step of clauses 9 and 11.7 in every view, in the desktop and the smartphone presentation, the other requirements of Table A.1 for the application as a whole, and determine the additional duties under BITV 2.0. You receive an audit report as an accessible PDF with a prioritised list of findings and a solution path for each finding.

Request a free consultation All services
EN 301 549 V3.2.1 · Table A.1 · Level AA Audit report as an accessible PDF Own accessibility statement published

In short and in plain language

This page is about our test for public offices and other public bodies. Strict rules apply to them. The rules help everyone use their websites.

We check the rules for websites on each page. We look at each page as it looks on a large screen. And as it looks on a phone. We use everything without a mouse.

We also check what the page passes on to programs that read text aloud. We do not test with such a program itself. We also do not test with disabled people.

You get a report. It lists each problem with a way to fix it. The most serious problems come first. A short version helps you with your accessibility statement.

The test has a fixed price. Write to us or give us a call.

Key figures

V3.2.1

version of EN 301 549 currently cited in the EU Official Journal

Table A.1

test steps from Annex A of the standard

Level AA

test steps assessed per view

4 levels

of severity in the list of findings

BITV assessment per EN 301 549

from €2,980 fixed price net, one-off
  • Test steps of Table A.1 assessed per view
  • Additional duties under BITV 2.0: statement, feedback, explanations
  • List of findings by severity with code example
  • Summary as the basis for your accessibility statement
Request a free consultation All prices at a glance

For up to 11 views, each in the desktop and the smartphone presentation. Each additional view €190, re-test after remediation €590. All prices net plus VAT, prices as of October 2026. No ongoing costs, no minimum term.

Which standard applies to public bodies

BITV 2.0 applies to federal public bodies in Germany. It links the presumption of conformity to harmonised standards cited in the Official Journal of the EU (Section 3 (2) BITV 2.0); at present this is EN 301 549 V3.2.1 (Implementing Decision (EU) 2021/1339). Public bodies of the federal states and municipalities are subject to the laws and ordinances of their state, which as a rule refer to the same standard. Which rule applies in an individual case is a legal question; the assessment evaluates the technical state. The page on accessibility for public procurement gives an overview.

Anyone who runs or develops websites or web applications for public bodies measures accessibility against a different yardstick than a company under the BFSG: EN 301 549 and its Table A.1. This table contains the WCAG 2.1 success criteria at levels A and AA, but also requirements that appear in no pure WCAG audit, such as platform user preferences, authoring tools, and documentation and support. On top of that come the duties of BITV 2.0 itself: a reachable accessibility statement, a feedback mechanism, and explanations in German Sign Language and Easy Read on the home page. Our BITV assessment evaluates all of this on complete views and complete processes: every test step per view, in the desktop and the smartphone presentation, with the keyboard and with a view to what the page passes to the browser's accessibility API. The result is an audit report as an accessible PDF in German, which you can use to document the state, plan the remediation and write your accessibility statement.

The test standard in layers

BITV assessment · EN 301 549 V3.2.1 · Level AA
What Table A.1 requires beyond WCAG
Each layer assessed separately in the audit report
9
Clause 9 · Web content
WCAG 2.1 success criteria, levels A and AA, plus the conformance requirements in 9.6
per view
5
Clause 5 · Generic requirements
Accessibility features, biometrics, preservation during conversion
where applicable
6·7
Clauses 6 and 7 · Voice and video
Two-way voice communication and video capabilities of the application
where present
11
Clause 11 · User preferences and authoring tools
11.7 follow the browser settings, 11.8 where users create content
11.7 per view
12
Clause 12 · Documentation and support
Product documentation and support services, based on your documents
for the application
§
BITV 2.0 · Additional duties
Statement reachable, feedback mechanism, explanations in German Sign Language and Easy Read
presence
Clause 10, downloadable documents: separate serviceWCAG 2.2 as a note
Test methodAnnex C of the standard
Audit reportaccessible PDF
Schematic view of the test standard per EN 301 549 V3.2.1, Table A.1, and BITV 2.0.

What Table A.1 requires beyond WCAG 2.1

EN 301 549 is the European standard for the accessibility of information and communication technology. In Table A.1, its Annex A maps which of its requirements apply to websites so that the requirements of EU Directive 2016/2102 can be presumed to be met. The largest part is clause 9: the WCAG 2.1 success criteria at levels A and AA, numbered according to the standard. This turns 1.1.1 Non-text Content into test step 9.1.1.1, and 4.1.2 Name, Role, Value into test step 9.4.1.2. In our report, a test step means exactly one such requirement of Table A.1, assessed according to the corresponding test procedure in Annex C of the standard.

Testing against WCAG alone leaves the remaining rows of the table open. They concern less the individual page than how the application works together with the browser, with the people who create content in it, and with the documents users receive. A web application can meet every WCAG criterion and still have its input fields and focus disappear as soon as someone turns on forced colours. Or its help page may not describe a single accessibility feature. The BITV assessment therefore covers all requirements of the table that apply to web content and marks non-applicable ones with a reason. Downloadable documents under clause 10 of the standard are a separate service.

Clause 9: web content per WCAG 2.1

All success criteria at levels A and AA as listed in Table A.1, assessed per view and presentation. Plus the conformance requirements in 9.6: complete pages, complete processes and accessibility-supported technologies, judged by their documented support.

Clause 5: generic requirements

Whether documented accessibility features can be activated in a way the people concerned can use (5.2), whether the application does not rely solely on one biometric characteristic (5.3), and whether accessibility information is preserved during a conversion (5.4), as far as this can be tested on the application.

Clauses 6 and 7: voice and video

If the application offers two-way voice communication or video capabilities, such as calling in the browser or videos with their own controls, we test the requirements of clauses 6 and 7 as far as they can be tested on the interface in the browser; measurements of the transmission such as frame rate or audio bandwidth are not included. If these features are absent, the report marks the requirements as not applicable, with a reason.

11.7: user preferences

Whether the application follows the browser settings: forced colours, increased contrast, a larger default font size and a different default font, and whether the focus indicator remains visible. Assessed per view and presentation, with the browser as the platform.

11.8: authoring tools

If users can create content in the application that others will read later, it counts as an authoring tool. We then test whether it enables accessible content and preserves accessibility information. Otherwise the report marks 11.8 as not applicable.

Clause 12: documentation and support

Whether the product documentation describes the accessibility features and whether the support channels provide information about them and accommodate the communication needs of people with disabilities. The basis is the documents you give us; test requests to your support are not part of the assessment, nor is whether documentation in file form meets clause 10 (12.1.2, 12.2.4).

What BITV 2.0 additionally requires

Besides the standard, BITV 2.0 sets its own requirements for the website of a public body. We determine whether they are implemented and record the result in the report separately from the test steps of Table A.1. If the accessibility statement itself is part of the scope, we also assess it like any other view against the standard.

Statement reachable (Section 7 (1))

Whether the accessibility statement can be reached from the home page and from every view tested. If the link is only on the home page or in a menu that cannot be opened with the keyboard, this appears as a finding in the report.

Feedback mechanism (Section 7 (2))

Whether the statement names a feedback mechanism through which users can report barriers, and whether it is directly accessible from every view. We report direct accessibility as a recommended requirement, as the ordinance phrases it.

Sign language and Easy Read (Section 4)

Whether the home page offers explanations in German Sign Language and in Easy Read. We determine their presence, not the quality of their content. We produce Easy Read texts as a separate service: Easy-Read Language.

Our test approach: expert evaluation per Annex C

The BITV assessment is an expert evaluation following the WCAG conformance requirements: we assess complete views and complete processes, not individual components. Automated measurements provide data for many test steps, but a person makes the decision: whether an alternative text describes the image, whether an error message is sufficient for correction, and whether a status message is passed to the accessibility API. Every step of our approach can be traced in the report.

At the start we record the date, address and screenshots of the version tested. The report refers to this state. For the result to remain reliable, the version should stay unchanged from the cut-off date until delivery; the assessment does not cover later changes.

What the audit report contains

The audit report is an accessible PDF in German. It is written for two readers at once: the development team that is to fix the findings, and the body that has to document the state towards clients, funding bodies or the responsible monitoring body. The results per test step are structured so that you can use the summary directly as the basis for your accessibility statement.

Result per test step and view

Audit report · excerpt
Result per test step and view
D = desktop presentation · S = smartphone presentation
Test stepHome pageContact formResult
9.1.1.1 Non-text contentD and S passD and S passpass
9.1.2.2 Captionsnot applicablenot applicablenot applicable
9.1.4.10 ReflowD and S passS failfail
9.2.1.1 KeyboardD and S passD and S passpass
9.4.1.3 Status messagesnot applicableD and S failfail
11.7 User preferencesD and S passD and S passpass
Findings with remediation notes
9.4.1.3 Contact form — message after sending is not exposed · add a status role
9.1.4.10 Contact form, S — input fields overflow at 320 pixels · use relative widths
Severity levelscritical · high · medium · low
Summaryone page at most
Example view of an excerpt from the audit report — values illustrative.

Summary of the conformance status

At the start: how many test steps pass, fail or are not applicable, where the most serious findings are and what to do first. Readable without technical background.

Result per test step and view

For every test step of Table A.1 and every view tested: pass, fail or not applicable, in both presentations. The reasoning names the views in which a test step fails or is not applicable. Requirements on the application as a whole are assessed once.

List of findings by severity

Every finding with test step, view, screenshot and description, classified into four severity levels from critical to low. The order shows which barriers prevent a process and which make it harder.

Remediation note with code example

For every finding a solution path with a code example, derived from the delivered markup and suited to the technology in use. We group recurring patterns so that your developers fix them at the cause rather than at every single place.

Summary on one page at most

Test object, state, standard, result and the requirements not met, on one page. It is the basis for your accessibility statement and can be passed on to clients or funding bodies.

Notes and follow-up questions

We report the criteria that WCAG 2.2 added at levels A and AA as notes; they do not enter the result per Table A.1. We answer questions about the report by email for up to four weeks after delivery.

What the BITV assessment does not include

Tests with screen readers and with specific browsers or devices; what is assessed is what the application passes to the browser's accessibility API. Tests with people with disabilities. A test seal, test mark or certificate. Legal advice, for example on which rules apply to you. Fixing the findings; for that we offer accessible development. Reviewing the content of explanations in German Sign Language and Easy Read. Downloadable documents under clause 10 of the standard; for PDF documents there is the separate service accessible PDF. The assessment evaluates the recorded state and does not cover later changes.

Do you have to show how accessible your application is under BITV 2.0?

We assess the test steps of Table A.1 per view in the desktop and the smartphone presentation and deliver the report as an accessible PDF, with a summary for your accessibility statement.

Request a fixed-price offer Call now: +49 5123 9579000

Process: from the fixed-price offer to delivery

Before we write an offer, we look at your website or application: which views exist, which states and processes belong to them, and which requirements from clauses 5 to 12 of the standard are likely to apply. This results in a fixed-price offer with the standard, the scope and the list of views. We align the schedule with the cut-off date on which you freeze the version to be tested.

You give us the address of your website or application and, if available, your service specification. We review views, states and processes and propose a selection of views. This results in a written fixed-price offer with scope, standard and list of views.

What counts as a view

The fixed price is based on the number of views. A view is a separate page, a separate step of a process or a separate document generated by the application. We test every view in the desktop and the smartphone presentation. Whatever opens or changes within a view belongs to it and is included in the price: dialogs, menus, expanded sections, notes, error messages, conditional questions and editable lists. Areas that appear on every view, such as the header, navigation and footer, are tested as well.

For the selection: better all views of a process than a sample. WCAG requires conformance of complete processes; if one step of an application form cannot be operated, neither can the whole form. After the review we propose a selection that fully covers the processes and state the number of views in the offer. If another view is added before the cut-off date, the price per additional view applies; if one is dropped, the fixed price remains unchanged.

Pricing: a fixed price based on views

The BITV assessment is a one-off fixed price for the agreed scope. There are no ongoing costs and no minimum term. Additional views and the re-test are options; we only invoice them once we have delivered them, and unused they cost nothing.

BITV assessment: fixed price and options

All prices net plus VAT, prices as of October 2026. One-off services with no ongoing costs and no minimum term; the fixed-price offer after the review states the exact scope.

Core service

BITV assessment

Assessment per BITV 2.0 and EN 301 549 V3.2.1, Table A.1, level AA, for up to 11 views.

from €2,980 fixed price, one-off
  • Every view in the desktop and the smartphone presentation
  • Test steps assessed per view, with reasons
  • Additional duties under BITV 2.0 determined
  • List of findings by severity with code example
  • Summary on one page at most
Request a fixed-price offer

Additional view

For each view beyond the 11 included in the fixed price, in both presentations.

€190 per view, one-off
  • All test steps assessed as in the fixed price
  • Desktop and smartphone presentation
  • Can be ordered with the order or up to the cut-off date
  • Invoiced only after the assessment
Ask about scope

Re-test

After your remediation: all findings tested again, plus a sample check for new findings.

€590 one-off, one round
  • All findings from the audit report again
  • Sample check for new findings
  • Audit report, findings and summary updated
  • Date agreed after your remediation
Ask about a re-test

For comparison: the WCAG 2.2 AA audit for websites up to 30 pages per clause 9 of the standard is available from €2,480 net. Anyone who has to demonstrate conformance under BITV 2.0 or offers a web application for public bodies needs the requirements of Table A.1 beyond clause 9.

AspectWCAG 2.2 AA auditBITV assessment
StandardWCAG 2.2, levels A and AAEN 301 549 V3.2.1, Table A.1, level AA
Clauses of the standardClause 9 (web content)Clause 9 plus 5, 6, 7, 11.7, 11.8 and 12, where applicable
Additional duties under BITV 2.0not included statement, feedback mechanism, explanations in sign language and Easy Read
User preferences (11.7)not included per view and presentation
Basis of the pricewebsite up to 30 pagesnumber of views, each in two presentations
Typical usecompany websitespublic bodies and their suppliers
Resultprioritised list of findings with solution coderesult per test step and view, list of findings, summary

Who the BITV assessment is for

Authorities

Federal and state authorities with websites, online services and specialist applications that must be accessible under BITV 2.0 or the rules of their state and that state their status in their accessibility statement.

Municipalities and districts

Citizen portals, appointment booking, council information and online applications. State rules as a rule refer to the same standard; we do not judge which rule applies in an individual case.

Public institutions

Chambers, social insurance bodies, cultural institutions and other institutions classified as public bodies that run websites or web applications.

Universities

University websites, application portals, learning platforms and student administration applications. Web applications with forms and status messages in particular show, in the per-view assessment, where processes break off.

Providers of specialist software

Companies that develop specialist procedures, portals or web applications for public bodies and want to demonstrate accessibility in a tender or before acceptance.

Funded projects

Projects whose results public bodies are meant to reuse. An audit report per Table A.1 shows the state before a body takes over the application and names what needs fixing first.

What we need from you

  • the address of the version to be tested and the cut-off date from which it stays unchanged
  • a version that remains unchanged from the cut-off date until delivery, or advance notice of planned changes
  • for clause 12 of the standard, your product documentation and details of your support channels, in the form in which users receive them
  • if available, your service specification or your client's requirements on the scope
  • answers to questions, which we collect and send by email
  • sample data instead of real data: we do not need personal data for the assessment

Typical findings beyond the WCAG criteria

11.7 User preferences
Starting point
With forced colours, the borders of the input fields and the focus indicator disappear, because both are styled only with background colours and shadows.
Measure
Mark borders and focus with lines instead of shadows and test the presentation with forced colours specifically.
Result
Goal: fields and focus remain recognisable in the system colours, 11.7 is met.
Section 7 BITV 2.0
Starting point
The accessibility statement is only linked from the home page; the link is missing in the steps of an application form.
Measure
Add links to the statement and the feedback mechanism to the shared footer of all views.
Result
Goal: statement and reporting channel can be reached from every view.
9.4.1.3 Status messages
Starting point
After saving, the note “Changes saved” only appears visually; it is not passed to the accessibility API.
Measure
Output the note in an area with a status role that already exists when the view loads.
Result
Goal: screen readers can announce the message without the focus jumping.

Example scenarios for illustration, not client projects.

Key Takeaways

  • The BITV assessment evaluates websites and web applications per EN 301 549 V3.2.1, Table A.1, level AA, the version currently cited in the EU Official Journal, to which Section 3 (2) BITV 2.0 links the presumption of conformity.
  • Beyond the WCAG 2.1 criteria in clause 9, we test clauses 5, 6, 7, 11.7, 11.8 and 12 of the standard where applicable, and the additional BITV 2.0 duties on statement, feedback and explanations.
  • Every view is assessed in the desktop and the smartphone presentation, with keyboard, zoom, user preferences and what is passed to the browser's accessibility API.
  • The audit report is an accessible PDF with a result per test step and view, a list of findings by severity with code examples, and a summary for the accessibility statement.
  • One-off fixed price based on the number of views, with no ongoing costs and no minimum term; tests with screen readers, user tests, seals and legal advice are not included.

Frequently asked questions about the BITV assessment

How the customer portal of a municipal utility could look

The draft shows structure and handling: short paths to meter reading and instalment, a form naming the error at the field, plain language and text size in the header. The utility in it is invented.

Draft
Municipal utility

Customer portal with self-service and plain language

A draft for a municipal utility portal: submitting a meter reading, adjusting the instalment and registering a move sit side by side as six short paths, and the form checks entries and places the error as text right next to the field. Reporting a fault is laid out in four steps, and the tariff comparison is a table with labelled rows and columns. Text size and plain language can be switched in the page header.

Plain languageText sizeForm validationFault reporting

Illustrative layout drafts. The businesses shown are fictitious; these are not client projects.

What can we help you with?

One click is enough — everything after that is optional.

Tell us briefly about the project

Everything on this step is optional.

As shown in your browser, with or without https://.

When would you like to start? (optional)
Rough budget range (optional)

Optional — you are not committing to anything.

A few keywords are enough. If you write something, please use at least 5 characters.

How can we reach you?

We usually get back to you within one business day.

Your name or surname, at least 2 characters.

Only needed if you would like a call back.

The address our reply should go to, with @ and domain.

By submitting you consent to the processing of your details to handle this request. Details in our privacy policy.