Accessibility and SEO are the same body of work described in two vocabularies. Both depend on a page whose meaning survives without sight, without a mouse, and without running JavaScript — which is to say, both depend on how your DXP renders and structures markup.
Two readers arrive at every retail page. One is a shopper using a screen reader. One is a crawler deciding what the page is about. Neither can see your design. Neither can use your mouse. Both are reading structure and asking the same question: what is this, and what can I do here?
Teams run these as separate projects anyway — accessibility as a remediation line item, SEO as a growth channel — and pay twice for one architectural decision.
Start here, because most accessibility content in our industry gets this wrong, and a VP who repeats the wrong version in a board meeting gets corrected by counsel.
No US regulation requires a private retailer’s website to meet WCAG. The Department of Justice says so in its own words: in Guidance on Web Accessibility and the ADA (18 March 2022), it states that it “does not have a regulation setting out detailed standards” and that businesses “can currently choose how they will ensure” their online services are accessible.
Three things are true at once, and the distinction between them is the whole legal picture:
So the honest framing: your exposure is litigation and settlement risk under a general nondiscrimination statute, not a compliance deadline. That isn’t a lighter problem — it’s a less predictable one. No date to work toward, no safe harbor to certify against, which is precisely why the plaintiff’s bar is active here.
Which leaves a practical question rather than a legal one: what do you build to? WCAG 2.2 Level AA — the standard DOJ’s guidance points at, the one consent decrees are written against, and the one whose requirements double as SEO requirements.
WCAG 2.2 first became a W3C Recommendation on October 5, 2023, with an updated version published on December 12, 2024. It is backward-compatible: conforming to 2.2 also means conforming to 2.1 and 2.0.
Measured against WCAG 2.2 Level AA, and written as what the platform must make possible rather than what your team must remember.
Lay the two lists side by side and the overlap isn’t a coincidence — it’s the same requirement serving two readers.
Semantic structure satisfies 1.3.1 for a screen reader and tells a crawler what the page is about. Text alternatives satisfy 1.1.1 and feed image search. Descriptive headings support 2.4.6 and help search engines and answer engines interpret page sections. Reflow supports 1.4.10 and improves mobile usability, which also matters for SEO. Structured data isn’t a WCAG requirement, but it’s the same instinct: make meaning machine-readable instead of leaving it implied by layout.
The asymmetry is worth naming. Accessibility work almost always helps SEO. SEO work does not automatically help accessibility — you can stuff perfect schema onto a page that traps keyboard focus. So sequence accessibility first and collect the SEO benefit, rather than the reverse.
See accessibility and SEO handled in one workflow. Book a demo.
Client-side rendering. The single biggest shared failure. Content assembled in the browser arrives late for Core Web Vitals and unreliably for assistive technology.
Modal-heavy checkout. When checkout is an iframe or third-party overlay, you inherit someone else’s focus management, error handling and authentication — the exact surface where 3.3.7 and 3.3.8 now apply, on the page where abandonment costs most.
Infinite-scroll PLPs. Usually ship with no keyboard path to later products and no crawlable URL for page two. One pattern, both readers lost.
Accessibility overlay widgets. Worth being direct, because they’re sold hard to retail teams: a script that injects an accessibility toolbar does not fix the underlying markup. It leaves structural failures in place and has not reliably prevented litigation. Treat an overlay as a reporting tool at best, never as remediation.
Alt text as a content-team chore. A process that depends on a human writing 40,000 alt attributes is a process that produces 40,000 empty alt attributes.
Twelve questions worth asking a vendor, drawn from the two lists above — with space to record what the demo actually showed rather than what the deck claimed.
📋 Download the DXP accessibility and SEO evaluation checklist. Twelve questions, the WCAG 2.2 criterion each one maps to, and the follow-up that exposes a vague answer. (Gated asset — request it here.)
I’ll be precise here, because accessibility is an area where vendors routinely claim more than they can support — and because no platform can hand you compliance. Compliance is a legal conclusion about your whole site, reached through testing and human review. What a platform can do is make the right output the default and surface failures before launch rather than after.
Fastr Frontend does that four ways. Its accessibility toolkit enforces a checklist at design time — heading tags, keyboard navigation, tab and focus order, live text — surfacing violations while someone is still building, not in a post-launch audit. The ADA agent flags issues, recommends fixes and organizes tab order. Alt text generates automatically for every image with manual override, the only way the catalog-scale problem gets solved. And server-first rendering puts the structural work in the markup before either reader arrives — the same mechanism that keeps Core Web Vitals and page speed metrics healthy.
The GEO and AEO layer injects JSON-LD and screen-reader-only content summaries alongside each experience, so JavaScript-rendered content is readable by AI crawlers. One feature serving both readers — this piece’s whole argument in a single implementation detail.
One disclosure. Fastr’s toolkit is documented against WCAG 2.1 Level AA; this article recommends 2.2 AA. The delta is four AA criteria added in 2.2 — Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Accessible Authentication (3.3.8) — plus two at Level A. Ask us where we are on those rather than assuming. I’d rather tell you the gap than let you find it in an audit.
A platform that emits clean markup does not make a site accessible, and anyone selling you that is selling you a problem for later. Conformance is a property of your whole site at a moment in time — including third-party scripts, the PDFs in your size guides, the review widget, the video player you didn’t choose. A DXP governs the part it renders. That’s a large part and not the whole.
The second limit is testing. Automated checks catch only the measurable failures — contrast ratios, missing attributes. Criteria about meaning and sequence need a person, ideally one who uses assistive technology daily. Budget for that, or the dashboard stays green while the experience is broken.
And on headless architecture: it doesn’t help or hurt either requirement by itself. What matters is where rendering happens. Headless plus client-side rendering is the worst case for both readers; headless plus server rendering is among the best.
Your accessibility budget and your SEO budget fund the same work. One is framed as risk and one as growth, which is why they sit in different parts of the plan and get different levels of enthusiasm.
No deadline is coming for retailers. That isn’t good news — a deadline at least tells you what finished looks like. What you get instead is a page that either makes sense to a machine or doesn’t, read by two kinds of reader who can’t see it. One of them can sue you. The other can stop sending you traffic.
In the United States the ADA applies to retail websites — DOJ has held since 1996 that Title III reaches the web content of businesses open to the public, and enforces that through settlements. But DOJ has issued no regulation specifying a technical standard for private businesses, and states plainly in its March 2022 guidance that businesses “can currently choose how they will ensure” accessibility. So: a legal obligation of nondiscrimination, with no prescribed technical standard attached. The WCAG 2.1 AA mandate issued in April 2024 applies to state and local governments, not retailers. This is general information, not legal advice — talk to counsel about your own exposure.
Neither, by itself. The variable that matters is where rendering happens. A headless architecture that assembles pages in the browser delays content for crawlers and assistive technology alike. The same architecture rendering server-side performs well for both. Judge the rendering model, not the label.
WCAG 2.2 Level AA. AA is the level named in DOJ guidance, used in consent decrees and adopted by regulations elsewhere; AAA includes criteria impractical to meet sitewide. Target 2.2 over 2.1 because it’s backwards-compatible, and because the criteria it adds — minimum target size, accessible authentication — land on retail’s weakest surfaces.
Done in the markup, no — they usually help, because semantic HTML is lighter than the div-and-script constructions it replaces. Done as a client-side overlay, yes: an injected script adds JavaScript, delays rendering and degrades INP and LCP while leaving the underlying failures in place. The method determines the answer, not the goal.
Product with Offer for PDPs, since that supports product rich results closest to purchase; BreadcrumbList for category structure; Organization for business information. Other schema types can be useful where the content supports them. What matters more than the list is whether your platform keeps markup accurate as prices and inventory change — stale structured data is a liability, not an asset.