Skip to content

Making an online shop accessible: test, fix, evidence

This page describes the implementation: how we bring an existing shop to WCAG 2.2 AA step by step — audit, fixes directly in the template code, re-test and accessibility statement. Without a relaunch wherever the existing code allows it. Shop audit from €2,480 net, complete package from €4,900 net.

Fixes in the existing code instead of a relaunch BFSG mandate since June 28, 2025 Shop audit from €2,480 Re-test and accessibility statement

In short and in plain language

This page is about online shops. We make existing shops accessible. Accessible means that all people can use the shop.

We test the shop against the WCAG. These are rules for accessible websites. We go through the purchase with a keyboard. And we check what a screen reader can read out.

Then we fix the problems in the code. Search, cart and checkout come first. Often you do not need a new shop.

After that we test again. You also get an accessibility statement.

The BFSG is a German law. Many online shops usually fall under it. Write to us or give us a call.

Key figures

EN 301 549

assessment basis

WCAG 2.2 AA

assessment standard

15–25

page types in audit scope

Fixed price

after a review of your shop

Shop accessibility at a fixed price

from €2,480 shop WCAG audit, net
  • BFSG quick check as an entry point for €490
  • Shop WCAG 2.2 audit from €2,480 (up to 30 page types)
  • Audit plus remediation as a complete package from €4,900
  • Ongoing BFSG monitoring from €49 per month

BFSG mandatory since June 28, 2025 — violations can incur fines of up to €100,000 (BFSG Section 37). We assess our own website against WCAG 2.2 AA ourselves; status and known limitations are set out in our accessibility statement.

Prices as of October 2026. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.

This page answers a single question: how does an existing online shop become accessible? It is about implementation — audit, prioritization, changes in the template code, re-testing and evidence. The whole shop is in scope: product search, categories and filters, the product detail page with images, variants and reviews, the cart, the customer account and content pages. If your focus is specifically the order flow — address form, error dialogues, payment methods, order confirmation — the page on accessible checkout goes deeper. Which BFSG obligations apply to retailers, marketplaces and physical retail overall is set out under accessible e-commerce. The legal frame itself is described on the page about BFSG requirements.

Shop accessibility at a glance: the audit report

WCAG 2.2 AA · the accessible purchase path
The building blocks of an accessible online shop
An operable shop is created from the interplay of these elements
Accessible online shop
Keyboard operation across the pathARIA live: cart announcementContrast ≥ 4.5:1Alt text for product imagesLogical focus orderLabelled form fieldsAccessible checkoutFilters with result announcement
Purchase-path zones6/6tested
Page types in scope22assessed per view
Conformance86 %+31 since start
Shop auditfrom €2,480 net
CheckedKeyboard · screen reader output
Example view of a shop WCAG 2.2 audit: building blocks of the purchase path, audit scope and conformance status. Values are illustrative, not a client project.

The Most Common Barriers in the Purchase Process — and How We Fix Them

E-commerce platforms are technically complex: interactive filter bars, dynamic cart updates, multi-step checkouts and JavaScript-driven product configurators pose particular accessibility challenges. The WebAIM Million study shows that home pages of shopping websites have an above-average number of automatically detectable WCAG errors (Source: WebAIM Million 2024). Across all home pages analyzed, low-contrast text, missing alternative text, missing form labels and empty links and buttons are the most common detected errors. Problems with keyboard operation and dynamic content only show up when you play through every flow.

Product Search and Filtering

Autocomplete must be keyboard-operable, search results announced via ARIA live regions. Filter widgets need correct ARIA roles (combobox, listbox) and result count must be communicated after filter changes.

Product Detail Pages

Product images need descriptive alt texts, image galleries must be keyboard-navigable. Variant selection (size, color) requires correct ARIA attributes and visually distinct active states with sufficient contrast.

Shopping Cart and Quantity Changes

Dynamic cart updates must be announced via ARIA live regions. Quantity fields need labels, delete functions must be keyboard-reachable and price changes must be communicated to screen readers.

Checkout Process

Multi-step checkouts need clear progress indicators (e.g. the aria-current attribute with the value step), all forms must have labels and error messages, and the current step must be recognizable to screen readers.

Payment and Security

Payment forms must be fully keyboard-operable. CAPTCHAs must offer accessible alternatives (WCAG 1.1.1, plus 3.3.8 in login steps). Password managers and autofill must be supported. Security notices need sufficient contrast.

Order Confirmation and Account

Order confirmation pages must be semantically structured. Customer account areas (order history, address management, returns portal) must meet the same accessibility standards as the public shop area.

Our Approach: Shop Accessibility in Four Phases

