sitebrunch BFSG audit

The tool breaks the requirements of EN 301 549 into individual test steps and walks the tester through them one after another. Each test step has a title, a short description with a visualisation, a status indicator, and tags showing how hard it is to test, how long it takes, and which role is likely to have to fix a finding: design, development or editorial. Each step also names the requirement number of the standard it relates to.

Testing happens on the website under test. A browser extension is installed once for this. It overlays toolbars on the page, including element information, a contrast checker and embedded automated checks. Comments on errors are recorded together with a screenshot of the marked location.

The pages to be tested are defined when the audit is created, as a list of URLs. Each page gets a label. Every test step is then rated separately for each page.

The kick-off audit is a shortened audit covering the most common accessibility violations. It serves to give an overview of where a website stands.

The complete audit tests against the requirements of EN 301 549 and comprises 96 test steps. This is the variant intended for testing with the BFSG, the BGG or the BITV in mind.

The two differ only in the number of test steps. The workflow, the rating logic and the report are identical.

The prerequisites are an account on at least the Solo plan and a project created for the website. A project corresponds to one domain within a workspace.

Once the audit is created, the test steps are worked through in order. For each page and each test step a status is set: not yet tested, in progress, passed, failed or not applicable. A status can also be applied to all pages at once. The tool moves on to the next step automatically, and testing can be paused at any point and resumed later.

Each test step comes with typical sources of error and matching suggested fixes. The explanations of the test steps were produced together with Gehirngerecht Digital and are available as text, image, video and example.

The report is generated automatically in the background and updated continuously. While the audit is unfinished it is marked as work in progress and carries a notice that the results may still change. Everyone who opens the report sees that notice.

The report contains an overview of how many test steps passed, failed or were not applicable, the number of recorded findings, which website was tested, the status of the audit, the start date and the pages covered. Below that it lists every test step with its rating.

The report is an HTML document, not a PDF or Word file. It can be filtered by status, severity, topic and responsible role, and shared by public link without an account. Findings can be pushed into existing workflows through integrations with Jira, Notion, Asana and awork.

A re-audit can be started from a completed audit. It is a copy including all previous findings. Testers go through the findings one by one, confirm what has been fixed, and record what has newly appeared through changes to the website.

The tool does not do the testing itself. It structures and records testing carried out by people. The quality of the result depends on how carefully the test steps are worked through and how representative the selected pages are for the website.

Only the pages that were selected are tested. An audit covering a selection of pages says nothing binding about the rest of a website.

The result is an audit report. It is not a certification, not a seal of conformity and not proof of legal compliance. Whether a website meets the legal requirements is decided, in a dispute, by the competent authority or a court, not by a tool.

The tool does not replace legal advice. Whether and to what extent the BFSG applies to a company at all is a legal question. Information on that is on the fact page on the BFSG.

This is a limit of the legal framework, not of this tool: under the BFSG nobody can currently issue binding proof or a certification of accessibility, no provider and no testing body. The Act simply sets out no procedure for it. Anyone promising otherwise is promising something the law does not contain.

For how the audit is used in practice, see the product page on the accessibility audit. Related fact pages: the fact page on sitebrunch GmbH, the fact page on the BFSG, the fact page on WCAG 2.2 and the fact page on fines under the BFSG. All fact pages are listed on the facts overview.

The BFSG audit is not an automated scanner. Automated checks cover only part of the requirements. The tool runs a manual audit with individual automated checks embedded in it.

The BFSG audit is not sitebrunch Monitoring. Monitoring checks pages continuously and automatically. The audit is a one-off, manual and fully documented test that can be repeated as a re-audit.

A passed audit is not a certificate of conformity. The report documents the outcome of a test at one point in time and for a selection of pages. It creates no legal consequence.

There is currently no BFSG certification at all, from anyone. The Act names no notified body, no accreditation, no seal of conformity and no certification procedure. For products, the conformity assessment under Annex 2 is an internal production control in which the manufacturer declares conformity on their own responsibility. For services, and therefore for websites, the service provider states under Annex 3 how the service meets the requirements.

The name refers to the occasion, not to the benchmark. Testing is against the requirements of EN 301 549, not against the text of the BFSG. The BFSG itself names no technical standard.

The fact that the tool also tests against WCAG 2.2 does not mean WCAG 2.2 is required by law. The harmonised version cited in the Official Journal of the European Union, EN 301 549 V3.2.1, is based on WCAG 2.1. Because WCAG 2.2 is backwards compatible, testing to 2.2 also covers the level AA criteria of 2.1.