[Digital commerce & conversion]() / [Use cases]() / [Accessible checkout]() [How it works]() [What you get]() [Scope]() [Start a review]() [Digital commerce & conversion]()[Releases]() # Make search, sizes, cart and payment work for everyone. People who use a keyboard or a screen reader can search, choose a size, check out and pay, and you can show it. [Start with a conversion review]() [How it works]() Keyboard path, search to payment **3 of 5**steps completed by keyboard alone - Search and suggestions - Size selector Stock state not announced - Cart quantity - Checkout errors Not linked to their fields - Payment form The buying path, tried with a keyboard alone. Open steps are the fix list. ## Sound familiar? - A shopper using a keyboard can’t get past the size selector. - The accessibility scan passes, and a person using a screen reader still can’t pay. - Nobody has mapped the rules to the store’s actual pages. Some customers can’t finish the purchase. In some markets the rules now expect that they can. ## What changes. ShowTodayWith the engine Checks An automated scan, once a year Scans on every release, and people on the key paths Scope The whole site, which in practice means none of it The path that earns money: search, size, cart, payment Fixes A report nobody owns A ledger of fixes with owners, hours and dates Proof A badge Tasks completed by keyboard and screen reader ## How it works. 4 steps, 4 stages. - AI**1** - Rules and automation**2** - Your team**1** - Approval 1. 1 Scan 1. Rules and automation ### Scan every release Automated checks on search, product, cart and payment pages. They find the easy failures, and only some of them. - Playwright 2. 2 Test 1. Your team ### Test the paths by hand People using a keyboard and a screen reader try to buy. Automation can’t establish accessibility alone. 3. 3 Fix 1. AI ### Draft the fixes Proposed markup and code changes, each naming the criterion it meets, for your engineers to review. - GitHub 4. 4 Keep 1. Rules and automation ### Keep it from slipping The key-path checks join the release pipeline, so a regression stops the release. - GitHub Each new page or feature is checked on its way out ## What you get. Real work, every week. Accessibility fixes Effort in hours - Checkout errorsMessage not linked to its field **5 h**Fix first - Size selectorOut-of-stock sizes unlabeled **3 h**Fix first - Sale price contrastPasses on desktop, fails on mobile **2 h**Fix - Promo fieldLabel disappears on focus **1 h**Fix The fix ledger: what’s broken, what it costs to fix and what goes first. WCAG 2.2 on the buying path Step Criterion Result Search Focus stays visible and unobscured Pass Size selector Targets at least 24 by 24 pixels Fail Sign in No puzzle or memory test to log in Pass Payment Errors named and tied to their fields Fail The criteria that matter most on the buying path, checked step by step. ## How you’ll know it’s working. 1. Key tasks completed by keyboard Search, size, cart and payment, start to finish. 2. Open defects by step Where the buying path still fails, with the hours to fix it. 3. Criteria met on the key paths The WCAG 2.2 criteria that matter here, such as target size and focus. Baselines agreed before we build. ## Works with what you have. Commerce - Shopify Delivery - Playwright - GitHub We configure first Your theme’s settings and the checks you already run come first. We add keyboard and screen reader testing on the key paths. We build when Regressions keep reaching the store, or a market you sell in now expects it. ## What a first build includes. Built in your accounts, around your team. Scope, fee and baseline agreed before we start. 1. 1 Design 2. 2 Build 3. 3 Run it, or hand it over [Start with a review]() [Scope this build]() ### We build - A keyboard and screen reader test of the buying path - Fixes for the defects found, with owners - Journey checks added to the release pipeline - A criteria report mapped to WCAG 2.2 ### We start from - Theme and storefront code access - Search, product, cart and payment flows - The markets you sell in ### From your team Owner Head of ecommerce, with engineering Involves - Ecommerce - Engineering - Design - Legal ## Questions teams ask. Is this a legal requirement for us? It depends on where you sell and how big you are. EU ecommerce accessibility rules have applied since June 28, 2025, with exemptions and transition conditions to check. As of October 2026, US guidance covers online services but sets no technical standard. WCAG 2.2 is voluntary. This isn’t legal advice. Can AI make the site accessible? It helps draft fixes, and scans catch part of the problem. Automation can’t establish accessibility alone, so people try the buying path with a keyboard and a screen reader. Who owns it once it’s running? You do. It’s built in your accounts, documented, with training for the people who run it. Ownership usually sits with your head of ecommerce, with engineering. We can keep running it with you, or step back. How do we start? Usually with a conversion review: two to four weeks, a fixed fee credited to the build, and a plan that’s yours. If the job is already clear, we can scope the build directly. ## Part of your conversion engine. One of 14 use cases, in 5 parts. [See the whole conversion engine]() 1. [Evidence & decisions **2**]() 2. [Search & discovery **2**]() 3. [Guidance **4**]() 4. [Cart & checkout **4**]() 5. [Releases **2**]() In releases - [**Release assurance**Ship proven changes every week, safely]() - **Accessible checkout**You’re here Works with - [**Checkout clarity**Show the full cost and delivery date before checkout]() ## Make buying work for everyone. Start with a conversion review. [Start with a conversion review]() [**Talk it through first**15 minutes]() We reply within one business day. --- Source: [https://www.thekeating.co/use-cases/accessible-checkout/]() [Contact Keating & Co](mailto:nelson@thekeating.co) · [Agent guidance](https://www.thekeating.co/llms.txt)