How do I make my website accessible?

Making a website accessible: what does it mean and who has to do it?

A website is accessible when it is perceivable, operable, understandable and robust – these are the four basic principles of the Web Content Accessibility Guidelines (WCAG). In practice that means: texts can be read, even with weak vision, everything works without a mouse, processes are easy to follow, and the code is clean enough for assistive tools such as screen readers to read it correctly. WCAG 2.2 at level AA has become established as the implementation target.

Whether an obligation exists depends on your offering. The German Accessibility Strengthening Act (BFSG) has applied since June 28, 2025 and mainly affects consumer offerings with contract conclusion such as online stores and booking flows; microenterprises are exempt for services. Purely informational pages and offerings only for business customers are generally not covered, and public bodies follow BITV 2.0. This guide does not replace legal advice – have your obligation reviewed case by case.

Step 1: Check the current state – auto­mati­cally and by hand

Begin with an inventory. Automated tools such as Lighthouse, axe or WAVE quickly find missing labels, insufficient contrast or duplicate identifiers but detect only some of the problems. They cannot see whether an alternative text makes sense or whether operation stays logical. So never rely on a test score alone, but supplement every automated run with simple manual tests.

Check your most important flows, such as home page, contact form, booking or order, with a few simple moves. Operate the page using only the Tab key, zoom it to 200 percent and test a short flow with a screen reader such as NVDA or VoiceOver. Note every error with page, description and urgency. This produces a prioritized list from which the effort and order of implementation can be read.

• Navigate through the page with the keyboard only
• Zoom the view to 200 percent and check that nothing is cut off
• Spot-check with a screen reader on the most important flows
• Measure the contrast of text and controls
• Record errors with page, description and urgency

Step 2: Perceivable – contrast, text and media

Under WCAG, normal text needs a contrast ratio of at least 4.5 to 1 against the background, large text and controls such as input field borders at least 3 to 1. Light gray text on white and text over photos are typical errors. Also never rely on color alone: a red border around a faulty field additionally needs a text or an icon. Text should be enlargeable without loss and should not be embedded in images.

Images with meaning get a short, sensible alternative text, purely decorative images an empty one so screen readers skip them. Videos need subtitles, and for content explained only in the picture a description or transcript is needed. Media should not start automatically with sound and should be pausable. These measures help not only people with impairments but also anyone looking at a display on the go in noise or bright light.

Step 3: Operable – keyboard, focus and target sizes

Everything that can be operated with a mouse must also work by keyboard: menus, forms, dialogs, carousels. The order when tabbing should follow the visual logic, and every active element needs a clearly visible focus. Under WCAG 2.2 the focus must also not be hidden by fixed elements such as headers or cookie banners. A skip link at the top of the page lets users bypass the navigation. Keyboard traps from which you can no longer escape are not acceptable.

WCAG 2.2 also sets requirements for touch operation: clickable areas should be at least 24 by 24 CSS pixels or have enough spacing, and actions that require dragging need a simple alternative by click. Time limits, such as for sessions, should be extendable. These points make operation easier for people with motor impairments and at the same time improve use on smartphones.

• All functions reachable by keyboard, logical order
• Visible focus that is not hidden
• Skip link to the main content
• Clickable areas with sufficient size or sufficient spacing
• Simple alternatives to drag movements

Step 4: Under­stand­able – structure, forms and error messages

A clear structure helps everyone. Use exactly one main heading with a logical hierarchy below it, mark up areas such as header, navigation, main content and footer semantically, give every page a meaningful title and set the page language in the code so screen readers pronounce correctly. Link texts should be understandable on their own; “click here” says nothing in a list of links.

Forms are the most frequent hurdle. Every field needs a visible label linked to the field, required fields must be recognizable, and error messages appear as text next to the affected field and say how the error can be fixed. Use the browser’s autofill function and do not require entering information several times. Logins should work without puzzles or memory tasks. This increases the number of completed inquiries.

Step 5: Robust – clean code, third parties and documents

The most reliable foundation is semantic HTML: real buttons as buttons, links as links, lists as lists. ARIA attributes supplement where native elements are not enough but do not replace them; faulty ARIA often makes operation worse than none at all. For self-built components such as dropdown menus, dialogs or sliders there are proven patterns that take keyboard and screen reader into account. Test these building blocks individually.

Also consider what does not come from you: cookie banners, booking and payment widgets, chat windows and embedded maps. If they are not accessible, your entire flow becomes unusable – then adaptation or replacement is needed. The same applies to PDF documents, which should be provided as structured, accessible files. We advise against using an overlay that promises accessibility at the push of a button: it does not fix the causes in the code.

Step 6: Statement, feedback and lasting upkeep

Document the state of your accessibility. Depending on the obligation, this includes information on the accessibility of your offering, an accessibility statement with the status of implementation and known limitations, and a contact through which users can report problems. Public bodies are expressly obliged to do so; for other providers the information obligations depend on the law and the offering. Have this reviewed legally case by case; this does not replace legal advice.

Accessibility is not a project with an end point, because every new piece of content can open gaps. Set rules for the editorial team: alternative texts, heading structure, meaningful link texts, subtitles. Check the most important flows again for releases and larger changes and train new editors. Anyone who names responsibilities clearly keeps quality up in the long term. We accompany you from review through implementation to training.