Most BigCommerce stores fail accessibility on the same handful of screens: the product page, the cart, and the checkout. Those are exactly the screens where a blocked customer means a lost sale. The good news is that BigCommerce accessibility is largely within your control through theme choices, content habits, and a few Stencil tweaks, not a platform rewrite.
This guide walks through what to fix and in what order, with concrete examples. It also explains how the European Accessibility Act (EAA) changes the stakes for any retailer selling to EU consumers, and how to confirm your store actually meets the standard rather than just hoping it does.
Why accessibility is now a retail requirement
The legal baseline is no longer aspirational. The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025, and it covers e-commerce consumer services, including online stores selling to EU customers. The technical bar it points to is WCAG 2.2 Level A and AA, referenced through the European standard EN 301 549. Penalties vary by member state, but the practical risk is broader than fines: an inaccessible store quietly turns away customers who use screen readers, keyboards, or magnification every day.
WCAG is organized around four principles, often shortened to POUR: content must be Perceivable, Operable, Understandable, and Robust. Every fix below maps back to one of those. If you sell across borders, the same WCAG 2.2 AA target applies whether your obligation comes from the EAA, the US ADA, or a public-sector contract. For the law-to-standard chain, see our overview of the European Accessibility Act.
Start with an accessible BigCommerce theme
Your theme decides most of your accessibility outcome before you write a word of content. BigCommerce's Stencil themes (Cornerstone and its derivatives) give you a reasonable starting point, but theme defaults and customizations are where problems creep in. Audit these first:
- Color contrast: body text needs a 4.5:1 ratio against its background; large text (18pt, or 14pt bold) and UI components like buttons and form borders need 3:1. A pale-gray 'Sale' badge or a light-on-light 'Add to Cart' button is the single most common BigCommerce failure.
- Focus visibility: tab through your homepage. Every link and button must show a clear focus ring. Many custom themes strip the default outline with CSS — restore it, and make sure WCAG 2.2's 2.4.11 Focus Not Obscured (Minimum, AA) is met so a sticky header never hides the focused element.
- Headings and landmarks: one h1 per page, logical h2/h3 nesting, and real <nav>, <main>, and <footer> regions so screen reader users can jump around.
- Target size: 2.5.8 Target Size (Minimum, AA) wants interactive controls to be at least 24x24 CSS pixels — relevant for quantity steppers, swatch pickers, and mobile menu icons.
Before committing to a theme, run a quick automated pass and tab-test it in the demo. Settle your palette while you are still in design mode, when a color swap costs nothing rather than a site-wide retheme.
Write alt text that sells, not just complies
Product imagery is the heart of a store and a frequent accessibility gap. Every meaningful image needs an alt attribute that describes what matters for a buying decision. BigCommerce lets you set alt text per image in the product editor — use it instead of leaving the auto-generated filename.
- Good: alt="Navy merino wool crew-neck sweater, front view"
- Weak: alt="IMG_4821" or alt="sweater"
- Decorative only: leave alt="" (empty) for background flourishes and spacer graphics so screen readers skip them.
Two retail-specific traps: text baked into promotional banner images (the discount code is invisible to screen readers unless it's also in the alt text or page copy), and zoom or gallery thumbnails that lack labels. Decide your convention once, then apply it across every product template so new uploads inherit the habit.
Make checkout and forms keyboard-accessible
Checkout is where accessibility converts directly to revenue. BigCommerce's Optimized One-Page Checkout is more accessible than older custom flows, but you still need to verify the whole purchase path works without a mouse and announces itself correctly to assistive technology.
- Label every field. Each input needs a programmatically associated <label> — placeholder text alone fails, because it disappears on focus and is often too low-contrast. See accessible forms for the patterns.
- Tie errors to fields. When a card number is invalid, the message must be linked to the input and announced, not just shown in red.
- Respect Redundant Entry (3.3.7, A) — don't force shoppers to retype their shipping address as billing; offer a 'same as' checkbox.
- Honor Accessible Authentication (3.3.8, Minimum, AA): let customers paste one-time codes and use password managers; never block paste on login or guest-checkout verification fields.
- Avoid drag-only interactions (2.5.7 Dragging Movements, AA) in any slider, image reorder, or quantity control — provide button or keyboard alternatives.
Test the full journey by unplugging your mouse: Tab to a product, add to cart, open the cart, reach checkout, and complete a test order using only the keyboard. Anything you can't reach or operate is a blocker.
Get EAA-ready and prove it
Readiness is a process, not a one-time scan. A workable sequence for a BigCommerce store: fix theme-level contrast and focus issues, correct alt text and form labels across templates, validate checkout end to end, then publish an accessibility statement describing your conformance and a contact route for problems. Keep a copy of your testing notes alongside it.
For the retail-specific obligations — product information, support channels, and contracts — see EAA compliance for e-commerce. To confirm where you stand today, run your storefront and a product page through AccessScan; it flags contrast, missing alt text, label, and structure issues so you can prioritize the fixes that matter to checkout first.