Salesforce Commerce Cloud Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-05-25
Salesforce B2C Commerce - still widely called Commerce Cloud, and Demandware before that - powers high-traffic storefronts for retail, fashion, and consumer brands, many of them selling into both the United States and the European Union. That dual exposure matters: these merchants face routine ADA Title III demand letters in the US and, since mid-2025, European Accessibility Act enforcement on the EU side, where an online store is explicitly an in-scope service. The platform does not make storefronts inaccessible on its own, but the Storefront Reference Architecture (SFRA) base cartridge is a starting point teams override heavily, and the accessibility of the final store depends on what the front-end team and merchandisers do on top of it. The failures cluster in the parts of a store that are unique to commerce. Product tiles and color/size swatches are frequently built as clickable divs or unlabeled buttons, so a screen reader user cannot tell which variant is selected or even that the control is a button. Faceted search refinements - the filter rails that are central to Commerce Cloud merchandising - often update results without announcing how many products remain, and the filter controls themselves lack state. The mini-cart and add-to-cart flow update silently, so a shopper who adds an item hears nothing. Quantity steppers are built from plus/minus icons with no accessible name. Page Designer, the drag-and-drop tool merchandisers use to build landing and campaign pages, lets non-developers assemble components that emit broken heading order, decorative images marked as content, and carousels with no keyboard support. And the multi-step checkout - the highest-stakes flow in the store - frequently ships placeholder-only labels, validation errors that are not tied to the field that failed, and a step indicator that does not communicate progress to assistive technology. This checklist targets those commerce-specific decisions, with the specific place in SFRA, ISML, or Page Designer to fix each one.
Common Accessibility Issues
Product tiles on category and search pages, and color/size swatches on product detail pages, are often built as div or span elements with click handlers, or as buttons with no accessible name and no selected state. A screen reader user cannot tell that a swatch is interactive, which color or size it represents, or which one is currently selected, so choosing a variant - the core action of shopping - is impossible without sight.
Render swatches as real <button> elements with an accessible name that includes the value (for example 'Color: Cobalt blue') and expose the selection with aria-pressed or, for a radiogroup pattern, role=radio with aria-checked. Make the whole product tile reachable by a single descriptive link (the product name) rather than a clickable div, and ensure price and key attributes are part of or adjacent to that link's context. Verify each swatch announces its name and selected state with a screen reader.
<div class="swatch" style="background:#0b3d91" onclick="selectColor('cobalt')"></div><button type="button" class="swatch" aria-pressed="true">
<span class="swatch-color" style="background:#0b3d91" aria-hidden="true"></span>
Color: Cobalt blue
</button>Commerce Cloud's faceted refinement rails (size, color, price, brand) typically re-render the product grid via Ajax when a filter is toggled. The number of results that changed, and the fact that the grid updated at all, is usually not announced. A screen reader user toggles a filter and hears nothing, with no idea whether 4 or 400 products now match, or whether the action did anything.
Add an aria-live='polite' status region that announces the updated result count after each refinement (for example '24 products match your filters'). Make each refinement control a real checkbox, link, or button with a clear accessible name and, where it is a toggle, a correct checked/pressed state. Manage focus sensibly so it is not lost when the grid re-renders. Ensure the 'X selected filters' / clear-all controls are keyboard reachable and labeled.
When a shopper clicks Add to Cart, SFRA updates the mini-cart count and often opens a flyout, but the change is usually silent to assistive technology. A screen reader user does not hear that the item was added, that the cart now has 3 items, or that a flyout appeared - so they cannot tell whether their action succeeded and may add the same item repeatedly.
Announce the result of adding to cart through an aria-live region ('Added Cobalt blue jacket, size M, to your cart. Cart now has 3 items.'). If a mini-cart flyout opens, give it appropriate dialog semantics and move focus to it (or to the confirmation) and return focus on close. Make sure the cart icon's accessible name reflects the current count so it is meaningful when a user navigates to it later.
Quantity controls on cart and product pages are commonly built as plus and minus icon buttons with no text and no accessible name, next to an input that may also lack a programmatic label. Screen reader users hear 'button button' with no idea what they do, and cannot reliably change quantities.
Give the increment and decrement controls accessible names ('Increase quantity', 'Decrease quantity') via visually hidden text or aria-label, and give the quantity input a real associated <label>. Ensure the control is operable from the keyboard and that the current value is announced when it changes. If the stepper is a custom widget, expose its value with appropriate ARIA rather than relying on the visual number alone.
<button class="qty-minus"><i class="icon-minus"></i></button>
<input type="text" value="1">
<button class="qty-plus"><i class="icon-plus"></i></button><button type="button" aria-label="Decrease quantity">-</button>
<label for="qty-123" class="sr-only">Quantity</label>
<input id="qty-123" type="number" inputmode="numeric" value="1" min="1">
<button type="button" aria-label="Increase quantity">+</button>Page Designer lets merchandisers assemble landing and campaign pages from drag-and-drop components without developer involvement. The result is often broken heading order (multiple H1s or decorative banner text marked as a heading), images placed as content with no alt text, hero text overlaid on photos at failing contrast, and carousel/banner components with no keyboard support or pause control for auto-rotation.
Build accessibility into the Page Designer component definitions developers ship, so merchandisers cannot easily produce broken output: expose an alt text attribute (required for informative images), constrain which heading levels a component can output, and ship carousels that already include keyboard controls, visible focus, and a pause/stop control with reduced-motion support. Give merchandisers a short authoring guide for the editable fields (alt text, heading choice, link text) and review high-traffic Page Designer pages with a screen reader.
The SFRA checkout - shipping, billing, payment - is frequently rendered with placeholder text instead of persistent visible labels, and validation errors shown in a way that is not programmatically tied to the field that failed. Placeholders vanish on focus and are not reliable labels; a screen reader user who hits an error hears that something is wrong but cannot navigate to the broken field or learn what to fix, on the single most important flow in the store.
Render a persistent visible <label> for every checkout field, associated with for/id, and stop relying on placeholders as labels. Set aria-invalid on failed fields and tie each error message to its field with aria-describedby. Put a checkout-level error summary in an aria-live region (or move focus to it) so it is announced. Override the relevant SFRA checkout ISML templates and the client-side validation to produce this markup.
<input type="text" name="shippingFirstName" placeholder="First name">
<div class="invalid-feedback">This field is required.</div><label for="shippingFirstName">First name <abbr title="required">*</abbr></label>
<input type="text" id="shippingFirstName" name="shippingFirstName"
required aria-required="true" aria-invalid="true"
aria-describedby="shippingFirstName-err">
<span id="shippingFirstName-err">Enter your first name.</span>Multi-step checkouts show a visual progress indicator (Shipping > Payment > Review > Place Order), but it is usually built as styled divs that convey the current step only by color or weight. Screen reader and keyboard users get no programmatic sense of which step they are on, how many remain, or that progress changed when they advance.
Expose the current step programmatically - for example mark the active step with aria-current='step', use an ordered list for the sequence so position is conveyed, and update an aria-live region or move focus to the new step's heading when the shopper advances. Ensure each step has a clear heading so users can orient with the headings list. Do not rely on color alone to indicate the active step.
Salesforce Commerce Cloud-Specific Tips
- Treat the SFRA base cartridge as a starting point, not a guarantee. Audit your overrides and custom cartridges - that is where commerce-specific accessibility regressions live (swatches, refinements, mini-cart, checkout).
- Build accessibility into reusable ISML templates and JS components (product tile, swatch, refinement, quantity stepper, form field) so every page that uses them inherits the fix instead of patching page by page.
- Constrain Page Designer component definitions so merchandisers cannot easily ship broken output: required alt text, limited heading levels, and carousels that already include keyboard support, a pause control, and reduced-motion handling.
- Add aria-live status regions for the Ajax-driven moments unique to commerce - refinement result counts, add-to-cart confirmation, mini-cart updates, and inline cart totals - because these are silent by default.
- Make the checkout the priority. Persistent labels, aria-describedby error association, an announced error summary, and a programmatic step indicator address the highest-risk, highest-conversion flow.
- If you sell into the EU, the storefront is an in-scope service under the European Accessibility Act; plan for an accessibility statement and keep test evidence. US storefronts should expect ADA Title III demand letters and prepare similarly.
- Test the full purchase journey - browse, filter, select a variant, add to cart, and complete checkout - with the keyboard only and with NVDA + Firefox and VoiceOver + Safari, the pairings most shoppers use.
Recommended Tools
axe DevTools
A free browser extension to scan rendered storefront pages - category, product, cart, checkout - for missing names, contrast, and structural issues with WCAG references; the pro version adds guided manual tests for swatches and steppers.
Pa11y / pa11y-ci
An open-source command-line accessibility tester that can be wired into the SFRA build/CI pipeline to catch regressions on key storefront templates before they ship.
WAVE Browser Extension
WebAIM's free extension annotates a rendered storefront page inline - useful for merchandisers reviewing Page Designer pages without reading code.
Commerce Cloud Storefront: Failure Pattern vs. Fix
| Plugin / Tool | Storefront Area | Common Failure | Fix (where in SFRA) |
|---|---|---|---|
| Variation swatches 4.1.2 | Clickable divs with no name or selected state | Real buttons/radios with value in the name + aria-pressed/aria-checked (product tile template) | |
| Faceted refinements 4.1.3 | Grid re-renders silently after filtering | aria-live result count + labeled checkbox/link controls (search/refinements template) | |
| Add-to-cart / mini-cart 4.1.3 | Cart updates with no announcement | aria-live confirmation + dialog semantics and focus management on flyout (cart JS) | |
| Checkout fields 3.3.1 | Placeholder-only labels, errors not tied to fields | Persistent labels + aria-describedby errors + announced summary (checkout ISML) | |
| Page Designer 1.3.1 | Broken headings, missing alt, inaccessible carousels | Constrain component definitions; required alt; accessible carousel component |
Frequently Asked Questions
Does Salesforce Commerce Cloud (SFRA) come accessible out of the box?
The Storefront Reference Architecture gives you a reasonable HTML and component baseline, but it is explicitly a reference to build on, and most teams override it heavily. The accessibility of your live store is determined by your custom cartridges, your JS components, and what merchandisers assemble in Page Designer - not by SFRA alone. The commerce-specific controls (variation swatches, faceted refinements, mini-cart, quantity steppers, checkout) are exactly where teams reintroduce barriers, so a real store needs its own audit regardless of the SFRA starting point.
What are the most common Commerce Cloud accessibility failures?
In order of impact: variation swatches and product tiles built as unlabeled clickable divs (a screen reader user cannot choose a color or size); checkout fields with placeholder-only labels and errors not tied to the field that failed; faceted refinements and add-to-cart updates that change the page silently with no aria-live announcement; icon-only quantity steppers with no accessible name; and Page Designer pages with broken heading order, missing alt text, and inaccessible carousels. These map to WCAG 4.1.2, 3.3.1, 4.1.3, 1.1.1, and 1.3.1 respectively.
How do I make Page Designer pages accessible when merchandisers build them?
Push the fix into the component definitions developers ship rather than relying on merchandiser discipline. Make alt text a required attribute on image components, constrain which heading levels a component can emit so the outline stays valid, and ship carousel/banner components that already include keyboard operation, visible focus, a pause/stop control, and reduced-motion handling. Then give merchandisers a short guide for the fields they do control (alt text, heading choice, descriptive link text) and review high-traffic campaign pages with a screen reader before they go live.
Does the EU Accessibility Act apply to my Commerce Cloud store?
If you sell to consumers in the EU, yes - e-commerce is named as an in-scope service under the European Accessibility Act, whose obligations took effect in June 2025 and are now being enforced by member-state regulators against WCAG 2.1 AA via EN 301 549. US-facing stores face a parallel risk under ADA Title III, where retail demand letters are routine. Either way, plan for an accessibility statement and keep evidence of what you tested. This is general information, not legal advice; confirm your obligations with qualified counsel for your markets.
How should I test a Commerce Cloud storefront for accessibility?
Test by journey, not just by page. Walk the full path - browse a category, apply filters, open a product, choose a color and size, change quantity, add to cart, open the mini-cart, and complete checkout - first with the keyboard only, confirming focus is always visible and nothing is unreachable, then with a screen reader (NVDA + Firefox and VoiceOver + Safari). Run axe DevTools on each template type and wire Pa11y into CI to catch regressions. The commerce-specific moments (swatch selection, silent Ajax updates, checkout errors) are where manual testing finds what scanners miss.
Further Reading
- Accessible Ecommerce Checkout Guide
- Product Variant Swatches Screen Reader Accessibility
- Shopify Store Accessibility Guide
- Accessible Forms Guide
- How Much Does Ada Lawsuit Cost
- What Is A Vpat Plain English Guide
Other CMS Checklists
- Shopify Accessibility Checklist
- Magento Accessibility Checklist
- Bigcommerce Accessibility Checklist
- Adobe-experience-manager Accessibility Checklist
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.