We test the entire purchase process against the WCAG 2.2 success criteria at levels A and AA. The audit scope typically covers 15 to 25 page types: homepage, category, product detail, search, cart, each checkout step, login, registration, customer account and contact form. More about the audit process

From audit to a usable order

The critical purchase path first

We prioritize the business-critical steps: product search, product detail, shopping cart and checkout. This makes the most important processes usable first, before supporting areas follow.

  • Testing against WCAG 2.2 AA and EN 301 549
  • 15 to 25 page types in the audit scope
  • End-to-end keyboard run with screen reader output checks
1 · Critical purchase path — search, product, cart, checkoutPrio 1
2 · Supporting areas — navigation, footer, customer accountPrio 2
3 · Content and marketing — newsletter, landing pages, documentsPrio 3
BFSG conformance for revenue processes firstby revenue relevance

Typical Barriers in the Checkout Process

The checkout is the most business-critical area of an online shop and at the same time particularly prone to barriers. Here complex forms, dynamic validation, payment integration and address suggestions converge. The following examples illustrate typical barriers and our solution approaches.

Checkout: from barrier to completed order

Red before, conformant after

Many checkout barriers are invisible to sighted users but a hard obstacle for screen readers and keyboard operation. We make every field clearly labeled, high in contrast and equipped with understandable error texts — with as little change to the design as possible.

  • Visible, programmatically linked labels
  • Contrasts raised to at least 4.5:1
  • Error messages with a concrete correction hint
Before · address field3 violations
No label — screen reader says only “input field”
Contrast 2.4:1 — below 4.5:1 (WCAG 1.4.3)
Error marked in red only, no text
VS
After · address fieldconformant
Visible label, linked programmatically
Contrast 5.1:1 — AA met
Error text with a concrete correction hint
Example · checkout address fieldWCAG 3.3.1–3.3.4

Shop Platforms We Make Accessible

Accessibility requirements are identical across platforms, but technical implementation varies by shop system. We align the implementation with the respective shop system and take its platform-specific characteristics into account.

Shopware

Accessibility optimization for Shopware Community Edition: theme adjustments, plugin modifications, template overrides for semantic HTML and ARIA attributes. Focus on storefront components and checkout flow.

SaaS Shop Systems

Accessibility adjustments for hosted shop systems: template optimization, CSS contrast adjustments, JavaScript extensions for keyboard navigation and ARIA live regions. Considering platform-specific checkout limitations.

CMS-Based Shops

Accessibility optimization for CMS-based online shops: theme adjustments, plugin compatibility testing, custom widget accessibility and block editor optimization. Checkout and cart pages as particular focus points.

Enterprise E-Commerce

Accessibility optimization for enterprise shop solutions: layout adjustments, template overrides, JavaScript widget optimization and checkout flow improvements. Considering complex component architectures and multi-store setups.

Custom Shops

Accessibility consulting and implementation for custom e-commerce solutions based on React, Vue, Angular, Next.js or Svelte. Accessible component development and design system integration.

Headless Commerce

Accessibility optimization for headless architectures with separate frontend and backend. Special attention to client-side routing, dynamic content updates and state management for assistive technologies.

Ready for a shop where everyone can buy?

Economic Benefits of Accessible Online Shops

Accessibility in e-commerce is not just a legal obligation but also an economic argument. Just over 7.8 million severely disabled people lived in Germany at the end of 2025 (Source: Destatis, press release of 13 July 2026), plus millions with temporary impairments and the growing group of over-65s. An accessible user interface also improves general usability: clear forms, understandable error messages and a logical page structure reduce cart abandonment for all users.

Studies show that the average cart abandonment rate in e-commerce is around 70 percent (Source: Baymard Institute, as of September 2025). Part of these abandonments is due to usability issues: incomprehensible forms, missing error messages, confusing navigation and lack of transparency in checkout. Many of these problems overlap with accessibility barriers. Fixing WCAG violations therefore not only improves accessibility for people with disabilities but can also reduce cart abandonment and improve conversion rates for all customers.

What accessible shops gain

Larger audience

Just over 7.8 million severely disabled people lived in Germany at the end of 2025 (Source: Destatis), plus people with temporary impairments and the growing group of over-65s.

Fewer cart abandonments

The average cart abandonment rate is around 70 percent (Source: Baymard Institute, as of September 2025). Clear forms and understandable error messages reduce abandonment for all users.

Lower legal risk

Online shops fall directly under the BFSG. An implementation in line with WCAG 2.2 AA reduces the risk of fines and injunction lawsuits.

