Skip to content

Accessibility

Last updated: 18 September 2026

This site should be usable by everyone — with a keyboard, with a screen reader, at high magnification, with colour vision deficiency. We work to the Web Content Accessibility Guidelines 2.2 at level AA. What is in place and what still falls short is set out here without varnish.

Current state

By our own assessment this website largely meets WCAG 2.2 level AA. The limitations listed below are known to us.

What is in place

  • Keyboard operation. The type selector in the generator follows the tab pattern and can be stepped through with the arrow keys. Keyboard focus is visible.
  • Skip link. A link at the top of the page bypasses the navigation – straight to the generator on the home page, to the main content on every other page.
  • Contrast measured, not guessed. Every text colour was calculated against the surface it actually sits on and reaches at least 4.5:1, with large text and interface components at 3:1 or better. The border of the input fields also meets 3:1 — on an empty field it is the only thing marking the control.
  • Permanently visible labels. Every input has its own label that stays put while you type. Placeholders are examples only and carry no information that would otherwise be lost.
  • Nothing conveyed by colour alone. Warnings and errors appear as text, not merely as a coloured area.
  • Status messages are announced. Notices about contrast or excessive content are marked up as status regions and so reach screen readers.
  • Light and dark mode. Dark mode is the default. The switch changes to light mode at any time, and that choice is remembered.
  • Reduced motion honoured. If reduced motion is set in the operating system, transitions and smooth scrolling are switched off.
  • Magnification down to 320 pixels. Content reflows to the width of a narrow phone without horizontal scrolling.
  • Language declared. German and English are marked up as such, and the switch carries the language of its target.
  • Checked automatically. The project's test suite runs axe-core against every page in both languages on every run, using the rule sets for WCAG 2.0 to 2.2 at levels A and AA plus axe's own best-practice rules. It also checks at a width of 320 pixels that nothing overflows horizontally. A new violation fails the build.

Known limitations

  • The QR code itself is an image. A grid of modules cannot meaningfully be described in words. The encoded content is therefore shown below the preview as readable text with a copy button — anyone who cannot see the code can still get at the information.
  • The colour picker belongs to the operating system. How it behaves is up to the browser and outside our control. The defaults are chosen so that no change is needed to get a reliably scannable result.
  • Tools have checked this, people have not. Automated testing is known to catch only part of the barriers. Testing with screen reader users is still outstanding.
  • No formal conformance assessment. There is no audit report to EN 301 549. The statements on this page rest on our own assessment.

Legal position

In our assessment there is no statutory accessibility obligation for this service: the German BITV declaration duty applies to public bodies, and the German Accessibility Strengthening Act exempts micro-enterprises providing services. We implement accessibility regardless — a tool that shuts someone out has missed its purpose.

Something not working?

If you run into a barrier, please tell us. A short description is enough: which page, which assistive technology, what happened. We will reply and put it right.

Report a barrier

How this statement came about

Self-assessment by the provider. It rests on automated testing with axe-core 4.x in Chromium and a calculated check of the colour contrasts against their actual backgrounds. Operating every page with the keyboard alone is still outstanding.