German online shops face a specific set of BFSG challenges that informational websites do not. Product filters that only work with a mouse. Shopping carts that trap keyboard focus. Checkout forms that announce errors to sighted users but stay silent for screen readers. Payment widgets from third parties that your team did not build but your business is legally responsible for. This guide covers what the Barrierefreiheitsstärkungsgesetz requires from e-commerce specifically — not websites in general, but the components that make a shop a shop.
Why Online Shops Face Higher BFSG Risk
The BFSG classifies e-commerce as a covered service category. Any online shop selling to consumers in Germany must comply — regardless of where the business is based. A French Shopify store shipping to Germany, an American marketplace with German buyers, a Polish dropshipper targeting German keywords: all in scope.
Online shops face higher enforcement risk for a practical reason: they have more interactive elements than typical websites. Every product filter, sort control, quantity selector, add-to-cart button, coupon field, address form, and payment widget is a potential accessibility failure point. A corporate brochure site might have 10 interactive elements per page. A product listing page might have 50.
The DataPulse study tested 2,446 German online shops specifically — not random websites — and found 99 percent non-compliance. The Abmahnung wave that started in August 2025 targeted online shops almost exclusively, because their violations are easy to identify, document, and monetize through cease-and-desist letters.
Product Pages: Images, Variants, and Reviews
Product images need alt text that describes the product, not the filename. For a blue cotton t-shirt, the alt text should be "Blue cotton crew-neck t-shirt, front view" — not "product-1847.jpg" or "t-shirt" alone. When a product has multiple images, each needs distinct alt text describing what that specific image shows.
Variant selectors — color, size, material — must be keyboard-operable and announce the selected option to screen readers. Custom dropdown menus built with div elements and JavaScript often fail both requirements. Use native select elements or implement the WAI-ARIA combobox pattern correctly.
Star ratings need text alternatives. A screen reader encountering five star SVGs with no text reads nothing meaningful. Add aria-label="4.5 out of 5 stars" or use visually hidden text.
Customer reviews must be navigable. If reviews load dynamically via infinite scroll or "load more" buttons, those controls must be keyboard-accessible and the new content must be announced to screen readers via aria-live regions.
Product Filters and Sorting Controls
Faceted navigation — filtering by price, brand, size, color, category — is where most German online shops fail accessibility testing. The common pattern: a sidebar of clickable filter options built with JavaScript click handlers that do not respond to keyboard events.
Each filter control must be operable with Enter or Space keys. Checkbox filters need proper label associations. Range sliders (for price ranges) must have keyboard alternatives — either arrow key support or text input fields. When filters are applied, the results area must announce the update: "Showing 23 products" via an aria-live region, so screen reader users know the page changed.
Sorting controls ("Sort by price", "Sort by rating") are frequently implemented as styled links or divs without proper button roles. Use native button or select elements. If using custom components, implement the WAI-ARIA listbox pattern.
Active filters must be visible and removable. A "Clear all filters" button must be keyboard-accessible. Each individual filter tag ("Size: M ×") must be removable via keyboard.
Shopping Cart Accessibility
The "Add to cart" confirmation is a critical moment. When a user adds a product, they need feedback. A visual animation alone is not enough — screen reader users need an announcement. Implement this with an aria-live="polite" region that announces "Product added to cart. Cart now contains 3 items."
The mini-cart dropdown or slide-out panel must be keyboard-navigable. Focus must move to the cart when it opens and return to the trigger element when it closes. The Escape key must close it. These are standard dialog interaction patterns defined in WAI-ARIA Authoring Practices.
Quantity adjustments need proper labeling. The plus and minus buttons next to each cart item need aria-label attributes that include the product name: "Increase quantity of Blue T-Shirt" rather than just "+".
The "Proceed to checkout" button must have sufficient contrast, a clear label, and must be reachable via keyboard without tabbing through every cart item first. Consider adding a skip link within the cart: "Skip to checkout."
Checkout Flow: The Highest-Risk Area
The checkout flow determines whether a disabled user can actually buy from your shop. If they cannot complete a purchase, you are violating the BFSG's core purpose: ensuring equal access to e-commerce services.
Address forms must support browser autofill with correct autocomplete attributes: autocomplete="given-name", autocomplete="family-name", autocomplete="street-address", autocomplete="postal-code", autocomplete="country". This is both a WCAG 1.3.5 requirement and a usability improvement for all users.
Multi-step checkouts need a progress indicator that is accessible to screen readers. Indicate the current step, total steps, and step labels: "Step 2 of 4: Shipping address." Each step transition must manage focus — when moving to step 3, focus should land on the first element of that step, not stay on the "Next" button from step 2.
Inline validation must announce errors in real time. When a user tabs away from an invalid field, the error must be associated with the field via aria-describedby and announced by screen readers. Waiting until the user submits the entire form to show errors creates a frustrating experience for everyone and a barrier for screen reader users who cannot scan the page visually for red highlights.
Payment Integration Accessibility
Third-party payment widgets are your legal responsibility under the BFSG, even though you did not write their code. Stripe Elements, PayPal buttons, Klarna widgets, Amazon Pay, Apple Pay, and Google Pay all render inside your checkout page. If they are inaccessible, your shop is non-compliant.
Test each payment method with keyboard-only navigation. Can you select PayPal as a payment method using Tab and Enter? Can you complete the Stripe card form without a mouse? Does the Klarna installment calculator announce options to screen readers?
Common failures: iframes that trap keyboard focus (users enter the payment iframe and cannot Tab out), unlabeled card number fields inside Stripe Elements, PayPal buttons that only respond to mouse clicks, and Klarna modals that open without moving focus.
If a third-party widget fails accessibility testing, document it, report it to the provider, and offer an accessible alternative (bank transfer, invoice) in the meantime. Having at least one accessible payment method reduces your legal exposure significantly.
Search Functionality
The search input must have a visible label or an accessible name via aria-label (WCAG 1.3.1). Autocomplete suggestions that appear as you type must be navigable with arrow keys and selectable with Enter. Screen readers must announce that suggestions are available and how many there are: "5 suggestions available, use arrow keys to navigate."
Search results pages must announce the result count. "42 results for cotton t-shirt" should appear in an aria-live region or be the first heading on the results page. If no results are found, that must also be clearly communicated — not just an empty page.
Filters on search results pages follow the same requirements as category page filters: keyboard-operable, properly labeled, with announcements when results update.
Cookie Consent and Overlays
Cookie consent banners are the first thing every visitor encounters — and frequently the first accessibility barrier. The banner must be keyboard-navigable. The "Accept" and "Reject" buttons must be reachable via Tab. The banner must not trap focus (a common failure where Tab cycles within the banner endlessly).
Focus must start on the cookie banner when the page loads. Once the user makes a choice, focus must move to the main page content. The banner must be dismissible with keyboard alone — preferably with a clear "Reject all" option, not just "Accept" and "Settings."
Settings panels (where users choose individual cookie categories) must use proper checkbox patterns with labels. The "Save preferences" button must be keyboard-accessible.
Many German shops use Cookiebot, OneTrust, or Usercentrics. All three have accessibility modes — but they are not always enabled by default. Check your CMP configuration and enable WCAG mode if available.