AspectNon-Accessible ShopAccessible Shop
Reachable audiencePeople with disabilities effectively excludedUsable for people with disabilities too
Cart abandonmentUnclear forms increase abandonmentClear labels and error texts reduce abandonment
Legal riskFines up to €100,000 and warnings possibleImplementation documented in the accessibility statement
Mobile operationTouch targets and zoom often unusable24x24 px targets, reflow to 320 px tested
ReputationNegative reports on social mediaPositioning as an inclusive brand
SEO and usabilitySemantic flaws can weaken rankingsClean semantics support discoverability

Mobile Commerce and Accessibility

A growing share of e-commerce revenue is generated through mobile devices. For accessibility this means: your online shop must be usable not only on desktop computers but also on smartphones and tablets with accessibility features enabled. Mobile screen readers interpret HTML and ARIA partly differently than desktop screen readers. We therefore also check every view in the smartphone layout for what it passes to the accessibility interface; tests with specific screen readers on real devices are not included.

WCAG 2.2 specifically addresses mobile accessibility: success criterion 2.5.8 requires a minimum size of 24x24 CSS pixels for interactive target areas to improve operability for people with motor impairments. Success criterion 2.5.7 requires drag-and-drop interactions to also be operable without dragging movements, particularly relevant for touch devices. Additionally the reflow requirement (1.4.10) must be ensured: content must be usable at 400 percent zoom, equivalent to 320 CSS pixel viewport width, without horizontal scrolling. Our audit checks all these requirements in the desktop and smartphone layout, including opened states such as menus and dialogs.

Accessible Product Data and Catalog Maintenance

The accessibility of an online shop depends not only on technical infrastructure but also on product data quality. Alt texts for product images must meaningfully describe the product: not just the product name but also relevant visual features like color, material and shape. For extensive catalogs with thousands of products we recommend a systematic alt text strategy: definition of a consistent description structure, training for product data maintainers and quality control through spot-check audits. Additionally product descriptions must be written in understandable language, tables with technical data must be correctly marked up and downloadable documents like datasheets and instructions must be created accessibly.

Special attention is also required for search function and filter navigation. Search autocomplete must be keyboard-operable and announce suggestions via ARIA live regions. Filter results must communicate the updated result count after each filter change. Faceted navigation elements need correct ARIA roles and states so screen reader users understand which filters are active and how many results remain. These interaction patterns are technically demanding but reliably solvable with the right ARIA patterns.

Online shops carry a particularly high compliance risk as they directly fall under the BFSG as electronic commerce services. Micro-enterprises providing services are exempt: companies with fewer than ten employees and an annual turnover or annual balance sheet total of no more than two million euros (BFSG Section 3(3) and Section 2 no. 17). Violations threaten not just fines of up to €100,000 (Source: BFSG Section 37) but also injunction lawsuits from consumer protection and disability associations. In the USA, where ADA Title III has been used for accessibility lawsuits for years, e-commerce companies are disproportionately frequently sued (Source: UsableNet ADA Litigation Report 2024). A similar development in the EU cannot be ruled out.

Beyond direct legal consequences a non-accessible online shop also carries reputational risk. Reports about poor accessibility spread quickly on social media and in the disability rights movement and can sustainably damage brand image. Conversely companies that proactively invest in accessibility position themselves as responsible and inclusive. This commitment can be a differentiating factor in competition, especially in industries where competitors have not yet taken the topic seriously. Our WCAG 2.2 audit shows you where your shop already meets the requirements and where improvements are needed.

Accessible Customer Communication in E-Commerce

The BFSG's accessibility obligation is not limited to the shop itself. Associated customer communication should also be accessibly designed: order confirmation emails must be semantically structured and readable with assistive technologies. Invoices and delivery notes provided as PDF must be tagged and navigable accessibly. Customer service channels must offer alternative contact options, not only by phone but also via email, chat or contact form. Returns portals and complaint processes must be just as accessible as the purchase process itself.

Special attention also deserves the accessibility of marketing content: newsletters should be semantically correctly structured and contain meaningful alt texts for product images. Landing pages for advertising campaigns must meet the same accessibility standards as regular shop pages. Even though the newsletter itself does not directly fall under the BFSG, it is inconsistent from a user perspective if the shop is accessible but the associated communication is not. A consistently accessible customer experience from first touchpoint to after-sales service strengthens trust and customer loyalty.

We advise you holistically on all aspects of the accessible e-commerce experience: from the shop itself through transaction communication to customer service. In our WCAG 2.2 audit we consider all relevant touchpoints and provide concrete recommendations for each area. This lays the groundwork for your customers to have a consistently accessible experience regardless of which channel they use to interact with your company.

Accessible throughout, from click to invoice

Every touchpoint counts

