Platform Guides

BigCommerce Accessibility for B2B and Mid-Market Storefronts

BigCommerce is a SaaS commerce platform whose storefront is rendered through its Stencil theme framework. Stencil uses Handlebars templates, SCSS, and ES modules, and the recommended starting point for every new store is the Cornerstonereference theme. Cornerstone is reasonably structured out of the box — semantic landmarks, labeled form fields, a skip link — but the markup you ship to customers is the markup your agency or in-house team customized on top of Cornerstone, not Cornerstone itself. Most of the accessibility regressions we see on BigCommerce sites originate in that customization layer: removed focus outlines, custom dropdowns written in vanilla JS that do not implement the WAI-ARIA listbox pattern, and ajax cart updates that do not announce themselves to screen readers.

The risk profile changes again once you turn on BigCommerce's B2B features. Gated pricing, customer-group conditional rendering, bulk-order tables, quote requests, and configurable products all introduce a11y patterns that do not exist on a consumer storefront, and they all need to be tested while logged in as the customer group that actually sees them. Per TestParty's analysis of H1 2025 lawsuit data, ecommerce sites accounted for 69–77% of all H1 2025 ADA web-accessibility filings (see TestParty's ecommerce lawsuit trend analysis). B2B stores are not exempt from that filing pattern; large buyers and procurement teams include disabled users, and a portal that gates pricing behind login does not get a pass on WCAG. This guide walks through the Stencil-specific surface area and the B2B-specific patterns you have to audit before launch.

Stencil + Cornerstone — what you get by default

Cornerstone is BigCommerce's recommended default theme and the baseline that BigCommerce itself maintains. Stencil is the framework underneath it, documented at developer.bigcommerce.com/stencil-docs. Templates are Handlebars (.html partials with {{handlebars}} expressions), styles are SCSS, and behavior is shipped as ES modules bundled by the Stencil CLI. Cornerstone's product and category templates use <main>, <nav>, and <header> landmarks, ship a skip-to-content link, and label form controls. BigCommerce maintains an ADA / a11y FAQ at support.bigcommerce.com (Accessibility / ADA Compliance) that summarizes the platform's baseline.

The recurring gaps on default Cornerstone are narrower than on, say, custom Webflow builds, but they are real: focus indicators get weakened or removed on customized buttons, ajax cart-update toasts fire without an aria-live region attached, and the off-canvas mobile menu's focus management depends on whether you kept Cornerstone's original JS or replaced it. For background on the underlying patterns, see our guides on keyboard navigation and ARIA landmarks.

B2B-specific a11y patterns

These patterns are not visible on a logged-out storefront scan. Every one of them needs to be audited as the customer group that sees it.

• Gated pricing / customer-group rendering — BigCommerce lets you hide pricing per customer group, so a guest user may see a product page without any price displayed at all. If you simply remove the price node, screen-reader users can spend several minutes navigating a product page without ever being told that pricing requires authentication. Render an explicit, screen-reader-accessible message in place of the price (for example, “Sign in for pricing”), associated with the product title via aria-describedby.
• Bulk-order forms— Large quantity inputs arranged in a table (SKU, name, qty, subtotal) are the canonical B2B pattern. Each input cell needs a programmatic label that includes both the row (SKU/product) and the column (quantity). Use real <th> elements for row and column headers and aria-labelledby on each input to point at the row header id plus the column header id, so a screen reader announces “SKU 1024, Quantity, 0” rather than just “Quantity”.
• Quote-request flows— Multi-step quote forms typically reveal additional fields as the buyer makes selections. Wrap the dynamically-revealed region in an aria-live="polite" container so additions and removals are announced, and move keyboard focus to the new region when it appears so keyboard users do not have to tab from the top.
• Configurable products — Many B2B catalogs use BigCommerce product options to drive variant selection (size, finish, packaging, lead time). When you render those as radio groups, wrap each group in a <fieldset> with a <legend> so the option name is announced once for the whole group rather than repeated per radio.
• Large filterable catalog (faceted search) — Mid-market and B2B catalogs commonly ship hundreds of filter checkboxes split across a dozen facets. Group each facet in a <fieldset> with a <legend> so the facet name is associated with every checkbox in it. Announce updated result counts via a single aria-live="polite" region (“128 products match”) rather than letting the count silently re-render.

Stencil customization — typical a11y regressions

When developers extend Cornerstone for a client build, four regressions show up over and over:

• CSS that removes the focus outline without replacement — A designer asks for a cleaner-looking button, the dev adds outline: none, and keyboard users lose every focus indicator on the page.
• Custom dropdown menus written in vanilla JS — A bespoke account-menu or sort dropdown that does not implement the WAI-ARIA listbox / combobox pattern: no roles, no arrow-key handling, no Escape-to-close.
• Auto-rotating carousels without pause control — Hero banners that advance every five seconds and ignore both an explicit pause button and the user's prefers-reduced-motion preference.
• “Added to cart” modals that do not move focus — A confirmation overlay opens, focus stays on the original Add-to-Cart button, and a screen-reader user never hears that anything happened. See our guide on accessible modals for the correct focus-trap pattern.

The single highest-leverage fix is restoring a real focus indicator in your theme's SCSS. A minimal pattern that works on Stencil:

// Restore a real focus indicator on every interactive element.
// Use :focus-visible so mouse users don't see the ring, but
// keyboard users always do.
a,
button,
input,
select,
textarea,
[tabindex]:not([tabindex="-1"]) {
  &:focus-visible {
    outline: 2px solid currentColor;
    outline-offset: 2px;
  }
}

BigCommerce Stencil theme audit checklist

1. Scan the public storefront — Run an automated scan against the logged-out experience first; this is the baseline that anonymous shoppers and Google both see.
2. Scan each customer-group persona that sees different content — If wholesale buyers see different prices, a different catalog, or extra fields, re-run the scan logged in as a representative wholesale account.
3. Walk the B2B flows by keyboard — Tab through the quote-request form, the bulk-order table, and the account dashboard. Verify focus is visible at every step and never trapped.
4. Verify focus indicators across customized buttons — Many regressions land on the buttons most touched by designers: Add to Cart, Add to Quote, View Pricing.
5. Test faceted-search result announcements — Apply a filter; confirm a screen reader hears the updated result count rather than silence.
6. Test the “added to cart” flow with a screen reader — Confirmation should be announced; focus should land somewhere predictable; the modal (if any) should be a real, focus-trapping dialog.

Do not install an accessibility overlay app

The BigCommerce App Marketplace lists several overlay-style accessibility apps that promise to make your store WCAG-compliant by adding a single script tag. On April 22, 2025 the FTC approved a final consent order requiring overlay vendor accessiBe to pay $1 million for misrepresenting its automated product's ability to make websites WCAG-compliant (full text at the FTC press release). The legal and engineering consensus has not moved since: overlays cannot fix the DOM in a stable assistive-technology-readable way, they are increasingly cited as a barrier in pleadings, and the regulatory cost of marketing claims about them has gone up. See our full breakdown in why accessibility overlays fail. If you have one installed and a demand letter has arrived, follow the demand-letter response guide instead.

How SweepHound supports BigCommerce

SweepHound crawls your rendered BigCommerce storefront the way a real browser would, which means Stencil's server-rendered Handlebars output plus any client-side hydration both get scanned. On Growth and Agency plans, authenticated scanning lets you point the crawler at a customer-group-gated catalog so the report reflects what your wholesale buyers actually see, not just the public anonymous experience.

We run two open accessibility engines — axe-core and IBM Equal Access — against each page to get better coverage than either engine alone. Even so, we do not pretend automated scanning is exhaustive. Per Deque's Automated Accessibility Coverage Report, Deque reported automated tests identified 57.38% of issue instances by volume in its dataset — based on 2,000+ audits across 13,000+ pages and ~300K issues (see Deque's coverage report). What we automate honestly is detection of mechanical violations and deterministic, code-level fix suggestions you can apply via Stencil theme customization — pasted directly into the right Handlebars partial or SCSS file. The ambiguous findings ship as explanations a human still has to review.

If you want to see what that looks like against your own BigCommerce store, the free scan will produce a report in under ten minutes, and pricing covers what is included at each plan level — including when authenticated scanning for gated B2B catalogs is available. For background on the standards we measure against, the WCAG 2.2 checklist and the broader ecommerce accessibility playbook are good companions to this guide. Building on a different platform? See the sibling guides for WooCommerce and Magento, or start a free scan to see your real numbers.