Guide · BFSG 2025

BFSG 2025 technical readiness checklist for SaaS

The Barrierefreiheitsstärkungsgesetz (BFSG) has been in force since 28 June 2025. Most guidance is legal. This one is technical: what to fix in the source, in what order, and how to prove it, written for engineering teams shipping SaaS and B2B platforms into the EU.

Does BFSG apply to your SaaS?

BFSG transposes the European Accessibility Act into German law. For SaaS, the practical trigger is: you sell a digital service to consumers in Germany, or your product is embedded in one that does. Pure B2B tools are formally out of scope, but procurement increasingly treats WCAG 2.1 AA as a hard requirement, and the checklist below is the same either way.

  • Consumer-facing web app, checkout, or booking flow → in scope.
  • Marketing site that converts to a paid consumer plan → in scope.
  • B2B admin console sold as part of a consumer offering → in scope.
  • Micro-enterprise service (< 10 staff, < €2M turnover) → narrow exemption; still expect procurement questions.

Source-level remediation, not overlays

Script-widget overlays inject fixes at runtime. They do not satisfy WCAG at the source, they collide with your own JavaScript, and German courts have already ruled against operators relying on them. The checklist below is scoped to fixes that live in your codebase: the same place your tests, reviews, and audits look.

The checklist

1.Semantic HTML and landmarks

WCAG 1.3.1, 2.4.1, 4.1.2

  • One <h1> per page; heading levels never skip.
  • Every page has <header>, <main>, <nav>, <footer> landmarks.
  • Interactive elements are <button> or <a>, never <div onClick>.
  • Forms use <label for> or aria-labelledby: no placeholder-only labels.

2.Keyboard operability

WCAG 2.1.1, 2.1.2, 2.4.3, 2.4.7

  • Every interactive element reachable and operable with Tab / Shift+Tab / Enter / Space.
  • Visible focus ring on every focusable element, contrast ≥ 3:1 against the background.
  • No keyboard traps. Escape closes modals, focus returns to the trigger.
  • Custom widgets (combobox, tabs, tree) follow the ARIA Authoring Practices keyboard model.

3.Color, contrast and motion

WCAG 1.4.3, 1.4.11, 2.3.3, 1.4.13

  • Body text contrast ≥ 4.5:1; large text and UI components ≥ 3:1.
  • Never rely on color alone: pair it with an icon, label, or pattern.
  • Respect prefers-reduced-motion for autoplay, parallax, and route transitions.
  • Hover / focus content is dismissible, hoverable, and persistent.

4.Forms, errors and status

WCAG 3.3.1, 3.3.3, 4.1.3

  • Errors are announced via aria-live=polite or role=alert, not toast-only.
  • Inputs declare autocomplete tokens (email, name, tel, postal-code…).
  • Submit disables gracefully: never remove the button from the tab order.
  • Server-validated errors return to the field, not to the top of the page only.

5.Media and non-text content

WCAG 1.1.1, 1.2.2, 1.2.5

  • Every <img> has an alt attribute: empty alt="" for decorative only.
  • Icons that convey meaning have an accessible name (aria-label or visually-hidden text).
  • Videos have captions; pre-recorded content has an audio description or transcript.
  • PDF attachments used in the flow are tagged and reflow on zoom.

6.Responsive, zoom and reflow

WCAG 1.4.4, 1.4.10, 1.4.12

  • Content reflows at 320 CSS pixels with no horizontal scroll.
  • Text zooms to 200% without loss of content or function.
  • Line-height, letter-spacing, and word-spacing overrides don't clip text.
  • Sticky headers don't cover focused inputs on mobile.

7.Authentication and session

WCAG 3.3.8, 3.3.9

  • Login accepts paste; no cognitive puzzles as the only path.
  • OTP fields expose autocomplete="one-time-code".
  • Session timeout warns the user with time to extend; recovery preserves data.
  • MFA fallback available for users who can't complete a given factor.

8.Evidence for procurement

EN 301 549 · BITV 2.0 · VPAT

  • Publish an accessibility statement at /accessibility with a contact channel.
  • Keep a dated conformance report (VPAT / BITV); regenerate on release.
  • Track findings with a status per WCAG SC: automated, human-certified, or manual-only.
  • Never claim 100% or fully compliant: claim what evidence supports.

Honest coverage: what a scanner can and can't do

Automated tools reliably catch ~30 to 40% of WCAG defects: missing alt text, contrast ratios, form label bindings, ARIA misuse. The rest (meaningful sequence, error identification, name / role / value on custom widgets) needs a human. Treat scanner passes as a floor, not a certificate. Our own reports mark each criterion as automated, human-certified, or manual-only, never inferred.

Where to start this week

  1. Run a source-level scan against one real surface: checkout, sign-up, or the highest-traffic dashboard.
  2. Fix the top 10 findings in the source. Ship a PR; keep the diff.
  3. Have one human certify the fixes against the WCAG SC they claim to satisfy.
  4. Publish an accessibility statement citing the dated report.
Run a free scanStart a paid pilot