Planning an accessible website: a practical WCAG 2.2 and BFSG checklist

Accessibility cannot be added to a completed website with an overlay and a handful of image descriptions. It affects information architecture, design, content, frontend code, forms, documents and ongoing publishing. When testing begins shortly before launch, teams discover failures in components that are already expensive to change together.

In Germany, the provisions of the Barrierefreiheitsstärkungsgesetz, or BFSG, have generally applied since 28 June 2025. The products, services, exceptions and transitional rules relevant to a specific organisation require legal assessment. This article is not legal advice. It explains how to organise a web project around an explicit, testable accessibility target.

Do not treat the BFSG and WCAG as the same thing

The BFSG sets legal requirements for specified products and services. The Web Content Accessibility Guidelines (WCAG) 2.2, published by the World Wide Web Consortium (W3C), provide technical and content-oriented success criteria for accessible web content. WCAG 2.2 organises its guidance under four principles: perceivable, operable, understandable and robust.

A project therefore needs two separate decisions:

1. Which legal duties apply to this service and organisation?
2. Which technical conformance target and test scope will the project use?

“The website will be accessible” is not a dependable requirement unless it identifies the target, page types, success criteria and verification method.

1. Define the scope before design starts

Create an inventory of every digital component a user may need:

• public pages and language versions;
• navigation, search and filters;
• forms, calculators and appointment booking;
• registration, sign-in and account functions;
• basket, checkout and payment;
• video, audio and animation;
• PDF files and other downloads;
• consent controls, chat and third-party widgets;
• emails or documents required to complete a process.

Third-party components should not disappear from the scope automatically. If a payment window, booking tool or consent dialog blocks an essential action, the overall journey is not accessible simply because the content pages are.

2. Build testable rules into the design system

Accessibility starts with components rather than individual screens. Colour, focus, errors and spacing should be defined as reusable behaviours.

The design needs to answer:

• Is colour contrast sufficient for text and essential controls?
• Does information remain clear without relying on colour?
• Is a visible keyboard focus state specified for every interactive element?
• Are targets large enough and separated for reliable operation?
• Does the layout work when zoomed and at narrow widths?
• Can motion and automatically changing content be paused?
• Are hover interactions also available to keyboard and touch users?

A static screenshot cannot prove many of these conditions. Focus, validation errors, open menus and disabled controls belong in the design handover.

3. Structure content for different ways of perceiving it

Editorial accessibility extends well beyond alt text. Headings need to represent the information structure, links should explain their destination and instructions should avoid unnecessary ambiguity.

Review:

• a logical heading hierarchy rather than visually simulated headings;
• descriptive links instead of repeated “Learn more” labels;
• alternative text that represents the purpose of a meaningful image in context;
• empty alternative text for purely decorative images;
• captions and other required alternatives for media;
• tables used for genuine data relationships rather than layout;
• clear instructions, validation messages and required-field cues;
• descriptive document titles and accessible download formats.

Alternative text should not repeat the page’s keywords. Its purpose is to replace the information the image contributes in that specific context.

4. Prefer semantic HTML before adding ARIA

Native HTML elements include useful roles and keyboard behaviour. A real button is generally more robust than a styled div supported by scripts that attempt to reproduce button behaviour. ARIA attributes can add semantics, but they do not automatically correct an unsuitable interaction.

Frontend review should cover:

• appropriate landmarks for header, navigation, main content and footer;
• labels and relationships for form controls;
• complete keyboard operation in a logical order;
• focus management for dialogs, menus and dynamic notifications;
• status and error messages exposed to assistive technology;
• no keyboard traps;
• the correct language for the document and any language changes;
• stable content under zoom, orientation change and responsive layouts.

5. Test forms as complete journeys

A form is accessible only when its fields, validation, error correction and confirmation work together. Placeholder text is not a durable label. Errors should identify the affected field and explain how to correct the value.

Test cases should include:

1. completing the workflow with a keyboard only;
2. submitting empty or invalid fields;
3. correcting errors without losing valid input;
4. receiving a clear success confirmation;
5. handling a server failure or timeout;
6. checking critical stages with a screen reader.

6. Combine automated and manual testing

Automated tools can identify certain patterns efficiently, including missing labels, some contrast failures and invalid relationships. They cannot reliably decide whether alternative text is useful, focus order supports the task or an error message makes sense.

A credible test plan combines:

• automated checks across representative templates;
• keyboard testing for every critical journey;
• review with zoom and different viewport sizes;
• screen-reader sampling;
• manual inspection of structure, text alternatives and errors;
• testing with disabled users when the reach and risk justify it.

Do not test the homepage alone. Select at least one representative example of every important template and add known exceptions or complex states.

7. Define acceptance and ongoing ownership

New content, plugins and design changes can introduce barriers after launch. Handover therefore needs more than a one-time report.

Acceptance should include:

• the documented target and test scope;
• the tools, devices and manual methods used;
• findings with severity, URL and a reproducible test case;
• owners and dates for unresolved items;
• component rules in the design system;
• editorial guidance for headings, links, images and documents;
• regression checks for future releases.

Release gate

Before launch, the team should be able to answer five questions with evidence:

1. Have the legal scope and technical target been decided?
2. Can users complete critical journeys with a keyboard?
3. Are structure, labels, focus and error messages understandable?
4. Have automated findings been evaluated manually?
5. Are owners and recurring checks in place after release?

Accessibility is not a certificate that covers every future change. It is a quality requirement for both the product and the delivery process. Defining the target, components and tests early reduces the risk of having to reverse fundamental decisions immediately before launch.

Primary references: the German Federal Ministry of Labour and Social Affairs on the BFSG, and the W3C Web Content Accessibility Guidelines (WCAG) 2.2.