Web design

Accessible websites: usable by everyone, not just an obligation

Accessible websites to WCAG: contrast, keyboard use, alt text and BFSG obligations explained clearly. Not legal advice.

Web design

Accessibility: what exactly is it?

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.

Background

Accessibility: why it matters.

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.

Overview

Accessibility: building blocks and variants.

Perceivable

Contrast, alt text, subtitles, scalable type. Everything that someone must be able to see, hear or read.

Operable

Keyboard use, sufficiently large click areas, enough time to read and fill things in, no flashing elements.

Understandable

Clear language, easy-to-follow navigation, understandable error messages in forms.

Robust

Clean code that different browsers and assistive tools interpret reliably.

Accessibility statement

A page that documents the current status and gives a way to send feedback. Where it is required, and where it makes sense.

Plain language as a complement

Short summaries or explanatory sentences for difficult content, where they make use easier.

Does the BFSG affect my business? A guide to getting your bearings

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.

A decision aid for a first picture

  1. Do you sell online to consumers, or conclude contracts with them online? If not, it is less likely that you are affected; if so, go on to question 2.
  2. Do you offer services and are you a micro-enterprise in the sense described above? Then the exemption may apply. Have this confirmed. If you sell products, the exemption does not apply.
  3. Is your offering a banking service, telecommunications, passenger transport, an e-book or a similarly regulated area? Then separate rules apply.
  4. Do you run your site on behalf of third parties (for example, retailers on your platform)? Check roles and responsibility separately.

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 four WCAG principles with everyday examples

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).

PrincipleMeaningExample of a barrierExample of a solution
PerceivableInformation must be available in at least one way a person can take it inA price list exists only as an image; blind visitors learn nothingPrices as text, image with alt text
OperableAll functions can be used with different input devicesA menu opens only when the mouse touches itMenu works by keyboard and touch, with a visible focus
UnderstandableContent and operation are easy to followError message “Invalid entry” with no further hintMessage at the field with an explanation and an example
RobustContent works with different browsers and assistive toolsCustom controls with no labels for screen readersUse 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.

Contrast: calculate, do not guess

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.

Practical rules for colour

  • Check every combination of text and background, including text on images and gradients.
  • Never rely on colour alone: marking a required field only in red is invisible to people with colour blindness. Add a symbol or some text.
  • Buttons and input fields need a visible border or a surface contrast of at least 3 to 1 against their surroundings.
  • Links within running text should not be distinguished by colour alone; an underline is the safest option.
  • Also test your page with a colour-blindness simulator and at high screen brightness outdoors.

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.

Keyboard and focus: moving through the page without a mouse

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:

  1. Logical order. With the Tab key, focus moves from element to element in an order that follows the visual layout.
  2. Visible focus. The element currently selected must be clearly recognisable. Anyone who removes the default marker with a style rule must provide an equivalent or better one.
  3. No focus trap. You must not get stuck in one area, such as a pop-up that cannot be closed by keyboard (Esc or a button).
  4. Skip links. A “Skip to content” link at the top of the page saves keyboard users from tabbing through the whole menu.
  5. Real controls. Buttons are buttons, links are links. Anyone who builds a div with a click event has to add keyboard support and roles by hand.
  6. Expandable menus. They must open with Enter or Space and close with Esc.
  7. Avoid time limits. Sessions that expire without warning are a barrier for people who operate things more slowly.

A two-minute test

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.

Structure and labelling: what screen readers need

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.

ElementRequirementTypical mistake
HeadingsOne H1, with H2 and H3 below it in a logical hierarchyHeadings chosen only for their font size, levels skipped
RegionsHeader, navigation, main content and footer marked up as suchEverything in identical blocks with no markup
LinksMeaningful text that is understandable even without its surroundings“More”, “Click here”, repeated twenty times
Form fieldsEvery field has a visible, associated labelOnly a placeholder in the field, no label
Error messagesAt the field, in text, with a suggested fix and detectable by assistive toolsA red outline with no text
TablesHeader rows marked, simple structureLayout built with nested tables
LanguagePage language and changes of language within the text marked upMissing declaration, so a German page is read out in English
Page titleUnique, and different for each pageAll 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: a decision tree for every image

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:

  1. Is the image purely decorative (a rule, a background)? Then use an empty alt attribute so that screen readers skip it.
  2. Is the image a button or a link? Then the text describes the function (“To the home page”, “Open search”), not the appearance.
  3. Does the image carry information (a photo of a product, a chart)? Then describe briefly what can be seen and why it is relevant.
  4. Is the image complex (a chart, a map, an infographic)? Then give a short alt text plus a detailed description as text nearby or as a table.
  5. Does the image contain text? Then the same text goes in the alt attribute, though it is better still as real text on the page.
