The pattern
The eight barriers I find in most BigCommerce stores
After auditing a good number of Stencil stores, the same failures recur. They are not exotic. They sit in the parts of the store that make money, which is exactly why they matter.
1. Faceted search that a screen reader cannot follow
This is the signature BigCommerce problem. Filters update the product grid over AJAX with no live region, so a screen reader user ticks “Blue”, hears nothing, and has no idea whether anything happened. Selected facets are often styled with colour alone, and the “clear all” control is frequently a div.
The fix: a polite live region announcing the new result count, real checkboxes with real labels, selected state exposed through markup rather than colour, and focus managed so it does not jump back to the top of the page.
2. Quick view opening into nothing
Quick view modals in Cornerstone and most marketplace themes open without moving focus into the dialog, without a dialog role, and without trapping focus. A keyboard user tabs straight through to the page behind. Escape often does not close it.
The fix: role=”dialog” with aria-modal, focus moved to the dialog on open, focus trapped inside, Escape closes, and focus returned to the button that opened it.
3. Variant pickers built from swatches with no labels
Colour and size swatches are usually spans with a background colour. A screen reader announces nothing, or reads a hex value. Out-of-stock combinations are shown by dimming, which is invisible to anyone not seeing the page.
The fix: a real radio group with a visible legend, each option carrying its name in text, unavailable options marked with aria-disabled and stated in words, not just dimmed.
4. Mini-cart updates that are announced to nobody
Add to cart fires, the mini-cart count changes, and the page says nothing. The customer has no confirmation the item was added, so many add it twice or abandon.
The fix: an aria-live region confirming “Added to cart, 2 items”, and a focus decision that is deliberate rather than accidental.
5. Checkout fields relying on placeholder text
The optimised one-page checkout is better than most, but customised checkouts routinely drop visible labels in favour of placeholders. The prompt vanishes as soon as the customer types, which defeats anyone with a memory or attention difficulty, and error messages often say only “invalid”.
The fix: visible persistent labels on every field, errors that name the field and say how to correct it, and an error summary at the top of the form that receives focus.
6. Product images with filenames as alternative text
Bulk imports leave alternative text as SKU numbers or “IMG_4821”. On a category page of forty products, a screen reader user hears forty meaningless strings. Where the image carries the only description of a pattern or finish, that information is simply absent.
The fix: alternative text that says what the product looks like, decorative gallery duplicates marked as decorative, and a content rule so new products do not reintroduce the problem.
7. Contrast failures in sale badges and helper text
White text on light-coloured sale badges, grey shipping notes under the price, and pale placeholder text. These are the items automated scanners find first, which makes them the items demand letters cite first.
The fix: a palette check across the theme, with every text and background pair brought to 4.5 to 1, and 3 to 1 for large text and interface components.
8. Carousels and banners that cannot be stopped
Home page hero sliders that auto-advance with no pause control fail WCAG 2.2.2, and they are hostile to anyone who reads slowly or uses magnification. Slide text baked into the image is invisible to a screen reader entirely.
The fix: a visible pause control, real text over the image rather than inside it, correct slide announcements and keyboard-operable previous and next buttons.
Scope
What the audit covers
Templates and journeys, not a page count. Testing one product page properly is worth more than scanning a thousand, because they share a template.
Browse and find
Home, category with filters applied, faceted search, sorting, pagination, search results and the empty results state.
Choose and buy
Product page, variant selection, quantity, quick view, add to cart, mini-cart, full cart and the complete checkout including guest checkout.
Account and contact
Registration, login, password reset, order history, address book, contact form and newsletter sign-up.
Across all of it
Keyboard only, JAWS and NVDA on Windows 11, VoiceOver on macOS and iOS, TalkBack on Android, 200 and 400 percent zoom, and Windows forced colours.
Process
How a BigCommerce audit runs
Scope in writing
You send the store address. I confirm which templates and journeys are in scope, what it costs and how long it takes, in writing, within one working day. No call required.
Manual testing
Every template driven by hand with screen readers and keyboard alone, at 200 and 400 percent zoom and in forced colours. Automated tools run alongside, but they are the starting point, not the audit.
Report you can act on
Each barrier recorded with the WCAG 2.2 criterion it fails, where it occurs, who it affects, a severity rating and the Stencil file or app responsible, with the fix described in code terms.
Remediation and re-test
Your developers apply the fixes, or my team does. Then the store is tested again and the report reissued showing before and after, which is the document that proves the work happened.
Why me
Built, not just inspected
I do not only audit BigCommerce stores; I build and maintain an accessible BigCommerce Stencil theme, so every fix in the report is one I have already shipped somewhere. That means recommendations that work inside Stencil rather than generic advice. I am DHS Trusted Tester certified, working with IAAP certified colleagues, and M/S. Anblik has been doing this since 2003. All findings are delivered in writing, so nothing depends on a meeting.
- Accessible Stencil theme. A production BigCommerce theme with accessible faceted search, variant pickers, mini-cart and checkout already solved. See the BigCommerce accessibility theme.
- 97 published case studies. Real audits with the barriers found and the fixes confirmed, at the case study library.
- Evidence for counsel. If a demand letter arrived first, the report is written so your lawyer can use it. See what to do about a demand letter.
- Re-testing afterwards. Apps and theme updates reintroduce barriers. Periodic re-testing keeps the store where you left it.
FAQ
BigCommerce accessibility – frequently asked questions
Is BigCommerce accessible out of the box?
The platform gives you a reasonable foundation, but a live store is the Stencil theme plus your customisations plus apps plus your product content, and barriers appear across all four. Cornerstone and most marketplace themes ship with keyboard and screen reader problems in the faceted search, the quick view and the mini-cart. Being on BigCommerce does not make a store compliant.
Which parts of my store do you test?
The journeys that carry revenue and risk: home, category with filters applied, product page including variant selection, quick view, mini-cart, full cart, the whole checkout, account creation and login, search results, and the contact page. Testing every product page is unnecessary, because they share one template.
Can you fix the theme as well as audit it?
Yes. I build and maintain an accessible BigCommerce Stencil theme, so the fixes are ones I have already implemented elsewhere rather than guesswork. You can either take the report to your own developers or have my team apply the changes to your Stencil files.
Will accessibility work slow down my store?
No. Most fixes are markup and CSS: real labels, correct roles, visible focus, announced state changes. Removing an overlay script usually makes a store faster, not slower.
Do checkout changes risk breaking payments?
Checkout is the most sensitive area, so it is handled carefully and separately. On BigCommerce the optimised one-page checkout limits what can be altered, and the audit is explicit about which items are yours to fix, which need a BigCommerce support request and which are constrained by the platform.
How long does a BigCommerce audit take?
For a typical store, one to two weeks from start to report. Remediation is usually four to eight weeks depending on how much sits in apps rather than in your own theme files.
Do I need this if I already use an accessibility widget?
Probably more, not less. Overlays sit on top of the code and cannot repair the faceted search or the variant picker underneath. Stores running overlays still receive demand letters.
Next step
Get your BigCommerce store tested
Send the store address and I will reply in writing within one working day: what fails, what it covers, how long it takes and what it costs.