Accessible Online Shop: A Checkout That Gets Every Customer to Payment
We make your shop's product search, cart and checkout accessible to WCAG 2.2 AA — cleanly in your existing code, without a relaunch. This wins 7.8 million people with disabilities as buyers while meeting the BFSG obligation in force since 28 June 2025.
from 2,480 EUR
WCAG shop audit fixed price
7.8 M
buyers with disabilities in DE
28 Jun2025
BFSG obligation in force
50+
accessible projects
Shop accessibility has been mandatory since 28 June 2025
An online shop only earns when the customer can complete the purchase. This is exactly where accessibility decides revenue: a screen reader user who does not hear the error message in checkout, a keyboard user who cannot reach the order button, or a customer with low vision who cannot select the variant will leave the shop and buy elsewhere. We make your shop technically accessible — from product search through the product page to order confirmation — and fix barriers directly in the existing template code, without a relaunch. The legal framework is provided by the Accessibility Strengthening Act; how a full audit works is described on the page about the WCAG 2.2 audit. The overview of approach, platforms and economics is on the page about the accessible online shop as a full service.
Shop audit report: conformance, principles and findings at a glance
Shop audit at a fixed price
- WCAG 2.2 AA review from product discovery to order confirmation
- Findings list prioritized by severity, critical path first
- Start with the BFSG quick check from as little as 490 EUR
- Complete implementation as an SME package from 4,900 EUR
SME shop up to 30 pages. Large catalogs and configurators after a brief review with a binding fixed-price offer.
Where the Shop Decides Between Purchase and Abandonment
Along the purchase path the accessibility requirements map precisely to individual WCAG 2.2 success criteria. Product search falls under keyboard operability (2.1.1) and visible focus (2.4.7); autocomplete suggestions must be implemented as a combobox pattern with correct ARIA role and live announcement. The product page requires text alternatives for images (1.1.1), a correct heading structure (1.3.1) and sufficient contrast (1.4.3); variant selection must be comprehensible via keyboard and screen reader. The checkout bundles the most demanding criteria from section 3.3 (Input Assistance): labels or instructions (3.3.2), error identification (3.3.1), error suggestion (3.3.3) and error prevention for legal transactions (3.3.4). This page works through each of these building blocks technically.
Accessible Product Search
Search field with correct label and ARIA attributes. Autocomplete suggestions navigable by keyboard and announced by screen readers. Search results with clear structure and sorting options.
Accessible Filters and Facets
Filter areas as fieldsets with legends. Checkbox and radio groups with correct association. Live result updates with ARIA live regions so screen reader users perceive the change.
Product Images and Galleries
Meaningful alt texts describing the product, not just the filename. Image galleries with keyboard-accessible navigation. Zoom functions operable with magnification software.
Accessible Cart
Quantity changes with correct labeling and live sum updates. Remove buttons with clear reference to the respective item. Summary of all items in tabular, semantically correct form.
Accessible Checkout
Step indicator with ARIA attributes. Form fields with labels, required field hints and error text on validation issues. Payment options as a proper radio group. Order confirmation with clear summary.
Customer Account and Registration
Accessible registration with comprehensible password requirements. Login form with correct autofill. Order overview, invoice download and address management operable by keyboard and screen reader.
Checkout Accessibility: The Most Sensitive Area
The checkout is where accessibility determines revenue or abandonment. A sighted user orients visually: they see the red border around an incorrectly filled field and the error text below. A screen reader user perceives none of this if the field is not programmatically linked with the error message. A user with motor impairments who only uses the keyboard cannot reach the order button if it falls outside the tab sequence.
We implement checkout accessibility systematically: every form field receives a programmatically linked label. Required fields are marked via aria-required and a visual hint. Error messages are associated with the respective field via aria-describedby and appear in an error summary at the page top. Focus is automatically moved to the first erroneous entry after validation errors. Payment options are implemented as a radio group also operable with arrow keys. The order confirmation contains an accessible summary of all order details.
Product Pages: Technical Accessibility Requirements
An accessible product page must serve multiple audiences simultaneously. Blind users need meaningful alt texts for product images that do not just name the product but describe relevant visual details: color, material, perspective. Users with low vision need sufficient contrast and the ability to enlarge text to 200 percent without losing functionality. Users with motor impairments must be able to select variants and reach the add-to-cart button without using a mouse.
Special challenges arise from product configurators, size charts and comparison features. A configurator with dropdown menus must be keyboard-operable and announce the selected configuration comprehensibly for screen readers. Size charts must be implemented as HTML tables with correct header markup, not as images. Comparison features must present compared properties in an accessible structure that is understandable without visual side-by-side display.
The accessible product page in detail
Variant selection everyone can operate
On the product page, alt texts, variant selection and the add-to-cart button decide whether a purchase is possible at all. We implement every variant as a radio group with a marked state, so the chosen option is reachable by keyboard and audible to screen readers.
- Meaningful alt texts instead of filenames (WCAG 1.1.1)
- Size chart as a real HTML table with header markup
- Variants as a radio group, operable with arrow keys
- Add-to-cart confirmation announced via ARIA live region
Platform-Specific Accessibility
Shopware CE
Adaptation of the Storefront theme for WCAG 2.2 conformance. ARIA attributes in product listings, filters and checkout. Accessible forms in registration and customer account. Plugin review for accessibility barriers.
WordPress and Shop Extensions
Theme optimization for semantic structure and keyboard accessibility. Accessible checkout templates for WordPress-based shops. Editor training for accessible content. Plugin audit for accessibility conflicts.
Custom Developments and Headless
ARIA patterns for SPA frameworks (React, Vue, Svelte). Route change announcements, focus management in dynamic components, live regions for asynchronous updates. Component library audit.
TYPO3 and CMS-Based Shops
Accessible templates for TYPO3-based shop frontends. Content element training for editors. Third-party extension review for WCAG conformance. Automated CI pipeline integration.
Accessible Payments and External Payment Providers
Payment processing is an area where shop operators frequently depend on external providers. Embedded payment forms from third parties can introduce their own accessibility issues: iFrames without accessible titles, credit card fields without labels, CAPTCHAs that screen readers cannot solve. We audit the accessibility of integrated payment providers, document barriers outside your control and recommend alternative payment paths where needed.
Where possible, we configure payment providers for maximum accessibility: correct labeling of embedded fields, accessible error handling and accessible confirmation pages. In the accessibility statement, we transparently document which areas are fully conformant and where unavoidable limitations exist, along with alternative contact options for affected users.
Embedded payment forms under the microscope
Where iFrames put accessibility at risk
Third-party payment forms often live in an iFrame whose accessibility you cannot control yourself. We check every embedded field, document barriers outside your control and secure purchase completion via an accessible alternative path.
- iFrame title and field labels checked systematically
- Captcha barriers identified and alternative paths named
- Provider error output tested for screen reader compatibility
- Transparent documentation in the accessibility statement
Four tools we use to test every step
Screen reader test
We operate product search, cart and checkout with NVDA and VoiceOver and listen to what is announced, instead of only reading the code.
Keyboard walkthrough
The entire purchase path is traversed using only Tab, arrow and Enter keys to uncover focus traps and unreachable buttons.
200% magnification
Text and controls are enlarged to 200 percent to reveal overlaps and clipped content (WCAG 1.4.4).
Our Audit Process for Online Shops
Scope Definition and Prioritization
We define the page types to audit: homepage, category, product detail, cart, checkout, customer account, search, contact. Business-critical paths from product discovery to purchase completion take priority.
We test your checkout with real assistive technology
In more than 50 accessible projects (project experience) we have made purchase paths accessible from product discovery to order confirmation. Let a shop audit show you where your order process stands today.
Accessibility in the Checkout Process
The checkout is the most business-critical area of an online shop and simultaneously the area where accessibility barriers cause the greatest economic damage. A form field without correct label association, an error message displayed only visually, or a button unreachable by keyboard: each of these barriers can make purchase completion impossible for users of assistive technologies. Our audits test the entire purchase process: from product search through shopping cart to order confirmation, we test every step with screen readers, keyboard navigation and various magnification levels. Remediation prioritizes the checkout above all other page areas because the direct connection between accessibility and revenue is most evident here.
BFSG Conformance as Competitive Advantage
The obligation for accessibility under the BFSG is regarded by many shop operators as a pure compliance task. In doing so, they overlook the economic potential: approximately 7.8 million (Federal Statistical Office, 2023) severely disabled people live in Germany, plus millions with temporary or age-related limitations. An accessible shop unlocks this purchasing power while simultaneously improving the user experience for all customers. Clear structure, understandable navigation and fast usability are quality characteristics that users without disabilities also appreciate and that translate into longer dwell time and higher conversion rates.
Furthermore, accessible shops benefit from better search engine rankings. Semantic HTML, correct heading structures and descriptive alt texts are relevant not only for screen readers but also for search engine crawlers. An accessible implementation typically leads to cleaner code structure, faster load times and better mobile usability, all factors that positively affect organic visibility.
Our training courses equip your development team with the knowledge to implement new shop features accessibly from the start. This makes accessibility an integral part of your development process rather than remaining a retroactive obligation.
Key takeaways
- Accessibility decides purchase or abandonment in the checkout — every barrier is lost revenue
- Shop audit to WCAG 2.2 AA at a fixed price from 2,480 EUR net, starting with the BFSG quick check from 490 EUR
- Implementation directly in the existing template code, without a relaunch — SME complete package from 4,900 EUR
- Mandatory since 28 June 2025; violations can incur fines up to 100,000 EUR (BFSG §37)
- Tested with NVDA, VoiceOver and keyboard-only operation, including the accessibility statement as a basis