Accessibility does not end at the order button. Order confirmation, PDF invoice, customer service and returns portal must also be usable with assistive technologies. A consistent experience strengthens trust and customer loyalty.

  • Semantically structured confirmation emails
  • Tagged, navigable PDF invoices
  • Alternative contact channels: email, chat, form
Purchase
Confirmation
Invoice
Support
Return
Accessibility per touchpoint
Confirmation email semantically structured
PDF invoice tagged and navigable (PDF/UA)
Support reachable via email, chat and form
Returns portal operable by keyboard
A consistent experience from click to invoiceall channels

The purchase path in detail: three specialist articles

We have broken down the critical purchase path in dedicated articles: the accessible checkout with its address, shipping and payment steps, accessible product search with filters including facets and sorting, and accessible forms and validation, because orders can fail at unclear error messages. Together they cover the central steps of the purchase path. If you only want to rebuild the order flow, the page on accessible checkout is the direct entry point; for the obligations across retail as a whole see accessible e-commerce. What implementation costs is set out on the pricing page.

Three Routes to an Accessible Shop

Only one of them fixes the barriers in the code and provides the basis for an accessibility statement.

Tool

Automated scan only

  • Included: Runs in minutes and can be repeated as often as you like
  • Not included: Finds only automatically detectable errors, not all WCAG failures (WebAIM Million 2024)
  • Not included: Assesses neither variant selection nor the checkout as a connected process
  • Not included: Not sufficient as the basis for an accessibility statement
Shortcut

Embedding an overlay tool

  • Not included: Quickly installed, but only changes the presentation in the browser
  • Not included: The shop template and the checkout code remain unchanged
  • Not included: Accessibility practitioners advise against it in the Overlay Fact Sheet
  • Included: Context in the article on accessibility overlays
Our route

Audit with implementation in code

  • Included: WCAG 2.2 AA success criteria assessed per view across 15 to 25 page types
  • Included: Purchase path walked by keyboard with screen reader output checked instead of only scanned
  • Included: Fixes in the existing template code, without a relaunch where the code allows it
  • Included: Re-test and documented evidence via the accessibility statement

Typical starting points and our approach

Product filters
Starting point
Faceted filters only expandable with a mouse, selections not announced, result counts changing unnoticed.
Measure
Rebuild filters as semantic controls, correct the focus order, announce the result count through a live region.
Result
Goal: product search usable by keyboard and screen reader, fixes verified in the re-test.
Checkout
Starting point
Address and payment steps with unlabelled fields, error messages marked by colour only.
Measure
Add labels, autocomplete attributes and error texts at field level, link an error summary at the top of the form.
Result
Goal: order completion possible without a mouse, invalid input explained instead of merely coloured.
Embedded services
Starting point
A third-party review widget and payment iframe without keyboard access inside the purchase path.
Measure
Review provider options, embed an accessible alternative, document remaining limitations.
Result
Goal: purchase path operable end to end; remaining limitations are named in the accessibility statement.

Examples, not client projects.

Key Takeaways

  • Implementation in the existing template code: test, fix, re-test — without a relaunch wherever the existing code allows it.
  • We test the entire purchase path against the WCAG 2.2 AA success criteria across 15 to 25 page types.
  • Prices as fixed anchors: BFSG quick check for €490, shop WCAG audit from €2,480, complete package from €4,900, monitoring from €49 per month (all net).
  • Prioritized by revenue relevance: the critical purchase path first, supporting areas afterwards.
  • End-to-end run through the purchase path by keyboard with checks of the screen reader output, in the desktop and smartphone layout.

Frequently Asked Questions About Accessible Online Shops

How the website of a university department could look

The draft shows structure and handling: degree programmes you can narrow down, an application path in steps, a section on disability provisions and campus access. The university in it is invented.

Draft
University department

Department with degree filter and disability provisions

A draft for a university department: eight degree programmes can be filtered by qualification and study mode, each listing award, standard duration and entry requirements in the same order. The application is described in four steps, and a separate section covers disability provisions and the advisory service hours. On campus accessibility the draft names ramp gradient, hearing loop and tactile guidance — and what is missing.

Degree filterDisability provisionsCampus detailsSubtitles

Illustrative layout drafts. The businesses shown are fictitious; these are not client projects.

What can we help you with?

One click is enough — everything after that is optional.

Tell us briefly about the project

Everything on this step is optional.

As shown in your browser, with or without https://.

When would you like to start? (optional)
Rough budget range (optional)

Optional — you are not committing to anything.

A few keywords are enough. If you write something, please use at least 5 characters.

How can we reach you?

We usually get back to you within one business day.

Your name or surname, at least 2 characters.

Only needed if you would like a call back.

The address our reply should go to, with @ and domain.

By submitting you consent to the processing of your details to handle this request. Details in our privacy policy.