Perceivable
Contrast, alt text, subtitles, scalable type. Everything that someone must be able to see, hear or read.
Accessible websites to WCAG: contrast, keyboard use, alt text and BFSG obligations explained clearly. Not legal advice.
Accessibility on the web means that content and functions are available to as many people as possible: to blind people using a screen reader, to people with low vision, colour blindness or motor impairments, to deaf people, to people with learning difficulties and to anyone who is temporarily limited. The guidelines are called WCAG and follow four principles: perceivable, operable, understandable and robust.
In practice it is mostly a matter of craft. Sufficient contrast between text and background (for normal text, WCAG sets a ratio of at least 4.5 to 1), headings in a logical order, form fields with visible labels, links with meaningful text instead of “click here”, and the ability to operate everything with the keyboard alone. If planned early, these things cause far less extra work than a correction made afterwards: anyone who adds them to a finished page often has to rebuild a great deal.
Legally, the Barrierefreiheitsstärkungsgesetz is the most important reason to act. It implements an EU directive and, since 28 June 2025, requires accessible design for certain digital offerings, such as in e-commerce. Depending on the case, this also includes an accessibility statement and a way to give feedback. We explain the technical side; the legal assessment belongs in the hands of a lawyer.
Barriers affect more people than you might think: someone with low vision, a person with a broken arm who can only use one hand, a visitor in harsh sunlight or in a noisy place with the sound off. Accessible design helps all of them.
Accessibility is above all craft: sufficient contrast, a clean structure and elements that can be operated. Brand colours rarely have to be replaced for this; an adapted variant for text is often enough.
On the obligation: the BFSG has applied since 28 June 2025, in particular to online shops and other offerings through which consumers conclude contracts. Micro-enterprises (fewer than 10 employees, turnover or balance sheet total of no more than €2 million) are exempt from the BFSG for services, but not for products. Whether and how you are affected is decided case by case by a legal review. We build in such a way that the technical requirements can be met, but we do not give legal advice.
Contrast, alt text, subtitles, scalable type. Everything that someone must be able to see, hear or read.
Keyboard use, sufficiently large click areas, enough time to read and fill things in, no flashing elements.
Clear language, easy-to-follow navigation, understandable error messages in forms.
Clean code that different browsers and assistive tools interpret reliably.
A page that documents the current status and gives a way to send feedback. Where it is required, and where it makes sense.
Short summaries or explanatory sentences for difficult content, where they make use easier.
First of all: this section is a guide, not legal advice. If in doubt, a lawyer will assess your business. The law and its interpretation change; check current information from the responsible authorities.
The Barrierefreiheitsstärkungsgesetz (BFSG) implements a European directive and has applied since 28 June 2025. As we understand it, it is aimed primarily at providers of products and services for consumers. On the web, e-commerce is particularly affected, that is, online shops and offerings through which consumers conclude contracts. Offerings aimed purely at businesses (B2B) are not covered. Micro-enterprises (fewer than 10 employees, turnover or balance sheet total of no more than €2 million) are exempt from the BFSG for services, but not for products.
Regardless of any obligation, accessibility improves usability for many people and largely overlaps with good web design. Public bodies are subject to separate requirements. Which obligations apply in your case (for example an accessibility statement, a way to give feedback, labelling) is something the legal review will clarify.
The Web Content Accessibility Guidelines organise their requirements into four principles, known in English as POUR. Each principle has success criteria at three levels (A, AA, AAA); for legal requirements, level AA is usually taken as the basis, in Europe via the EN 301 549 standard (currently based on WCAG 2.1; WCAG 2.2 serves as guidance).
| Principle | Meaning | Example of a barrier | Example of a solution |
|---|---|---|---|
| Perceivable | Information must be available in at least one way a person can take it in | A price list exists only as an image; blind visitors learn nothing | Prices as text, image with alt text |
| Operable | All functions can be used with different input devices | A menu opens only when the mouse touches it | Menu works by keyboard and touch, with a visible focus |
| Understandable | Content and operation are easy to follow | Error message “Invalid entry” with no further hint | Message at the field with an explanation and an example |
| Robust | Content works with different browsers and assistive tools | Custom controls with no labels for screen readers | Use standard elements, set roles and names |
The examples show that accessibility mostly requires not specialist knowledge but care: using standard building blocks, offering content as text, and not tying functions to a single way of operating them.
The contrast between text and background is expressed as the ratio of two brightness values. The higher the value, the easier it is to read. At level AA, WCAG requires at least 4.5 to 1 for normal text, at least 3 to 1 for large text (roughly from 24 pixels, or 18.5 pixels in bold), and likewise 3 to 1 for important controls and graphical cues.
A common case: light grey text on a white background. The grey with the colour value #777777 reaches around 4.48 to 1 on white and so narrowly fails; #767676 comes in at around 4.54 to 1 and narrowly passes. A difference that small decides whether a design meets the requirement. Free contrast calculators, in browser developer tools and online, show the value immediately.
Your brand's colour palette does not have to become dull as a result. A darker variant of the main colour for text and a lighter one for surfaces produce combinations that are easy to read. You can find more on choosing colours under Colour palette.
Many people cannot or do not want to use a mouse: because of motor impairments, when using screen readers, with voice control, or simply out of habit. All functions on a page must therefore also be reachable by keyboard. The most important requirements:
Load your home page, put the mouse aside and press the Tab key several times. Can you see where you are at each step? Can you reach the menu, the main action, the form? Can you submit the form using the keyboard? Do you get stuck anywhere? Every place where this does not work is a finding.
Screen readers do not read a page like a photograph but as a structure: headings, lists, links, form fields. Users often jump from heading to heading, just as sighted people skim a page. Good structure is therefore the foundation.
| Element | Requirement | Typical mistake |
|---|---|---|
| Headings | One H1, with H2 and H3 below it in a logical hierarchy | Headings chosen only for their font size, levels skipped |
| Regions | Header, navigation, main content and footer marked up as such | Everything in identical blocks with no markup |
| Links | Meaningful text that is understandable even without its surroundings | “More”, “Click here”, repeated twenty times |
| Form fields | Every field has a visible, associated label | Only a placeholder in the field, no label |
| Error messages | At the field, in text, with a suggested fix and detectable by assistive tools | A red outline with no text |
| Tables | Header rows marked, simple structure | Layout built with nested tables |
| Language | Page language and changes of language within the text marked up | Missing declaration, so a German page is read out in English |
| Page title | Unique, and different for each page | All pages are called “Home page” |
Most of this is clean code, which also helps search engines. Anyone who marks things up properly gains twice over.
Alt text stands in for an image for everyone who cannot see it, and for search engines. Which text is right depends on the image's job. Work through these questions for every image:
| Image | Weak alt text | Good alt text |
|---|---|---|
| Photo: a floor fitter in a living room, oak parquet freshly laid | Bild1.jpg | Freshly laid oak parquet in a living room, with light from the window raking across it |
| Icon: magnifying glass in the header | Magnifying glass | Open search |
| Diagram: process in four steps | Process | Process in four steps: initial consultation, concept, implementation, launch. Details in the text below. |
| Decorative wave pattern | Waves | (empty, will be skipped) |
A rule of thumb: one or two sentences, without “image of” at the start. You can find more in the guide Alt text for images.
Audio and video need alternatives. Deaf people need subtitles, blind people need a description of the important visual content, and everyone benefits from a searchable transcript. Motion can impair or distract people, so there are clear rules:
The simplest approach is to use animations sparingly and only where they explain something. That also adds to the page's speed.
| Myth | Fact |
|---|---|
| Accessibility only affects a few people | It includes permanent, temporary and situational limitations: low vision, an injured arm, sunlight on the display, age. Almost everyone experiences them at some point |
| An overlay tool makes the site accessible | Such add-ons do not fix the underlying causes and can interfere with assistive tools. Accessibility has to be built into the structure and design |
| Accessible pages look bad | Accessibility does not restrict design; it calls for clear contrast, structure and usability |
| Checking once is enough | Every new piece of content can create a barrier: an image without text, a video without subtitles. Accessibility is an ongoing process |
| Automated tests find every error | They find some of them, such as missing alt texts or contrast problems. Whether labels are understandable and processes make sense can only be checked by a person |
| It is purely a legal matter | Legal obligations are one reason to act. The benefit lies in reaching more people and finding usability problems |
Note down every finding with the page, a description and its urgency. Fix first whatever blocks the main action (form, contact, order). These steps also show you how closely design and user guidance are intertwined.
Forms are where barriers most often lead to lost business: if someone cannot use the form, they cannot enquire or buy. The good news is that with standard building blocks and a few rules, this is easy to get right.
Labels. Every field has a visible label that is technically linked to the field. A screen reader then reads out the field's purpose when you enter it, and a click on the label puts the cursor in the field. Placeholder text inside the field is no substitute for a label, because it disappears as you type and often has too little contrast.
Required fields. Mark them in text (for example “required” or an explained asterisk) and not just by colour. Limit required fields to what is necessary.
Field types and aids. Suitable types (email, telephone, date) bring up the right keyboard on a phone. The autocomplete attribute helps people who find typing difficult, because name and address are filled in for them.
Groups. Fields that belong together, such as several choices, are marked up as a group with a heading, so that it is clear what the choice refers to.
Error messages. They appear at the field and also as a summary above, name the problem and suggest a solution (“Please enter the email address with an @”). Focus moves to the message so that screen readers announce it.
Time. Sessions do not expire at short notice. If time limits are necessary, warn people in good time and allow them to extend.
Spam protection. Visual puzzles with distorted letters lock many people out. Use invisible methods or simple knowledge questions with an alternative.
Check every form with the keyboard, at 200 per cent zoom and with a screen reader. As a rule, what works there works better for everyone. You can find further practical rules for forms in the guide Designing a contact form properly.
Accessibility is not created in a single step at the end, but spread across the whole project. The table shows which role has which task in which phase.
| Phase | Task | Typical mistakes if forgotten |
|---|---|---|
| Concept and structure | Logical page structure, clear naming, simple paths, a decision on media and functions | Complex interaction patterns that cannot be made accessible later |
| Design | Colour palette with checked contrasts, font sizes, states for focus and errors, sufficient spacing | Elegant but low-contrast colours, missing focus state |
| Copy and content | Clear language, meaningful headings, alt text, link text, accessible documents | Images without descriptions, “click here”, PDFs without structure |
| Development | Semantic code, keyboard operation, labels, testing with assistive tools | Controls built from unsuitable elements, missing names and roles |
| Testing and acceptance | Automated and manual tests, spot checks with users or specialists | Testing with a tool only, without real use |
| Operation and maintenance | Editorial rules, spot checks after changes, updating the statement | New content breaks old standards |
It is important to end each phase with a check question: can what is being produced now be understood without a mouse, without colour and without images? That way a barrier is spotted while it still costs little to fix.
Many businesses offer price lists, brochures, data sheets or forms as PDFs. These files are part of what you offer and are included in the review where accessibility is required. The requirements are similar to those for pages: heading structure, alt text, a readable order, tables with header rows, a language declaration, sufficient contrast.
The practical advice is this: make important information accessible primarily as a web page and offer the PDF as an additional download. That avoids maintaining accessibility twice and also helps visitors on their phones. If a PDF is still needed, produce it from a well-structured source (for example a text document with real paragraph styles) and check the result with a testing tool as well as manually. Scanned documents that consist only of images are invisible to assistive tools without text recognition and should be replaced.
A bicycle retailer (entirely made up) runs an online shop for accessories. He is a provider to consumers in online retail and is therefore checking with his legal adviser whether and how the BFSG applies to him. Whatever the outcome, the checkout is the most critical part. The points to check, along the way:
| Step | Question to check | Possible barrier |
|---|---|---|
| Home page and search | Can the search be reached by keyboard, and are results announced? | Search field without a label, results load without any feedback |
| Categories and filters | Can filters be operated by keyboard, and are their states recognisable? | Filters usable only with a mouse, selection visible only through colour |
| Product page | Do images have alt text, is the price available as text, and is “Add to basket” recognisable as a button? | Price inside an image, button built as a div |
| Basket | Are quantity fields labelled, and is a change confirmed? | Plus/minus icons without names |
| Address and payment | Are errors explained at the field, and is the choice of payment method accessible? | Error messages shown only in colour, payment provider window not usable by keyboard |
| Confirmation | Do buyers learn that the order went through, and what happens next? | Message disappears after a few seconds, focus is left somewhere random |
| Order confirmation by email | Is the email clearly structured and easy to read? | Images only, no text version |
The retailer documents the results, fixes first whatever prevents purchases, and plans the rest. This order applies to any site: main function first. For more on shops, see the page Online shops.
We check your site for common barriers: contrast, keyboard use, missing labels, structure.
Colours and font sizes that stay readable even with low vision and in bright surroundings.
All functions can be reached without a mouse, with a visible marker showing where you are.
Headings, lists and labels that screen readers interpret correctly.
Image descriptions, subtitles for videos, understandable link text.
We record what has been checked and where gaps remain, as a basis for the accessibility statement.
For new sites, accessibility is part of the quality of the work and, if planned early, causes far less extra effort than a correction made afterwards. It is different for existing sites: here the effort grows with the number of defects, the complexity of the functions (shop, configurators, bookings) and how thoroughly things must be checked and documented.
The calculation behind this: how we price our work.
That depends on who you are and what you offer. The BFSG mainly affects offerings to consumers, such as online shops. Micro-enterprises (fewer than 10 employees, turnover or balance sheet total of no more than €2 million) are exempt from the BFSG for services, but not for products. If in doubt, have this clarified legally.
The Web Content Accessibility Guidelines are the internationally accepted technical benchmark, with levels A, AA and AAA. In Europe, the legally relevant standard is EN 301 549, which currently refers to WCAG 2.1 level AA; WCAG 2.2 serves as guidance.
Tools find some of the problems, such as missing alt text or insufficient contrast. Much else, for example whether labels are understandable, can only be checked by a person.
No. Such add-ons tend to cover up problems rather than fix them, and they are controversial among specialists. The foundation is a site that is built cleanly in the first place.
PDFs should be accessible too: with a heading structure, alt text and a readable order. If a piece of information is important, it is best also given as text on the page.
Indirectly, yes: clear structure, alt text and good usability largely overlap with what search engines also understand. Details in the guide Accessibility and the BFSG.
Record which standard was used for the check (for example WCAG 2.1 or 2.2, level AA), when, by whom and with what result. Open points belong in a list with a date for fixing them.
Where the law requires it, yes. Even voluntarily it makes sense, because it shows openness. Have the text reviewed before it goes online.
This is governed by the law and the market surveillance authorities responsible in each case. Which consequences are conceivable in your case can only be answered by a legal review.
Send us the address of your site and your most important question about accessibility. You will receive a personal assessment.