ImageWeak alt textGood alt text
Photo: a floor fitter in a living room, oak parquet freshly laidBild1.jpgFreshly laid oak parquet in a living room, with light from the window raking across it
Icon: magnifying glass in the headerMagnifying glassOpen search
Diagram: process in four stepsProcessProcess in four steps: initial consultation, concept, implementation, launch. Details in the text below.
Decorative wave patternWaves(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.

Media and motion: videos, animations, timing

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:

  • Subtitles for recorded videos with sound, and for live video as far as possible.
  • A transcript or text version for audio-only content.
  • No autoplay with sound. If something starts automatically and runs for more than five seconds, it needs a way to pause it.
  • No flashing elements. Flashing more than three times per second can trigger seizures in sensitive people.
  • Respect for system settings. Anyone who has set “reduce motion” on their device should not see large animations.
  • Allow time. Carousels and notices that change by themselves must be pausable, and important notices should not disappear after a few seconds.

The simplest approach is to use animations sparingly and only where they explain something. That also adds to the page's speed.

Myth versus fact: accessibility

MythFact
Accessibility only affects a few peopleIt 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 accessibleSuch 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 badAccessibility does not restrict design; it calls for clear contrast, structure and usability
Checking once is enoughEvery 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 errorThey 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 matterLegal obligations are one reason to act. The benefit lies in reaching more people and finding usability problems

A self-test in 30 minutes

  1. Zoom test: Enlarge the page in your browser to 200 per cent. Does everything stay readable and usable, without content being cut off or you having to scroll sideways?
  2. Keyboard test: Operate the menu, a form and a button using only Tab, Enter, Space and Esc.
  3. Contrast test: Use a contrast calculator to check running text, links, buttons and form fields.
  4. Structure test: Use a browser extension to display the heading structure. Is there an H1? Do the levels follow a logic?
  5. Alt text test: Turn off images or have the text displayed. Can you still understand the page?
  6. Form test: Submit a form with deliberate mistakes. Does an understandable message appear at the right field?
  7. Quick screen reader test: Switch on your operating system's screen reader for a few minutes and listen to your home page. Do you understand what it says?

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.

Building accessible forms: step by step

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 in the project workflow: who does what, and when

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.

PhaseTaskTypical mistakes if forgotten
Concept and structureLogical page structure, clear naming, simple paths, a decision on media and functionsComplex interaction patterns that cannot be made accessible later
DesignColour palette with checked contrasts, font sizes, states for focus and errors, sufficient spacingElegant but low-contrast colours, missing focus state
Copy and contentClear language, meaningful headings, alt text, link text, accessible documentsImages without descriptions, “click here”, PDFs without structure
DevelopmentSemantic code, keyboard operation, labels, testing with assistive toolsControls built from unsuitable elements, missing names and roles
Testing and acceptanceAutomated and manual tests, spot checks with users or specialistsTesting with a tool only, without real use
Operation and maintenanceEditorial rules, spot checks after changes, updating the statementNew 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.

Making documents and downloads accessible

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.

Scenario: a bicycle retailer's checkout (fictional example)

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:

StepQuestion to checkPossible barrier
Home page and searchCan the search be reached by keyboard, and are results announced?Search field without a label, results load without any feedback
Categories and filtersCan filters be operated by keyboard, and are their states recognisable?Filters usable only with a mouse, selection visible only through colour
Product pageDo 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
BasketAre quantity fields labelled, and is a change confirmed?Plus/minus icons without names
Address and paymentAre 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
ConfirmationDo 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 emailIs 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.

Terms related to accessibility

BFSG
Barrierefreiheitsstärkungsgesetz (the German Accessibility Act), which has applied since 28 June 2025 to certain products and services for consumers.
WCAG
Web Content Accessibility Guidelines, the international benchmark for accessible web content.
EN 301 549
A European standard that describes requirements for digital accessibility, is legally relevant and currently refers to WCAG 2.1 level AA.
Screen reader
Software for people with visual impairments that outputs screen content as speech or in Braille.
ARIA
Additional markup in the page code that tells assistive tools about roles and states. Only worthwhile when standard elements are not enough.
Focus
The element currently selected when operating a page by keyboard.
Alt text
A text description of an image for assistive tools and search engines.
Accessibility statement
A page that describes the state of accessibility, names known shortcomings and offers a way to get in touch.
Our work

Accessibility: what we do for you.

Audit of your existing site

We check your site for common barriers: contrast, keyboard use, missing labels, structure.

Design with sufficient contrast

Colours and font sizes that stay readable even with low vision and in bright surroundings.

Keyboard operation

All functions can be reached without a mouse, with a visible marker showing where you are.

Semantic structure

Headings, lists and labels that screen readers interpret correctly.

Alt text and media

Image descriptions, subtitles for videos, understandable link text.

Documentation

We record what has been checked and where gaps remain, as a basis for the accessibility statement.

Quality

Accessibility: how to recognise good work.

  • Text has sufficient contrast against the background
  • All functions can be used without a mouse, and the current position is visible
  • Images that carry content have alt text; decoration is skipped
  • Headings follow a logical order
  • Form fields have visible labels and understandable error messages
  • Link text makes sense on its own
  • Videos have subtitles or a text version
  • Information does not depend on colour alone
  • Where required, there is an accessibility statement
Costs

Accessibility: what it costs.

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.

What determines the price

  • Condition of the existing site
  • Number of page types and functions
  • Depth of the review (automated, manual, with assistive tools)
  • Rebuilding of templates and third-party components
  • Documentation and ongoing checks

What you can prepare

  • An assessment of whether your offering falls under the BFSG (if necessary after consulting your legal adviser)
  • Access to the existing site and to shop functions
  • A list of the functions and forms that visitors use
  • Your videos and PDF documents that are on the site
Pitfalls

Accessibility: common mistakes.

  • Light grey text on a white background that looks “modern” and is barely legible
  • Buttons with no label, only an icon
  • Menus that open only with a mouse
  • Error messages shown only in red, with no text
  • Images of text that screen readers cannot capture
  • Accessibility treated as a one-off task rather than ongoing care
Frequently asked questions

Questions about accessibility.

Does my website have to be accessible?

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.

What is WCAG?

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.

Are there automated checks?

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.

Is an accessibility plug-in or overlay enough?

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.

What applies to PDF files on my site?

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.

Does accessibility also help with Google?

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.

How do I document the state of my site?

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.

Do I have to publish an accessibility statement?

Where the law requires it, yes. Even voluntarily it makes sense, because it shows openness. Have the text reviewed before it goes online.

What happens in the event of violations?

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.

Guides

More to read.

What does a website cost? The price factors at a glanceWhat a business website costs depends on scope, features, content and ongoing support. These are the factors that determine the price.Read more →Website relaunch without losing rankings: how to proceedHow to relaunch a website without losing visibility on Google: audit, content plan, redirects and checks after launch.Read more →Responsive Web Design: What It Is and Why It Is the StandardResponsive web design explained: how websites adapt to smartphone, tablet and desktop, why it matters to users and Google, and how to tell if yours does it well.Read more →Accessible websites: the basics and the BFSGAccessible websites explained: why accessibility matters, what the BFSG regulates, which requirements apply (WCAG) and how to get started.Read more →Cookie banners and privacy: the essentialsCookie banners and consent: when a banner is needed, which services you can avoid, and how to build a privacy-friendly website.Read more →WordPress or custom-built? Choosing the right systemWordPress, other site builders or content management systems, or a custom solution: pros, cons and criteria for choosing for a business website.Read more →Optimising website images: format, size, loading timeOptimising images for websites: the right formats (WebP, AVIF, JPEG), suitable sizes, compression and lazy loading for fast loading times.Read more →Writing website copy from the customer’s perspectiveWebsite copy that sells: the customer’s perspective instead of self-description, clear benefits, direct address and a structure from headline to call to action.Read more →Designing a Contact Form: More Enquiries, Fewer FieldsDesigning a contact form: which fields you need, how to lower barriers, keep spam out and comply with data protection. Practical tips for more enquiries.Read more →Website maintenance and security: what to do regularlyWebsite maintenance and security: updates, backups, passwords, HTTPS and monitoring. The key tasks that keep your website secure and fast.Read more →

Want to clarify accessibility for your business?

Send us the address of your site and your most important question about accessibility. You will receive a personal assessment.

Book an initial consultation