Checkout and Payment Accessibility
E commerce accounts for approximately 70% of all web accessibility lawsuits filed in the United States, according to UsableNet’s 2025 Year in Review. Ev..
E-commerce accounts for approximately 70% of all web accessibility lawsuits filed in the United States, according to UsableNet’s 2025 Year in Review. Every other page on your site is a browsing risk. Your checkout is a transaction risk: the one moment where an accessibility barrier costs you both a customer and a completed sale simultaneously. This article tells you who is legally responsible for your payment page’s accessibility (including the parts your payment processor controls), which WCAG 2.2 criteria apply specifically to checkout flows, and which fixes eliminate the most exposure first.
Video: Checkout and Payment Accessibility
Who Is Legally Responsible for Your Checkout’s Accessibility?
This is the question most business owners cannot answer. The short version: under ADA Title III, you are responsible for the end-to-end customer experience on your site. “We use Stripe” is not a legal defense when that widget creates an accessibility barrier.
The picture shifts depending on how your payment processor integrates. Here is who owns what:
| Integration Type | Who Controls the UI | Who Bears ADA/WCAG Responsibility |
|---|---|---|
| Hosted redirect (user sent to processor’s domain, e.g., PayPal Standard) | Payment processor | Primarily the processor. Verify their WCAG conformance statement before integrating. |
| Embedded widget or iframe (e.g., Stripe Elements, PayPal JS SDK, Square Web Payments SDK, Braintree Drop-in UI) | Processor controls widget internals; you control page wrapper and integration | Shared. You own the surrounding page, focus management, and wrapper code. The processor owns widget internals. |
| Fully custom payment form (merchant-built, own server or vault) | You | You bear full WCAG responsibility for every element. |
If you use an embedded widget, your exposure is real regardless of what the processor does. A broken focus transition between your address form and the Stripe Elements iframe is your problem. An unlabeled field inside the iframe is Stripe’s problem. Either way, your customer cannot complete the transaction and your business receives the demand letter.
Three practical steps before you go further:
- Request your processor’s VPAT (Voluntary Product Accessibility Template), a self-reported WCAG conformance document. Stripe, PayPal, and Square publish these. Request the most recent version.
- Test the embedded payment widget with a keyboard and screen reader independently from the rest of your checkout flow.
- Document the VPAT request in writing. This supports a good-faith defense and may create contractual remedies if the processor’s widget causes the failure.
Run your checkout URL through a free website accessibility checker to surface what automated scanning finds before you go further.
The WCAG 2.2 Criteria Your Checkout Must Meet
WCAG 2.2 Level AA is the current legal benchmark under the ADA (as consistently applied by courts) and under the European Accessibility Act, which entered enforcement on June 28, 2025. Six success criteria create the most checkout-specific exposure. For label and error-message implementation details, see Accessible Forms: Labels, Errors, Required Fields, and Instructions. This section covers the checkout scenarios that go beyond generic form guidance.
| WCAG SC | Requirement | Checkout Example |
|---|---|---|
| 1.3.5 Identify Input Purpose | Autocomplete attributes on personal data fields | Billing name, email, card number, and address fields should carry autocomplete attributes, reducing input burden for users with motor disabilities. |
| 2.2.1 Timing Adjustable | Users can extend time-limited sessions | Your checkout session timeout must warn the user at least 20 seconds before expiry with an option to extend. WooCommerce and Magento default sessions frequently fail this. |
| 2.4.11 Focus Appearance (WCAG 2.2 new) | Focus indicator meets minimum size and contrast | The active payment field must show a visible outline of at least 2px with 3:1 contrast against the adjacent background. Many Stripe Elements integrations strip this. |
| 2.5.7 Dragging Movements (WCAG 2.2 new) | Drag actions have a single-pointer alternative | Any swipe-to-pay or drag-to-confirm UI must also work via a single tap or click. |
| 3.3.4 Error Prevention | Financial transactions are reversible or confirmable | An order review screen before final submission, plus a confirmation email with a cancellation option, satisfies this criterion and is standard practice. |
| 3.3.7 Redundant Entry (WCAG 2.2 new) | Don’t make users re-enter information already collected | If billing address matches shipping address, pre-populate it. Forcing re-entry fails this criterion and adds friction for every user. |
The three WCAG 2.2-new criteria (2.4.11, 2.5.7, 3.3.7) post-date most competitor guidance. If your last accessibility review was against WCAG 2.1, your checkout has gaps even if that review was thorough.
What Inaccessible Checkouts Actually Cost You
The revenue case is not theoretical. According to the Click-Away Pound Survey (2019, directional, UK-based), 83% of disabled users limit their online shopping exclusively to websites they already know are accessible. That is not abandonment at the checkout. That is never arriving at the checkout in the first place.
When they do arrive and hit a barrier: only 8% of disabled customers who encounter difficulty on a website will contact the site owner about it, according to the same 2019 survey. The other 92% simply leave. You get no complaint, no bug report, no data in your analytics explaining the drop-off. You just lose the sale.
People with disabilities in the United States hold nearly $500 billion in disposable income, according to Accenture’s 2023 Disability Inclusion research, and that figure excludes the spending power of their families and advocates. An inaccessible checkout is not a niche problem. It is a barrier placed in front of a large and largely invisible customer segment.
The legal exposure compounds this. According to UsableNet’s 2025 Year in Review, approximately 3,117 federal web accessibility lawsuits were filed in 2025, a 27% increase over 2024. Including state court filings, total cases exceeded 5,000. Checkout flows are the most frequently cited barriers in those cases.
Three Fixes That Eliminate the Most Checkout Risk First
Not all WCAG failures carry equal legal and revenue weight. These three fixes are ranked by impact-to-effort ratio: the ones that reduce lawsuit exposure and cart abandonment fastest.
1. Fix focus management at every iframe boundary (High impact, medium effort)
If you use an embedded payment widget, the transition from your address form to the payment iframe is where keyboard users most commonly get stranded. When the user tabs out of your last address field, focus must move predictably into the payment widget. When they complete the widget, focus must return to your “Place Order” button. This requires explicit focus management code in your integration: two to four lines of JavaScript that eliminate one of the most common checkout-specific keyboard failures. For the full keyboard testing protocol, see Keyboard Accessibility: Test Your Site in 5 Minutes.
2. Replace reCAPTCHA v2 on your order submit button (High impact, low effort)
If you have a visual image challenge between your customer and completing their purchase, remove it. reCAPTCHA v2 fails WCAG 1.1.1 (non-text content), the audio alternative is widely considered unusable, and it blocks screen reader users at the worst possible moment. Compliant alternatives include Friendly Captcha, Cloudflare Turnstile, and ALTCHA, all of which run background verification without presenting a user challenge. Swapping this out is typically a one-hour implementation change with no design work required.
3. Add session timeout warnings (Medium impact, low effort)
Most checkout session timeouts are silent. The user fills in their billing details, pauses to find their card, and returns to find the session expired and their form cleared. WCAG 2.2.1 requires a warning at least 20 seconds before expiry with an option to extend. Most WooCommerce and Magento installs fail this by default. A session warning modal is a small plugin or snippet, and fixing it improves conversion for all users, not just those with disabilities.
Once you have addressed these three, use the Accessibility Audit Checklist: What to Review Before You Buy a Tool to evaluate whether your testing approach will catch the remaining gaps.
Frequently Asked Questions About Checkout Accessibility
Does WCAG apply if I use a third-party payment page?
Yes. If your processor hosts the payment page on their own domain via a redirect, the processor bears primary responsibility for that page’s WCAG conformance. You are still responsible for the transition to that page: link text, focus management, and the context your site provides. You are also responsible for verifying that the processor’s page is accessible before you integrate it. Request a VPAT before signing any payment processor contract.
Can I be sued if my checkout is not accessible?
Yes. ADA Title III has been applied to e-commerce checkouts in multiple federal court cases, and there is no small business exemption. Demand letters for checkout accessibility failures typically settle in the $5,000-$25,000 range; litigation costs run higher. According to UsableNet’s 2025 Year in Review, federal web accessibility lawsuits increased 27% year over year in 2025, with e-commerce as the dominant target sector.
Does Shopify automatically make my checkout accessible?
No, not entirely. Shopify’s default checkout themes include baseline accessibility features, but third-party apps, custom theme modifications, and added payment widgets can introduce failures at any point. You cannot assume your Shopify checkout is WCAG compliant without testing it. The checkout editor themes added in recent Shopify versions are better than older templates, but “better” is not the same as “compliant.”
What is the WCAG rule for checkout session timeouts?
WCAG Success Criterion 2.2.1 (Timing Adjustable) requires that any time limit be removable, adjustable, or that the user be warned at least 20 seconds before expiry with an option to extend. This applies directly to checkout session timeouts. If your session expires silently and clears the form, you fail this criterion.
The three fixes above, focus management at iframe boundaries, replacing reCAPTCHA v2, and adding session timeout warnings, will eliminate the highest-concentration risks in most checkout flows without requiring a full development sprint. Start there, then work through the WCAG 2.2 criteria in the table above.
To see which failures currently exist on your payment pages, run your checkout URL through the free website accessibility checker and share the report with your developer or agency. Automated scanning will not catch everything, but it will surface the labeling gaps, contrast failures, and missing form roles that your processor’s VPAT may not mention.
This article is for general informational purposes and is not legal advice. Consult an accessibility attorney for guidance specific to your business.