You need a checklist, not another explanation of what the BFSG is. This guide gives you exactly that: every accessibility requirement from the Barrierefreiheitsstärkungsgesetz mapped to concrete, testable checks you can run on your online shop today. Each item links to the relevant WCAG 2.1 AA criterion and EN 301 549 clause. Print it, share it with your development team, and start checking boxes.
Images and Media
Every non-decorative image must have meaningful alt text that describes the image's purpose, not just its appearance. Product images need alt text that includes the product name and key visual details. Decorative images must have empty alt attributes (alt="") so screen readers skip them. Icons used as buttons or links need accessible names via aria-label.
Check: Right-click any image, inspect the element, and look for the alt attribute. If it says "IMG_2847.jpg" or is missing entirely, that is a BFSG violation (WCAG 1.1.1, EN 301 549 Clause 9.1.1.1).
Video content requires captions for deaf and hard-of-hearing users (WCAG 1.2.2). Pre-recorded video also needs audio descriptions if visual information is not conveyed through the audio track (WCAG 1.2.5). Live video needs real-time captions (WCAG 1.2.4).
Check: Play every video on your site. Are captions available? Are they accurate and synchronized? Do they include speaker identification and relevant sound effects?
Color and Contrast
Text must have a contrast ratio of at least 4.5:1 against its background (WCAG 1.4.3). Large text (18pt or 14pt bold) needs at least 3:1. Non-text elements like form borders, icons, and focus indicators need at least 3:1 contrast (WCAG 1.4.11).
Color must never be the only way to convey information (WCAG 1.4.1). A form field highlighted in red for errors also needs an icon, text label, or pattern change. Sale prices shown in red need more than color to distinguish them from regular prices.
Check: Use the color contrast checker tool. Test your body text, headings, buttons, form borders, placeholder text, and link colors. Placeholder text is a frequent failure — light gray on white almost never meets 4.5:1.
Navigation and Keyboard Access
Every interactive element must be reachable and operable using a keyboard alone (WCAG 2.1.1). This includes links, buttons, form fields, dropdown menus, tabs, accordions, modals, carousels, and custom widgets. There must be no keyboard traps — users must always be able to move focus away from any component (WCAG 2.1.2).
Focus order must follow a logical sequence that matches the visual layout (WCAG 2.4.3). A visible focus indicator must be present on every focusable element (WCAG 2.4.7). The default browser outline is acceptable, but many CSS resets remove it — check whether your stylesheets include outline: none without providing an alternative.
A skip navigation link must appear as the first focusable element on the page, allowing keyboard users to bypass the header and navigation and jump directly to the main content (WCAG 2.4.1).
Check: Tab through your entire homepage, a category page, a product page, and the checkout flow. Document every point where focus disappears, gets trapped, or follows an illogical order.
Forms and Input Fields
Every form input must have a visible, programmatically associated label (WCAG 1.3.1, 4.1.2). Using placeholder text as the only label is not compliant — placeholders disappear when the user starts typing, removing the label. Associating labels requires either a label element with a matching for attribute or aria-labelledby pointing to a visible text element.
Error identification must be specific and descriptive (WCAG 3.3.1). "Error in form" is not enough. "Please enter a valid email address" is. Errors must be announced to screen readers — either through aria-live regions, aria-invalid on the field, or by moving focus to the error summary.
Input purpose must be identifiable for fields that collect personal information: name, email, phone, address, credit card (WCAG 1.3.5). This enables browser autofill and assistive technology to help users. Add the autocomplete attribute with the correct token (autocomplete="email", autocomplete="cc-number").
Check: Submit every form on your site with empty or incorrect data. Does each error message name the specific field and explain what is wrong? Does the screen reader announce errors?
Page Structure and Semantics
Every page must have exactly one H1 heading. Headings must follow a strict hierarchy: H1, then H2, then H3 — no skipping levels (WCAG 1.3.1). Headings must describe the content that follows them, not be used for visual styling.
The page language must be declared in the HTML element (lang="de" for German pages) (WCAG 3.1.1). If sections of the page are in a different language, those sections need their own lang attribute (WCAG 3.1.2).
Landmark regions (header, nav, main, footer) must be present and properly labeled when there are multiple instances of the same type (WCAG 1.3.1). Use HTML5 semantic elements rather than generic div elements with ARIA roles where possible.
Lists must be marked up as lists (ul, ol, dl), not as sequences of paragraphs or line breaks (WCAG 1.3.1). Tables must use th elements for headers and scope attributes for complex tables (WCAG 1.3.1).
Check: Install the HeadingsMap browser extension. View the heading outline for every key page. Is there exactly one H1? Do headings descend logically without skipping levels?
Checkout and Payment
The checkout flow is where BFSG compliance matters most for online shops — and where violations cause the most measurable harm. If a user with a disability cannot complete a purchase, you are excluding them from your service. That is precisely what the BFSG prohibits.
Every step of checkout must be keyboard-accessible. Address forms must support autocomplete. Payment method selection must be operable with keyboard and announced by screen readers. Order summary must be readable in a logical order. The final submit button must have a clear, descriptive label ("Place order" not "Submit").
Error recovery must be possible. If a payment fails, the user must be able to correct the issue without re-entering all information (WCAG 3.3.4). For legal commitments like purchases, users must be able to review, confirm, and reverse their submission (WCAG 3.3.4).
Third-party payment widgets (Stripe Elements, PayPal buttons, Klarna) are part of your checkout — and their accessibility is your responsibility under the BFSG. Test them. If they trap keyboard focus or lack screen reader support, contact the provider or implement an accessible alternative.
Check: Complete an entire purchase using only your keyboard. Then do it again with a screen reader. If you cannot complete either, neither can your disabled customers.
Accessibility Statement
The BFSG requires every covered service to publish an Erklärung zur Barrierefreiheit (accessibility statement). This is not optional — missing it is a standalone violation even if your site is technically perfect.
The statement must include: the conformance standard you are claiming (EN 301 549 / WCAG 2.1 AA), the date of the most recent accessibility assessment, a description of any known accessibility limitations, contact information for accessibility feedback (name, email, or form), and a link to the enforcement authority where users can file complaints.
The statement must be easy to find — linked from your footer on every page, ideally with the label "Accessibility" or "Barrierefreiheit". It must be in the same language as your website content.
Use the accessibility statement generator to create a compliant statement in minutes. It covers all BFSG-required fields and generates the correct markup.
Check: Can you find your accessibility statement in two clicks from any page? Does it contain all five required elements? Is it dated within the last 12 months?
Responsive Design and Text Resizing
Content must reflow without loss of information or functionality when zoomed to 400 percent at 1280px viewport width (WCAG 1.4.10). No horizontal scrolling should be required. Text must be resizable up to 200 percent without assistive technology, without loss of content or functionality (WCAG 1.4.4).
Touch targets on mobile must be at least 24x24 CSS pixels (WCAG 2.5.8 in WCAG 2.2, referenced by latest EN 301 549 updates). Spacing between targets must prevent accidental activation.
Check: Zoom your browser to 400 percent. Can you still read all content? Does the layout adapt without horizontal scrolling? Then test on mobile: can you tap every button and link without accidentally hitting adjacent elements?