BigCommerce accessibility: what store owners need to know

BigCommerce occupies a particular position in the platform landscape: it has more built-in functionality than Shopify but more developer control than it is often given credit for. Its Stencil theme framework gives developers full control over frontend markup. Its Optimized One-Page Checkout (OOPC) is managed by BigCommerce directly, similar to how Shopify manages its checkout.

This creates a split accessibility responsibility. For your theme pages (product pages, category pages, cart page), you control the markup and can fix what is broken. For the OOPC, you are working within BigCommerce's constraints. Understanding this split is the first step to a realistic BigCommerce accessibility compliance strategy. For the full list of criteria your store needs to meet, see our WCAG 2.1 AA ecommerce checklist.

BigCommerce Stencil and the Cornerstone theme

Stencil is BigCommerce's current theme framework. Themes are built with Handlebars templates, SCSS and JavaScript. Cornerstone is the default official theme, similar to Shopify's Dawn. Most BigCommerce themes in the marketplace are either Cornerstone-based or built on Stencil independently.

What Cornerstone gets right

Cornerstone has received accessibility improvements over multiple versions. As of Cornerstone 6.x and later:

• The theme includes a skip navigation link that is visible on focus.
• Main navigation items at the top level are anchor elements (keyboard reachable via Tab).
• Product form inputs have associated labels.
• The theme uses semantic HTML5 elements for major page regions (header, main, nav, footer).

Where Cornerstone fails

Cornerstone's known accessibility failures in current versions:

• Dropdown navigation keyboard accessibility. Like most dropdown nav implementations, Cornerstone's navigation opens submenus on hover. Keyboard users cannot open submenus by pressing Enter or Space on a top-level nav item. Arrow key navigation between submenu items is not implemented.
• Product image gallery. Cornerstone uses a Slick Slider or similar carousel for the product image gallery. Carousel implementations require specific accessibility patterns: keyboard arrow key navigation, ARIA roles for the carousel container and slides, and live region announcements when slides change. Default Slick Slider implementations fail most of these requirements.
• Product option fields. Radio-button-style option sets (size selectors, color selectors) rendered as custom styled elements lose their native radio group semantics. The accessible name for the option group (the attribute label) is often presented as a <div> or <label> not properly associated with the group.
• Quantity stepper. The plus/minus quantity stepper buttons often have only icon content with no accessible names. A minus button showing only a "−" character with no aria-label leaves screen reader users with no context.
• Color contrast. Cornerstone's default palette uses grey text on white backgrounds in several locations (breadcrumbs, price labels, out-of-stock messages) that fail the 4.5:1 contrast ratio requirement.

BigCommerce Optimized One-Page Checkout accessibility

The OOPC is BigCommerce's hosted checkout, rendered by BigCommerce's servers. Merchants can customize its appearance (via the Checkout SDK or CSS overrides) but cannot modify its fundamental HTML structure. BigCommerce controls the underlying markup.

BigCommerce's accessibility commitments for OOPC

BigCommerce has stated that the OOPC is designed to meet WCAG 2.1 AA. The company publishes a VPAT for its platform. In practice, the OOPC performs better than most custom checkout implementations because it has been built and maintained by a company with accessibility resources.

Specific OOPC strengths: form fields have properly associated labels, error messages are linked to their fields, the shipping address country/state field cascade is accessible, required fields are marked programmatically and payment field integration (using embedded payment widgets) handles the constraint that payment card numbers are in separate iframes.

Known OOPC accessibility limitations

Despite BigCommerce's efforts, specific issues appear in OOPC testing:

• Focus management on step completion. The OOPC is a single-page checkout with accordion-style sections. When a user completes one section and the next section expands, focus management is inconsistent across browsers and screen readers.
• Shipping method selection. Shipping methods are presented as a list. The method descriptions (carrier name, estimated delivery, price) vary in how fully they are associated with the selection control.
• Payment method selection. Switching between payment methods (credit card, PayPal, Apple Pay) hides and shows different form sections. The panel display changes are not always announced via live regions.
• Embedded payment iframe accessibility. When a payment processor requires a card input rendered inside an iframe (Braintree, Stripe), the iframe must have an accessible title. BigCommerce's integrations with major payment processors generally handle this, but custom payment provider integrations may not.

Custom BigCommerce widgets and accessibility

BigCommerce's Page Builder allows merchants to add widgets to pages using a drag-and-drop interface. Widgets are small UI components (HTML, CSS, JavaScript) that can be created by BigCommerce, by third-party developers or by your own team.

Widget accessibility is entirely dependent on how each widget is built. Page Builder does not include accessibility checks. Common accessibility failures in BigCommerce widgets:

• Banner and hero widgets. Image overlays with text often fail color contrast requirements. The text color against the underlying image background may not meet 4.5:1 (regular text) or 3:1 (large text).
• Testimonial carousels. Carousel auto-play violates WCAG 2.2.2 (Pause, Stop, Hide) when it cannot be paused. Carousel navigation buttons typically lack accessible names.
• Promotional countdown timers. Timers that update every second create unnecessary screen reader noise if they use live regions with aria-live="assertive" instead of aria-live="off" with periodic updates.
• Video embed widgets. Embedded YouTube or Vimeo videos must have captions for audio content (WCAG 1.2.2). The video player controls must be keyboard accessible.

Script Manager and injected third-party script accessibility

BigCommerce's Script Manager is a built-in tool for injecting third-party scripts (analytics, chat widgets, review platforms, marketing tools) across your store. Every script injected via Script Manager is your accessibility responsibility.

The same patterns that cause accessibility problems on other platforms appear here: chat widgets with inaccessible launch buttons, review widgets with missing alt text on star ratings, popups and flyouts without focus trapping, and cookie consent banners with low-contrast text.

BigCommerce's Script Manager gives you more control over where scripts are injected (all pages, checkout only, order confirmation only) compared to manually editing theme files. Use this to limit inaccessible scripts to pages where they are actually needed rather than injecting them everywhere.

Product filtering on BigCommerce

BigCommerce's built-in faceted search and filtering uses an AJAX-based approach that updates the product grid without a full page reload.

Accessibility requirements for the filter panel:

• Filter attribute sections that collapse and expand need toggle buttons with aria-expanded and aria-controls.
• Individual filter options should be checkboxes (or rendered as elements with role="checkbox") with aria-checked reflecting the current selection state.
• Price range sliders need accessible labels and must be operable by keyboard (arrow keys to adjust the range).
• When filter selections update the product grid, the updated product count must be announced via a live region: <div aria-live="polite">42 products</div>.

Cornerstone's default filter implementation partially meets these requirements in recent versions. Check your specific theme version and test with a screen reader after applying filters.

How BigCommerce compares to Shopify on accessibility

Both platforms have similar accessibility profiles at the platform level. The key differences:

• Checkout control. BigCommerce gives merchants more ability to customize the checkout markup via the Checkout SDK than Shopify gives via Checkout Extensibility. More control means more responsibility.
• Theme flexibility. BigCommerce's Stencil framework gives developers more direct markup control than Shopify Liquid in some respects, making fixes easier to implement but also meaning more opportunities for mistakes.
• App/widget quality. Both app stores have accessibility quality problems. BigCommerce's smaller app ecosystem means fewer options but also a smaller pool of potentially inaccessible apps.
• Platform documentation. BigCommerce's developer documentation includes accessibility guidelines for theme development. Shopify's documentation has improved but historically has been thinner on accessibility specifics.

B2B edition accessibility considerations

BigCommerce B2B Edition (formerly Bundle B2B) adds business-to-business functionality: company accounts, buyer roles, purchase orders, quote requests and company address books. These features introduce additional UI components, each with their own accessibility requirements.

The B2B buyer portal (where B2B customers manage orders, quotes and company accounts) is a separate React application. Its accessibility is managed by BigCommerce but customers in the B2B context (company purchasers, procurement staff) may include people using assistive technology. WCAG compliance in B2B contexts is required under the same legal framework as B2C. For agencies and brands running multiple BigCommerce stores, our guide on multi-store compliance management covers how to scale accessibility across properties.

Steps to assess and fix BigCommerce accessibility

Start with automated scanning on your five highest-traffic page types: homepage, category page, product page, cart page and search results. Run axe-core or a browser extension like axe DevTools. Our guide on accessibility testing tools for ecommerce covers the full range of options. Note which failures are in your theme markup (fixable by you) versus injected by third-party scripts (may require contacting vendors).

For the OOPC, test with keyboard navigation and a screen reader. You cannot fix OOPC markup directly, but you can report issues to BigCommerce support and document your testing in your accessibility statement.

Prioritize fixes in this order:

• Checkout form accessibility (within OOPC or Checkout SDK customizations)
• Product option keyboard accessibility (size and color selectors)
• Navigation keyboard accessibility (dropdown menus)
• AJAX filter live region announcements
• Color contrast across all page types
• Third-party widget accessible names and focus management

Frequently asked questions

Is BigCommerce accessible out of the box?

BigCommerce's Cornerstone theme includes basic accessibility features but does not fully meet WCAG 2.1 AA. Common issues include missing form labels, inadequate focus indicators and heading hierarchy problems in customized themes.

Does BigCommerce checkout meet accessibility standards?

BigCommerce's optimized one-page checkout has invested in accessibility but still has gaps. Custom checkout implementations and third-party payment integrations often introduce additional accessibility failures.

How do BigCommerce apps affect accessibility?

Third-party apps on BigCommerce inject JavaScript and DOM elements that frequently lack accessibility testing. Review widgets, popups and chat tools are common sources of violations. Store owners are responsible for all content on their pages.