Salesforce publishes accessibility conformance reports for Education Cloud, Experience Cloud LWR, and Commerce, and those cover the platform. The institution still owns everything it configures: theme contrast, alt text, heading order, focus states, keyboard access through checkout, form labels, captions, gallery zoom, and the phone-width layout. This is the checklist ElevateActual runs on every storefront before launch.
Who Owns Accessibility on a Salesforce Storefront?
A continuing education director usually lands here: the accessibility policy names WCAG 2.2 AA, procurement received a conformance report from the vendor, the storefront on Salesforce Commerce is about to launch, and somebody asks whether it is accessible. The honest answer is that the report covers the platform, and the platform is not the storefront.
Salesforce publishes its accessibility conformance reports on a public index that, as of October 2026, lists reports for Education Cloud, Experience Cloud LWR, and Commerce. They say nothing about the colors your theme chose, the alt text on your course images, the heading order in a pasted description, or the custom component a developer added. That configured layer is the institution's. The storefront we build is what we call Commerce on Core: B2B or D2C Commerce on the Salesforce Platform with an LWR Experience Cloud storefront, connected to Education Cloud. On the storefronts we have built, every accessibility defect found at launch has been in the configured layer.
What Does Salesforce Cover and What Do You Configure?
Split the work by where the fix lives:
- Salesforce. Standard components, checkout framework, LWR runtime. Covered by the conformance reports; a shipped defect is a Salesforce case.
- Theme. Colors, fonts, spacing, focus styling, the site stylesheet. Owned by whoever manages the brand.
- Component. Any Lightning Web Component your partner or developer built. Owned by the developer.
- Content. Descriptions, images, embedded video, anything entered through the HTML editor or a Salesforce field. Owned by the unit staff who publish courses, so it needs a publishing checklist, not a one-time audit.
The Working Checklist
Each item names the WCAG 2.2 success criterion, the likely cause on an LWR storefront, and the durable fix.
Color Contrast in the Theme
Criterion 1.4.3 requires a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text; 1.4.11 requires 3 to 1 for interface components. The usual cause is a brand secondary color used for link text. The fix is in the theme: pick the brand's darker tint for text and borders, and set the approved pairs as theme tokens so unit staff cannot pick a lighter one.
Alt Text on Product Images
Criterion 1.1.1 requires a text alternative for images that carry meaning. Course tile images are usually decorative, so the alternative is empty and the course name carries the meaning. The durable fix is an alt text field on the product that staff fill at upload, with guidance on when to leave it empty.
Heading Order in the HTML Editor
Criterion 1.3.1 requires the structure a sighted user sees to be exposed in the markup. The page title is the only level one heading; description sections continue from the level below. Failures come from staff choosing a heading for its size. The fix is a publishing template with the levels in place, a guide that says to pick headings for structure, and a quarterly scan.
Focus States on Custom Components
Criterion 2.4.7 requires a visible focus indicator, and 2.4.11, new in WCAG 2.2, requires the focused element not to be hidden by a sticky header or cookie banner. Standard components ship with focus styling; custom components lose it when a developer resets outlines in CSS. The fix is a shared focus style in the site stylesheet applied to custom components by rule.
Keyboard Access to the Cart and Checkout
Criterion 2.1.1 requires every function to work from a keyboard. The test is a full purchase using only the keyboard, from category page to confirmation. Common failures are a cart drawer that cannot be closed without a mouse, a quantity control that ignores arrow keys, and a payment iframe that traps focus. Criterion 2.5.8, new in WCAG 2.2, asks for pointer targets of at least 24 by 24 CSS pixels.
Form Labels and Error Messages at Checkout
Criteria 3.3.1 and 3.3.2 require inputs to have labels and errors to be identified in text. Checkout forms fail when a placeholder stands in for a label or when the error text is not associated with its field. Criterion 3.3.7, new in WCAG 2.2, asks that information already entered not be requested again. Criterion 3.3.8 asks that signing in not depend on transcribing distorted characters.
Captions on Embedded Videos
Criterion 1.2.2 requires captions on prerecorded video with audio. Program videos come from the institution's video platform, and the captions are set there. The rule: no video is embedded without captions already published.
Hover-Only Zoom on Gallery Images
Criterion 1.4.13 covers content that appears on hover or focus. Hover zoom on a product gallery adds nothing for a course image. Turn it off. On the storefronts we have built, the gallery's zoom setting has not always survived a publish, so verify after each publish and, if it reappears, suppress it in the site stylesheet.
The Mobile Layout at Phone Width
Criterion 1.4.10 requires content to reflow without horizontal scrolling at 320 CSS pixels. Our working test is a phone width of 390 pixels: no horizontal page scroll, 16 pixel side gutters, no image or table wider than the column. Common causes are a fixed-width table pasted into a description, a hero image with a minimum width, and a banner sized for desktop.
Where Do You Fix Each Item, and How Do You Test It?
| Item | Where you fix it | How to test |
|---|---|---|
| Color contrast | Theme | Automated scan; manual check of button states and text over images |
| Alt text on product images | Content, with a product field to hold it | Screen reader pass over a category page and three detail pages |
| Heading order | Content, with a publishing template | Automated scan for skipped levels; headings list in a screen reader |
| Focus states | Component, via the site stylesheet | Keyboard-only pass with header and banner shown |
| Keyboard access to cart and checkout | Component and Salesforce | Complete a purchase with the keyboard only, including payment |
| Form labels and errors | Component and Salesforce | Submit checkout empty and with one invalid field; read the errors with a screen reader |
| Captions | Content, on the video platform | Play every embedded video with sound off |
| Hover-only zoom | Component and theme | Hover and tab onto a gallery image after each publish |
| Phone-width layout | Theme, and content for pasted tables | Open every template at 390 pixels; look for horizontal scroll |
How Do You Test Without a Specialist on Staff?
Four passes catch most of what the table lists, and none requires a specialist.
- Automated scan. Run a browser accessibility scanner over every page template, including each checkout step. It finds contrast, missing labels, and skipped headings. It does not find keyboard traps or bad alt text.
- Keyboard-only pass. Unplug the mouse and complete the guest learner UAT script. Note every place focus disappears or gets stuck.
- Screen reader pass. Use the screen reader built into the operating system and complete the same script with the display off.
- Phone width. Open every template on a real phone or a browser sized to 390 pixels.
Each pass takes an afternoon on a storefront the size we build for continuing education units. Run all four before launch and after any theme or component change. The Commerce Accelerator includes them in its launch checklist.
What Are the Follow-Up Checks?
A storefront that passed at launch drifts. The durable arrangement is checks with owners:
- Publishing checklist for unit staff: alt text decided, headings from the template, no pasted tables, video captioned. Owner: the unit's content lead.
- Post-publish check: gallery zoom still off, focus styles intact, contrast tokens unchanged. Owner: the Salesforce administrator.
- Release check after each Salesforce release: re-run the automated scan and the keyboard pass on checkout, and re-read the updated conformance reports. Owner: the administrator.
- Feedback path for a learner who meets a barrier, routed to a named person with a written response time. Owner: the unit director.
ElevateActual publishes its own accessibility statement for this website on the same basis, and the live demonstration storefronts go through the same four passes.
Questions We Hear
Is a Salesforce LWR storefront WCAG 2.2 AA compliant out of the box?
The platform layer is documented in Salesforce's accessibility conformance reports, which are the right starting point for procurement. The storefront as a whole is neither compliant nor non-compliant out of the box, because the theme, custom components, and content do not exist until the institution configures them.
Do we need a third-party accessibility audit before launch?
Policy at many public institutions requires one; where it does, schedule it so findings can be fixed before launch. Where it is optional, the four passes above, run by the institution's own testers with a written script, catch most of what an audit would find in the configured layer.
Who fixes an accessibility defect in a standard Salesforce component?
Salesforce does, through a support case, and the conformance report is the document to cite. In the meantime the storefront can often work around it in the theme or with a custom component that has the required behavior. Record the case number and workaround so the workaround is removed when the fix ships.
How do we keep unit staff from breaking heading order and alt text?
Give them fewer choices. A publishing template with headings already placed, a required alt text field on the product with a note on when to leave it empty, and a short checklist in the publishing instructions prevent most problems. Training alone fades; a template and a field hold.
Does the mobile check matter if most learners register from a laptop?
Yes. Phone-width reflow is a WCAG requirement regardless of traffic share, and learners who rely on screen magnification see a desktop page at a similar effective width. The check also catches real defects, such as pasted tables and oversized banners, that affect every screen size.