English
a11yglass · Accessibility check for websites

Since the EAA, your website is exposed to warning letters

Affected businesses must make their website accessible from 28 June 2025. See in 30 seconds where it breaches WCAG 2.2 — with one concrete step per finding.

See an example report → (www.hannecke-its.de)

Coming soon: automatic monitoring.

Weekly re-scan of several pages, check with JS rendering (more findings), email alert on new barriers, PDF export.

How to read the result

The A–F grade and the 100-point scale are only a rough guide. Points are deducted for critical barriers (contrast, missing labels) and for items to be checked. Each finding names the WCAG success criterion and a concrete step. An expandable block shows the calculation.

Frequently asked questions

Does this replace a full assessment?

No. The automated test finds roughly 20–35% of WCAG issues — above all those recognisable directly in the source code. Keyboard operation, focus order and screen-reader behaviour must be checked manually.

What about JavaScript?

The free scan reads the delivered HTML + linked CSS, without executing JS. Menus, modals and custom modules that only appear in the browser are not fully seen. A check with JS rendering will come with monitoring.

Do I need an accessibility statement?

Under the EAA/BFSG most websites of affected businesses need one — with a feedback mechanism and enforcement procedure. Fill-in help is available here. A legally reviewed template is still recommended.

Are overlay modules (accessiBe, UserWay) a solution?

No. Overlay tools do not create compliance and are criticised by disability advocacy organisations. Accessibility arises in the code, not via a module. More on this.

Accessibility knowledge base

Concrete explanations of the EAA/BFSG, the WCAG success criteria and implementation in WordPress, Shopify, Wix & the like. To the overview →

Recently checked