# AccessComply — Full Article Corpus
Source: https://accesscomply.com
Generated: 2026-09-12T19:52:51.629Z
AccessComply runs speed, findability (SEO) and WCAG-mapped
accessibility checks on discoverable Shopify storefront pages and prepares
eligible merchant-approved source or content changes through guarded Shopify
paths. SEO and speed coverage is intentionally scoped; accessibility
automation covers only part of accessibility and does not establish legal or
technical conformance. This
corpus contains educational articles from accesscomply.com; legal facts,
statistics, vendor details, and prices should be verified against current
primary sources before they are cited.
---
## 5 Accessibility Risk Scenarios Shopify Merchants Should Understand
URL: https://accesscomply.com/blog/5-shopify-stores-sued-ada-accessibility
Excerpt: Five clearly labeled, illustrative storefront scenarios that show how common accessibility barriers affect customers and what merchants can inspect first.
## Why These Scenarios Matter
The U.S. Department of Justice says inaccessible web content can deny people with disabilities equal access and identifies barriers including poor contrast, missing image text alternatives, inaccessible forms, missing captions, and mouse-only navigation. It also cautions that a clean automated report does not necessarily mean a website is accessible and recommends pairing automated checks with manual review.
The five scenarios below are **illustrative composites, not reports of named lawsuits or settlements**. They are intended to help Shopify merchants recognize customer-impacting patterns. They are not legal advice, proof of liability, or a prediction that a particular store will receive a claim.
## Scenario 1: Product Discovery Without Useful Image Text
A screen-reader user opens a collection page, but product images have missing or generic text alternatives. The search control has no programmatic label, and repeated navigation has no skip link.
**What to inspect:** meaningful text alternatives for informative images, labels for search and filter controls, logical headings, and a keyboard-usable way to bypass repeated navigation. Automated checks can identify some of these patterns, but merchants must review whether descriptions are accurate and useful.
## Scenario 2: Forms That Do Not Explain Errors
A shopper reaches an account, newsletter, or cart form. Placeholder text is the only label, validation errors appear only visually, and focus does not move to or announce the problem.
**What to inspect:** persistent labels, clear instructions, programmatic error associations, status announcements, visible focus, and a complete keyboard flow. Checkout surfaces controlled by Shopify or another app may require the relevant platform or vendor to remediate them.
## Scenario 3: Product Options and Galleries That Trap the Keyboard
A custom swatch, size selector, or gallery responds to pointer clicks but is built from non-interactive elements. A keyboard user cannot select a variant or escape a carousel.
**What to inspect:** native buttons, links, radios, or selects where possible; correct names, states, and roles; predictable arrow-key behavior where a composite widget requires it; and no keyboard traps. Complex interaction usually needs manual keyboard and assistive-technology testing.
## Scenario 4: Focus and Contrast Regressions After a Theme Change
A theme update removes visible focus styles and introduces low-contrast text. The storefront still looks polished with a mouse, but keyboard and low-vision customers lose critical cues.
**What to inspect:** visible focus indicators, text and control contrast, zoom and reflow, and monitoring after theme or app changes. A scan can flag many CSS-level problems, but it cannot evaluate every state or customer journey.
## Scenario 5: A Widget Is Present but Core Content Remains Inaccessible
A storefront adds a runtime accessibility widget, while product videos still lack captions, product information remains image-only, and underlying controls remain unusable by keyboard.
**What to inspect:** the actual shopping experience with the widget both available and unavailable. Do not advertise guaranteed ADA or WCAG compliance based solely on installing any automated product. Fix source content and interaction barriers, test manually, and describe the current accessibility status accurately.
## The Patterns Across These Scenarios
Across these scenarios, common themes emerge:
**The violations that appear most frequently:**
1. Missing alt text on product images
2. Unlabeled or inaccessible form inputs
3. Missing keyboard accessibility or keyboard traps
4. Insufficient color contrast
5. No skip navigation
**A stronger operating practice:**
- Give customers an accessible way to report barriers and respond promptly
- Combine automated scanning with manual keyboard and assistive-technology testing
- Prioritize core purchase journeys and fixes to the underlying source or content
- Keep an accurate accessibility statement and remediation record without claiming guaranteed compliance
## Your Store's Risk
[Run a free scan](/) with AccessComply to get an automated finding count, severity breakdown, and finding-priority signal scoped to the discoverable storefront pages and rules tested. Treat the result as a starting point: automation cannot evaluate every WCAG success criterion, customer journey, third-party surface, document, or legal requirement.
The installed Free plan includes three eligible deterministic fixes per rolling 30 days. [Paid plans](/pricing) add broader fix entitlements, monitoring, and reports. AccessComply does not guarantee ADA, EAA, or WCAG compliance, prevent claims, or replace a qualified manual audit or legal advice.
Primary guidance: [U.S. Department of Justice guidance on web accessibility and the ADA](https://www.ada.gov/resources/web-guidance/).
## Further Reading
- [ADA Lawsuits Against Ecommerce Stores: 2025–2026 Statistics and How to Protect Your Business](/blog/ada-lawsuits-ecommerce)
- [ADA Demand Letter Response: Template + 72-Hour Action Plan](/blog/ada-demand-letter-response-template)
- [Why Accessibility Overlay Widgets Don't Work (And What Actually Does)](/blog/accessibility-overlay-widgets-dont-work)
---
## AccessComply vs accessiBe: A Shopify Due-Diligence Guide
URL: https://accesscomply.com/blog/accesscomply-vs-accessibe-comparison
Excerpt: Compare AccessComply’s merchant-approved Shopify remediation workflow with accessiBe’s current offering using evidence, current vendor documentation, and a live test—not stale feature claims.
An honest AccessComply-versus-accessiBe comparison starts by separating three things: automated scanning, the mechanism used to change a storefront, and any human or professional service included in the plan.
Competitor pricing, product architecture, services, ratings, and plan limits change. This article describes AccessComply’s current workflow and links the primary FTC source; verify accessiBe’s current offering directly before buying. For the FTC order in detail — what it establishes, what it does not, and how to evaluate any replacement — see [evaluating an accessiBe alternative for Shopify after the FTC order](/blog/accessibe-alternative-shopify-after-ftc-fine/).
## The FTC fact that belongs in this comparison
In 2025 the FTC approved a final order requiring accessiBe to pay $1 million and restricting certain unsupported automated-WCAG-conformance claims. Read the [FTC announcement and final-order summary](https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million) rather than relying on a vendor’s paraphrase.
The order does not prove that another product makes a store compliant. Its durable lesson is narrower: demand competent evidence for conformance claims and reject promises that automation alone settles the question.
## What AccessComply can demonstrate
AccessComply scans discoverable storefront pages within the reported page scope and crawler limits. It reports eligible automated-rule findings. When a safely source-mapped candidate is available, the merchant reviews an exact candidate or scoped approval before a supported theme or Shopify content write.
Supported writes create restore records and run a post-change check. Only a confirmed finding is marked resolved. A failed, stale, unsupported, third-party, or judgment-heavy case remains for review rather than being counted as a successful fix.
This workflow does not amount to a full WCAG audit and does not establish legal compliance.
## Questions to ask accessiBe and AccessComply
| Due-diligence question | AccessComply’s documented answer | What to verify with accessiBe |
|---|---|---|
| What pages are scanned? | Discoverable public storefront pages within plan, crawler, and time limits | Current scan scope and exclusions |
| Where does a change live? | Eligible approved writes can affect a supported theme file or Shopify resource | Which changes are source, runtime, or performed as a service |
| Is a merchant approval required? | Yes, before supported writes | Current approval and change-control workflow |
| What is checked afterward? | The applicable automated rule is checked after the supported write | Verification scope and failure handling |
| Is there a restore path? | Supported writes create restore records; restore requires merchant confirmation | Current rollback or removal behavior |
| What remains manual? | Unsupported, risky, third-party, and judgment-heavy work | Manual audit, remediation, and service boundaries |
| What happens on uninstall? | Theme writes stay only in the modified theme; content changes remain; extension behavior stops | Current product behavior and data lifecycle |
| What does it cost? | [Current AccessComply pricing](/pricing) | Current vendor listing, quote, and contract |
## Source changes still have limits
A source change is not automatically correct, permanent, or complete. Theme updates can overwrite it. A different published theme does not inherit it. Third-party apps may reintroduce the barrier. A post-change automated check verifies only the specific rule and state reached by that check.
That is why a production workflow needs scoped approval, expected-source checks, restore records, post-change verification, and manual QA—not a claim that source code alone is “lawsuit proof.”
## Current AccessComply plans
- Free: three app scans per calendar month and three eligible deterministic fixes per rolling 30 days.
- Starter: $29 per month, unlimited deterministic fixes, quarterly monitoring, and remediation reports.
- Shield: $79 per month, AI-assisted alt-text and ARIA candidates plus monthly monitoring by default.
- Citadel: $199 per month, daily monitoring by default.
Optional annual Shopify billing is available for paid plans. See [pricing](/pricing) for the current annual amounts.
## Decision rule
Choose based on demonstrated behavior in a development theme, clearly documented exclusions, manual-service scope, current contract terms, and the quality of the evidence you can keep. Do not choose based on a promise of compliance or protection from a claim.
You can [run an AccessComply automated scan](/) without signup, then confirm the important results with manual keyboard and assistive-technology testing.
---
## Evaluating an accessiBe Alternative for Shopify After the FTC Order
URL: https://accesscomply.com/blog/accessibe-alternative-shopify-after-ftc-fine
Excerpt: What the FTC’s 2025 accessiBe order actually says, what it does not prove, and how Shopify merchants can evaluate scanning, source changes, runtime behavior, human services, and evidence.
The strongest reason to reconsider any automated accessibility product is not a dramatic headline. It is a mismatch between the claim and the evidence.
## What the FTC source says
The FTC approved a final order in 2025 requiring accessiBe to pay $1 million and restricting certain unsupported claims that its automated product could make websites WCAG compliant. The agency also addressed the presentation of paid endorsements.
Read the [FTC announcement](https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million) and the linked docket for the exact language.
The order is evidence about the specified accessiBe claims and conduct. It is not proof that every runtime tool fails, that every source change succeeds, or that another app guarantees compliance.
## What a credible alternative should show
An alternative vendor should be able to demonstrate—not merely assert—the following:
1. The pages, components, and states included in the scan.
2. The automated rules and standards mappings used.
3. Whether each proposed change affects theme source, Shopify content, runtime behavior, or a managed-service deliverable.
4. The merchant approval boundary before production writes.
5. How stale source, theme changes, and cross-store isolation are handled.
6. What is checked after a change and what “verified” means.
7. The restore path and risk of overwriting later merchant edits.
8. The findings that require manual or specialist work.
9. What stops, stays, or is deleted after uninstall or cancellation.
10. Current pricing, limits, service levels, and contract exclusions.
## How AccessComply fits that framework
AccessComply scans discoverable public storefront routes within the reported scope and crawler safety limits. It can produce candidates for eligible automated-rule findings when the underlying source is mapped safely. The merchant must approve the exact candidate or scoped operation before a supported write.
Supported writes create restore records and run a post-change check. Only confirmed findings are marked resolved. Unsupported, unresolved, third-party, and judgment-heavy cases remain for manual review.
This is a remediation workflow, not a full WCAG audit, legal opinion, or promise that every issue can be detected or fixed.
## Theme persistence is scoped, not absolute
An approved theme edit remains in the specific theme that was modified until a later edit, update, or replacement overwrites it. It does not automatically transfer to a newly published theme. Supported Shopify content changes remain in the underlying resource. Optional Theme App Extension behavior stops when the app or embed is removed.
Restoring an older value also requires merchant confirmation because it can overwrite later work. “Reversible” should never mean unattended rollback.
## Current AccessComply plan outline
- Free: three app scans per calendar month and three eligible deterministic fixes per rolling 30 days.
- Starter: $29 per month, unlimited deterministic fixes, quarterly monitoring, and remediation reports.
- Shield: $79 per month, AI-assisted alt-text and ARIA candidates plus monthly monitoring by default.
- Citadel: $199 per month, daily monitoring by default.
Paid plans also support optional annual Shopify billing. Use the [current pricing page](/pricing), not an old comparison article, as the source of truth.
## A safe migration sequence
1. Capture the current storefront and theme version.
2. Run automated scans with and without any optional runtime control where feasible.
3. Test representative purchase paths manually with keyboard and assistive technology.
4. Remediate eligible first-party source and content issues in a development theme.
5. Obtain specialist help for third-party, document, media, and complex interaction issues.
6. Verify the served storefront, not only the code diff.
7. Decide whether any runtime control remains useful as a supplement.
8. Keep evidence and continue monitoring after content or theme changes.
The decision is not “overlay bad, source good.” It is whether the merchant can understand, approve, test, and maintain the actual storefront outcome.
If you are weighing the two products side by side, the [AccessComply vs accessiBe comparison](/blog/accesscomply-vs-accessibe-comparison/) walks through write paths, scan scope, approvals, verification and manual-service boundaries in detail.
---
## Accessibility Overlays vs Source Remediation: What Shopify Merchants Should Verify
URL: https://accesscomply.com/blog/accessibility-overlay-widgets-dont-work
Excerpt: Runtime controls and source remediation use different mechanisms. Learn what each can and cannot prove, how to test the storefront, and why neither guarantees compliance.
“Overlay” and “source-code fix” describe mechanisms, not guaranteed outcomes. A runtime script can provide useful user controls or modify the rendered page. A source change can improve the markup or styles Shopify serves. Either can still miss important barriers.
Accessibility depends on the complete user experience, including content, states, third-party apps, checkout, media, documents, and assistive-technology behavior. No automated architecture establishes conformance or legal compliance by itself.
## What a runtime accessibility layer does
A runtime layer loads JavaScript in the visitor’s browser and can add controls or modify the rendered document. Its exact behavior varies by product. Merchants should confirm:
- what happens before and after the script loads;
- which changes are user-selected versus automatic;
- behavior when the script is blocked or unavailable;
- interaction with theme and third-party JavaScript;
- data collection and privacy terms;
- what stops when the service is removed.
Display controls can be a useful supplement for some visitors. They are not a substitute for testing and remediating underlying barriers.
## What source remediation does
Source remediation changes the Shopify theme or another supported resource so the served output can change without relying on a separate accessibility script. That has important benefits, but also limits:
- a theme edit stays only in the modified theme;
- theme updates or later edits can overwrite it;
- a different theme does not inherit it automatically;
- a change can fix one state and break another;
- third-party output may not be writable by the merchant’s app;
- code changes still require manual and assistive-technology testing.
## The relevant FTC record
In 2025 the FTC approved a final order requiring accessiBe to pay $1 million and restricting certain unsupported automated-WCAG-conformance claims. The [FTC announcement](https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million) is the primary source.
The durable lesson is to demand evidence and reject categorical conformance claims. The order does not prove that all runtime tools are identical or that source-remediation tools guarantee a legal outcome.
## A practical Shopify test plan
1. Choose representative product, collection, cart, account, and content journeys.
2. Record the theme version, third-party apps, viewport, and user state.
3. Run automated checks and retain their exact page scope.
4. Test keyboard order, visible focus, dialogs, error handling, and announcements manually.
5. Use relevant assistive technology on the critical purchase path.
6. Inspect source, computed output, and runtime changes separately.
7. Confirm what the tool could not reach, detect, change, or verify.
8. Repeat after theme publication, app changes, and major content updates.
## How AccessComply approaches changes
AccessComply scans eligible automated rules on discoverable public storefront pages within crawler limits. For a safely source-mapped candidate, the merchant approves the exact candidate or scoped operation before a supported write.
Supported writes create restore records and run a post-change check. Only confirmed findings are marked resolved. Unsupported, stale, risky, third-party, and judgment-heavy work remains for manual review. Restore requires merchant confirmation because an older value can overwrite later edits.
That workflow is intentionally scoped. It is not a complete audit or a compliance guarantee.
Start with a [free automated scan](/), then validate the most important journeys manually.
---
## ADA Website Demand Letter: A Shopify Evidence Checklist (Not a Legal Template)
URL: https://accesscomply.com/blog/ada-demand-letter-response-template
Excerpt: A careful intake and evidence-preservation checklist for Shopify merchants. Preserve the letter, notify the right people, obtain qualified counsel, and verify technical facts without making admissions.
If a Shopify merchant receives a website accessibility demand letter, the safest first move is not to paste a generic response from a blog. Preserve the communication, notify the appropriate internal and insurance contacts, and obtain qualified legal advice promptly.
Do not send this article, adapt its wording as a legal response, contact the claimant, admit facts, promise an outcome, or miss a deadline based on marketing content. Counsel should advise on the response and preservation plan.
## Immediate intake checklist
Preserve, without altering:
- the complete letter, envelope, email, attachments, and headers;
- the date, time, delivery method, and person who received it;
- any complaint, summons, deadline, reference number, or linked report;
- relevant insurance policies and notice provisions;
- the storefront URL, published theme ID, theme version, and app inventory;
- existing accessibility statements, audits, tickets, scan reports, and remediation records;
- relevant deployment and change history;
- screenshots or recordings counsel asks you to capture.
Notify the owner responsible for legal matters and follow the business’s incident and insurance procedures. Let counsel determine whom to contact, what to preserve, and how to communicate.
## Technical facts to gather for counsel
Create a factual packet without declaring the claim valid or invalid:
1. URLs and UI states identified in the letter.
2. Whether each state is public, authenticated, checkout, or third-party controlled.
3. The published theme and relevant theme files at the referenced time, if available.
4. App blocks, scripts, content sources, and vendors involved.
5. Reproduction steps, browser, viewport, and assistive-technology context when supplied.
6. Results of a dated automated check, including tool, rule version, and pages not reached.
7. Results of qualified manual testing when commissioned.
8. Changes made, approver, before-and-after evidence, and post-change verification.
9. Items still unresolved and the owner assigned to each.
An automated scan can help reproduce some technical facts. It cannot determine liability, standing, damages, settlement value, or legal compliance.
## Controlled remediation
Coordinate the evidence-preservation process with counsel. Then address verified barriers through normal change control:
- prioritize issues that block product discovery, forms, cart, account, and checkout tasks;
- work in a development theme where appropriate;
- review the exact or scoped change before writing;
- prevent stale candidates from overwriting newer merchant work;
- record the prior value for supported writes;
- verify the actual rendered result;
- manually test important keyboard and assistive-technology flows;
- document limitations and unresolved third-party work accurately.
Do not claim that a newly installed app proves the historical storefront was accessible or that a clean automated result resolves the legal matter.
## What AccessComply can provide
AccessComply can report automated-rule findings within a dated scan scope, retain scan and fix history, propose eligible merchant-approved changes, create restore records for supported writes, and run targeted post-change checks.
It does not provide a complete manual audit, legal conclusion, expert-witness opinion, settlement analysis, or guarantee against another complaint.
## Questions for counsel and providers
- What deadlines and preservation duties apply?
- Should an insurer, platform, vendor, or other party receive notice?
- What communication is appropriate, and who should send it?
- Which technical allegations require independent evaluation?
- What evidence should be collected before any code or content changes?
- What remediation scope and retesting are appropriate?
- What can be shared, and what should remain privileged or confidential?
If you need a cost worksheet, use the [accessibility response budget planner](/tools/lawsuit-cost-calculator) only to total estimates you enter. It does not estimate settlements, damages, claim probability, or legal outcomes.
---
## ADA Website Accessibility Risk for Ecommerce: A Practical Shopify Guide
URL: https://accesscomply.com/blog/ada-lawsuits-ecommerce
Excerpt: Inaccessible storefronts can prevent disabled customers from shopping and can create legal risk. Learn what the DOJ actually says, what automated scans can prove, and how to run a defensible accessibility program.
An inaccessible storefront can stop a customer from finding a product, understanding a form, or completing a purchase. It can also create complaint and litigation risk. The useful response is not a fear-based score or an unsupported settlement estimate; it is a repeatable program that finds barriers, fixes them, verifies the result, and gives customers a way to report what automation missed.
The US Department of Justice says Title III applies to the goods and services that businesses open to the public provide online. It also says there is no detailed Title III web technical regulation, and that WCAG is helpful technical guidance. Legal scope can depend on the facts and jurisdiction.
## Start with access, not a legal-risk number
No scanner can determine whether a merchant is legally compliant, predict whether a claim will be filed, or calculate a reliable lawsuit probability. AccessComply therefore reports detected technical issues, affected public pages, WCAG mappings, and remediation evidence. Those outputs help an accessibility program; they are not legal opinions or certifications.
For Shopify merchants, the most important question is concrete: can disabled customers complete the same core tasks as other customers?
- Discover and compare products.
- Understand product information, price, variants, and availability.
- Add, update, and remove cart items.
- Sign in or continue as a guest.
- Understand validation errors and recover from them.
- Complete checkout with a keyboard and assistive technology.
- Contact support when a barrier blocks the journey.
## Common storefront barriers
DOJ web guidance highlights issues such as poor color contrast, information conveyed by color alone, missing text alternatives, inaccessible forms, weak heading structure, and keyboard barriers. Shopify themes and third-party apps can introduce these problems in navigation, product cards, variant controls, dialogs, carts, and marketing forms.
Automated rules are useful for repeatable checks such as some accessible-name, contrast, ARIA, form-label, and markup failures. They cannot reliably judge every user journey, content decision, screen-reader announcement, keyboard interaction, caption, PDF, authenticated state, or third-party checkout behavior.
## A defensible Shopify accessibility program
### 1. Define the scope
List the page templates and high-value flows that customers actually use: home, collections, product details, search, account, cart, checkout, support, and key landing pages. Include installed widgets and apps rather than testing the base theme alone.
### 2. Establish an automated baseline
Run a crawl of the public states that automation can reach. Treat the result as a backlog of detected findings, not a pass/fail legal verdict. Record the date, viewport, URLs, rule engine, and any pages that could not be tested.
### 3. Test essential flows manually
Use keyboard-only navigation, browser zoom, visible focus, error recovery, and at least representative screen-reader testing. Check mobile interactions and dynamic components such as drawers, modals, predictive search, variant selectors, and app widgets.
### 4. Remediate at the right layer
Fix first-party theme problems in Liquid, HTML, CSS, and JavaScript when source mapping is safe. Use Shopify settings for content-owned issues such as product image descriptions. Escalate third-party app, hosted checkout, caption, document, and design-judgment issues to the party that controls them.
AccessComply backs up eligible theme files before a merchant-approved source change, records the diff, and runs post-fix verification. A detected issue that cannot be mapped safely remains a manual-review item.
### 5. Monitor and invite feedback
Theme releases, content changes, and third-party app updates can introduce new barriers. Re-scan on an appropriate cadence, repeat manual testing for important releases, and publish a feedback channel that a customer can use when a problem is not captured by automation.
## What good evidence looks like
Useful records describe what actually happened without overstating the conclusion:
- Scan scope, date, tool, completed pages, and limitations.
- Detected findings and severity at that point in time.
- Source changes, backups, approvals, and verification results.
- Manual tests performed and assistive technologies used.
- Known limitations, owners, and target remediation dates.
- Customer feedback and the response taken.
An accessibility statement can summarize the current scope, target, assessment method, known limitations, and contact channel. It should be merchant-reviewed and updated when the underlying facts change.
## If you receive a demand letter or complaint
Do not let an automated product make legal decisions for you. Preserve the letter and relevant records, notify the appropriate internal owner or insurer, and consult qualified counsel promptly. Counsel can determine deadlines, preservation duties, jurisdiction-specific issues, and the appropriate response.
In parallel, verify the reported barriers without changing or destroying relevant evidence. Prioritize customer-blocking issues, document remediation accurately, and keep counsel informed. A new scan can help reproduce technical facts, but it does not validate the legal allegations or replace an independent manual evaluation.
## State and international rules are separate analyses
Federal ADA guidance is not the only possible source of obligations. State laws and remedies vary, and cross-border ecommerce can involve other regimes. The [European Accessibility Act guide](/blog/eaa-enforcement-deadline-shopify) addresses a separate EU framework with its own scope, exemptions, national implementation, and service-information requirements.
## The bottom line
The strongest commercial strategy is also the most honest one: make essential shopping tasks more usable, fix verified barriers, retain accurate evidence, and keep improving as the storefront changes. Start with a [free public scan](/), then combine automated remediation with manual testing appropriate to the store's risk and complexity.
## Further reading
- [ADA Demand Letter Response: A Practical Action Plan](/blog/ada-demand-letter-response-template)
- [Shopify Accessibility: Complete Implementation Guide](/blog/shopify-accessibility-complete-guide)
- [Shopify Accessibility Statement Template](/blog/shopify-accessibility-statement-template-guide)
---
## Andrews v Blick Art Materials: A District-Court Online-Service Decision
URL: https://accesscomply.com/blog/andrews-v-blick-shopify-lessons
Excerpt: In 2017 the Eastern District of New York denied Blick\
Andrews v Blick Art Materials, LLC is a 2017 Eastern District of New York decision denying a motion to dismiss. The court accepted a broad Title III theory on the pleadings, but the decision is not controlling Second Circuit authority and should not be converted into a universal coverage rule for online-only Shopify stores.
"This Court holds that... the term \'place of public accommodation\' must be construed liberally to afford the people with disabilities equal enjoyment of the services that places of public accommodation provide... Considering the broader purposes of the ADA, websites of \'businesses that sell goods to the public should fall within the ADA\'s intended ambit." — Andrews v Blick Art Materials, LLC, 268 F. Supp. 3d 381 (E.D.N.Y. 2017), Judge Jack B. Weinstein
## The facts
Andrew Andrews is a blind New York resident who uses screen-reader software to navigate the web. In 2016 he attempted to access dickblick.com — the website of Blick Art Materials, LLC, a privately-held art-supply retailer. Blick operates physical stores in some cities and a nationwide ecommerce website. Andrews alleged that the website was inaccessible to screen-reader users in multiple ways, including missing alt text on product images, missing form labels on the cart and checkout flow, and inaccessible navigation.
Andrews sued in the Eastern District of New York, alleging violations of:
- Title III of the Americans with Disabilities Act (federal).
- The New York State Human Rights Law.
- The New York City Human Rights Law.
Blick moved to dismiss the ADA claim on the theory that ADA Title III is limited to physical places of public accommodation, and the website is not a physical place. (The same theory the Eleventh Circuit would adopt four years later in Gil v Winn-Dixie.)
## The ruling
Judge Jack B. Weinstein denied the motion to dismiss in a 2017 opinion. The reasoning included three themes:
### 1. The ADA is a remedial statute that should be construed liberally
The court emphasized that the ADA was enacted to ensure equal access for people with disabilities. Construing "place of public accommodation" narrowly to exclude commerce conducted online — where an ever-growing share of public commerce occurs — would defeat the statute\'s remedial purpose.
### 2. The statutory list of categories is illustrative, not exhaustive
The 12 categories in 42 U.S.C. § 12181(7) — "an inn, hotel, motel," "a restaurant," "a hardware store," etc. — are explicitly introduced with the language "[t]he following private entities are considered public accommodations". The court read this language as illustrative; the list provides examples of the kinds of entities covered, not an exhaustive enumeration.
### 3. Second Circuit precedent supports broad coverage
The Second Circuit had previously held in Pallozzi v Allstate (1999) that an insurance policy could be a "good or service" covered by Title III even though the policy was sold over the phone, not at a physical place. That reading — focusing on the goods and services, not the physical infrastructure — supported extending coverage to websites.
The court further held that even if the website were construed as merely connecting customers to Blick\'s physical stores, the inaccessibility violated ADA Title III under the more conservative nexus theory as well.
## Do not use Andrews and the vacated Gil panel opinion as a two-case circuit map
Andrews is a district-court decision. The April 2021 Gil panel opinion was vacated as moot in December 2021. Current Title III coverage analysis must start with controlling appellate authority and the facts in the relevant jurisdiction, not a marketing table that assigns broad or narrow labels from these two matters.
## What Andrews means for Shopify merchants
For Shopify merchants, the reliable operating advice is non-categorical:
1. Make product discovery, forms, cart, account, media, and checkout journeys usable by people with disabilities.
2. Test the current rendered storefront with automated and manual methods, including keyboard and assistive technology.
3. Keep accessibility statements and remediation records accurate about scope and remaining limitations.
4. Ask qualified counsel which federal, state, or international rules apply; neither a source-code change nor an AccessComply record creates a guaranteed legal defense.
## Further reading
- [Andrews v Blick Art Materials, LLC, 268 F. Supp. 3d 381 (E.D.N.Y. 2017) — full opinion](https://app.midpage.ai/case/andrews-v-blick-art-materials-7244752)
- [Pallozzi v Allstate Life Insurance Co., 198 F.3d 28 (2d Cir. 1999)](https://law.justia.com/cases/federal/appellate-courts/F3/198/28/597020/)
- [42 U.S.C. § 12181 — ADA Title III definitions](https://www.law.cornell.edu/uscode/text/42/12181)
- [AccessComply: Robles v Domino\'s deep-dive](/blog/robles-v-dominos-shopify-lessons)
- [AccessComply: Gil v Winn-Dixie vacatur and procedural history](/blog/gil-v-winn-dixie-shopify-lessons)
- [AccessComply: NFB v Target — first major class-action settlement](/blog/nfb-v-target-shopify-lessons)
---
## AudioEye Alternative for Shopify: A Buyer’s Due-Diligence Guide
URL: https://accesscomply.com/blog/audioeye-alternative-shopify
Excerpt: A careful framework for comparing AudioEye’s current products and services with a Shopify-native remediation workflow—without stale prices or unsupported feature claims.
Merchants searching for an AudioEye alternative are often comparing more than software. One offer may combine automation, runtime behavior, expert services, and legal-support resources; another may focus on a Shopify-native change workflow. Treat each layer separately.
AudioEye’s products, service bundles, and prices can change. Ask AudioEye for current documentation and a demonstration. The statements below describe AccessComply’s workflow and a vendor-neutral evaluation method, not AudioEye’s current feature inventory.
## Compare outcomes, not category labels
Ask both vendors:
- Which storefront routes, states, and responsive breakpoints are scanned?
- Which findings are automated, and which need human testing?
- Does a change affect Shopify theme source, Shopify content, runtime output, or a service deliverable?
- Can the merchant inspect and approve the change scope first?
- What is re-tested after the change?
- What record and restore path exists?
- How are third-party apps, checkout, PDFs, video, and complex widgets handled?
- What persists after cancellation, uninstall, a theme update, or a theme switch?
- Which services and response times are contractually included in the current plan?
## AccessComply’s current answer
AccessComply scans discoverable public storefront pages within crawler and plan limits. It reports automated-rule findings in that scope. For eligible safely source-mapped candidates, a merchant approves the exact or scoped change before a supported write.
Supported writes create restore records and run a post-change check. Only confirmed findings are marked resolved. Unsupported, unresolved, third-party, and judgment-heavy work remains visible for manual review.
This does not constitute a comprehensive human audit, WCAG conformance determination, legal opinion, or protection from a claim.
## Current AccessComply pricing
AccessComply currently offers Free, Starter at $29 per month, Shield at $79 per month, and Citadel at $199 per month. Paid plans can also use optional annual Shopify billing. See [pricing](/pricing) for current annual amounts and entitlements.
Confirm AudioEye’s current price and included services directly. A software fee and a managed expert engagement should not be compared as though they deliver the same work.
## When a broader service may fit
A cross-platform or managed service may be a better fit when the organization needs coordinated human audits, non-Shopify properties, procurement support, accessibility-program governance, or specialist remediation beyond the theme and Shopify content paths.
A Shopify-native tool may fit when the merchant wants in-admin scanning, explicit write approval, scoped restore records, and monitoring tied to a Shopify store. Many teams will still need both software and qualified people.
Run a [free AccessComply scan](/), then ask every shortlisted vendor to explain the exclusions and manually verify the critical customer journey.
---
## How to Compare Shopify Accessibility Apps in 2026
URL: https://accesscomply.com/blog/best-shopify-accessibility-app
Excerpt: A merchant-first framework for comparing Shopify accessibility apps by scan scope, write path, approval controls, verification, manual-review boundaries, and current plan terms.
Choosing a Shopify accessibility app is not a contest over who says “compliant” most confidently. The useful question is what the product actually checks, changes, verifies, and leaves for people to review.
Automated scans cover only eligible machine-testable patterns. They do not establish WCAG conformance, legal compliance, or protection from a claim. Manual keyboard and assistive-technology testing, content judgment, and professional advice may still be needed.
## A durable comparison framework
Use the same questions for AccessComply, accessiBe, UserWay, AudioEye, EqualWeb, EnableAll, Isonomy, and any other vendor:
| Question | Why it matters |
|---|---|
| What pages and states are scanned? | A homepage result does not represent carts, dialogs, account pages, third-party apps, or every responsive state. |
| Which WCAG rules are automated? | “WCAG support” can mean a ruleset, a report mapping, manual testing, or a marketing claim. Ask for the exact scope. |
| Where does remediation live? | Theme source, Shopify content, a runtime script, a managed-service patch, and a recommendation are different outcomes. |
| Who approves a write? | Merchants should understand the exact or scoped change before supported production writes. |
| What happens after the change? | A post-change check can confirm a specific automated rule, but it is not a complete conformance audit. |
| Is there a restore path? | Ask what is recorded, who confirms restore, and whether restoring can overwrite later edits. |
| What remains manual? | Captions, PDFs, complex interactions, third-party output, and judgment-heavy content often need specialist work. |
| What happens on uninstall or theme switch? | Runtime behavior can stop; theme edits stay only in the modified theme; content changes have their own lifecycle. |
| What is included in this plan today? | Prices, limits, services, and support change. Use the current vendor listing and contract. |
## What AccessComply currently does
AccessComply scans discoverable public storefront pages within crawler safety and time limits. It reports automated-rule findings in the scanned scope. For eligible, safely source-mapped candidates, the merchant reviews and approves the proposed scope before a supported Shopify write. Supported writes create restore records and run a post-change check; only confirmed findings are marked resolved.
Unsupported, unresolved, third-party, and judgment-heavy work remains visible for manual review. AccessComply is not a replacement for a comprehensive human audit, accessibility counsel, or ongoing merchant QA.
The current plan outline is:
- Free: three app scans per calendar month and three eligible deterministic fixes per rolling 30 days.
- Starter: $29 per month, unlimited deterministic fixes, quarterly monitoring, and remediation reports.
- Shield: $79 per month, AI-assisted alt-text and ARIA candidates plus monthly monitoring by default.
- Citadel: $199 per month, daily monitoring by default.
Optional annual billing is available through Shopify for paid plans. Check the [pricing page](/pricing) for current annual amounts and plan detail.
## How to evaluate competitor information
Competitor prices, ratings, feature names, and delivery methods can change without notice. This guide intentionally does not reproduce a current-looking matrix that will become stale. For every vendor on your shortlist:
1. Read the current Shopify App Store listing and vendor plan page.
2. Ask for a live demonstration on a development theme.
3. Inspect the theme and rendered storefront before and after the demonstration.
4. Ask which findings were not detected, not eligible, or not verified.
5. Read the restore, cancellation, data-retention, and support terms.
6. Test a representative purchase journey with keyboard navigation and assistive technology.
The [FTC’s 2025 final order concerning accessiBe](https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million) is a useful reminder to demand evidence for automated-conformance claims. It is not evidence that a different product guarantees compliance.
## A practical short list
Choose the product and service mix that can answer these questions with evidence:
- Can it show the finding in the actual storefront state?
- Can it explain whether the candidate affects theme source, Shopify content, or runtime behavior?
- Can the merchant review and approve supported writes?
- Can it show what was checked after the change?
- Can it state clearly what still needs manual work?
- Can it describe the lifecycle of the change after uninstall, theme updates, or a theme switch?
Start with a [free automated scan](/), then verify the result manually before treating any finding—or any vendor claim—as complete.
---
## DOJ and H&R Block (2014): What the Consent Decree Required
URL: https://accesscomply.com/blog/doj-h-r-block-settlement-shopify-lessons
Excerpt: The 2014 H&R Block consent decree required case-specific WCAG 2.0 AA, audit, training, reporting, damages, and civil-penalty terms. This guide explains those terms without treating one settlement as a binding rule or cost model for every merchant.
The March 2014 H&R Block consent decree is a useful example of a DOJ-backed, case-specific accessibility resolution. It specified WCAG 2.0 Level AA, third-party review, governance, training, reporting, and monetary terms for the parties. It did not create a binding nationwide rule for private ecommerce, predict another case\'s outcome, or establish a standard settlement amount.
"H&R Block will make its website... and its mobile applications conform to the Web Content
Accessibility Guidelines (WCAG) 2.0 Level AA — the industry guidelines for making websites
accessible to individuals with disabilities. The agreement requires that the website and mobile
applications be made compliant with these guidelines by January 1, 2015 for the 2015 tax filing
season." — DOJ Press Release, March 2014, on the H&R Block consent decree
## The procedural history
The case was filed in March 2013 in the District of Massachusetts (1:13-cv-10799-GAO) by the National Federation of the Blind and two blind plaintiffs, Mika Pyyhkala and Lindsay Yazzolino. They alleged that H&R Block\'s online tax-preparation website (hrblock.com) and mobile applications were inaccessible to screen-reader users in violation of ADA Title III and applicable state laws.
Eight months later, in November 2013, the **U.S. Department of Justice filed a complaint-in-intervention** — joining the private suit as a party and asserting the United States\' interest in enforcing ADA Title III in that matter.
In **March 2014**, four months after DOJ\'s intervention, the parties entered a consent decree resolving the case.
## What the consent decree required
The decree\'s substantive obligations:
### Technical conformance
H&R Block was required to bring its website and mobile applications into conformance with **WCAG 2.0 Level AA** by **January 1, 2015** — in time for the 2015 tax-filing season. Subsequent updates to either the website or apps had to launch already conforming.
### Annual third-party audits
H&R Block agreed to retain an independent third-party accessibility consultant to conduct annual audits of the website and apps and to remediate any non-conformance found.
### Web Accessibility Coordinator
H&R Block agreed to designate a Web Accessibility Coordinator with documented responsibility for ongoing accessibility, accessibility user testing, and incident response.
### Staff training
Relevant H&R Block staff (web developers, designers, content authors, customer-service representatives) were required to receive accessibility training.
### Compensation
- **$100,000 in damages** to the two named plaintiffs ($45,000 each in compensatory damages plus $10,000 for emotional distress).
- **$55,000 civil penalty** payable to the United States for the ADA violations (the maximum penalty under Title III for a first violation at the time was $75,000).
### Ongoing reporting
H&R Block was required to submit annual compliance reports to DOJ throughout the decree term.
## Why the WCAG 2.0 AA term mattered
The decree identified a specific technical version and conformance level for the covered H&R Block surfaces. That gave the parties an auditable target and illustrates why a remediation program should state its standard, version, scope, exclusions, evaluation methods, and timeline precisely.
Other DOJ resolutions and federal accessibility frameworks have also referenced WCAG, but each source has its own legal authority and scope. For example, rules governing state and local governments under ADA Title II are not automatically the rules for a private ecommerce service under Title III. Check the current primary source that applies rather than deriving a universal requirement from this decree.
## How H&R Block compares to NFB v Target
The 2008 NFB v Target settlement and the 2014 H&R Block consent decree involved different parties, courts, remedies, and technical terms. The comparison below is descriptive; neither negotiated resolution establishes a universal template or predicted amount for another merchant.
| Comparison | NFB v Target (2008) | DOJ + NFB v H&R Block (2014) |
| ------------------------ | --------------------------- | ----------------------------------- |
| Plaintiff | NFB + class | NFB + 2 individuals + DOJ |
| Court | N.D. Cal. | D. Mass. |
| Resolution | Settlement | Consent decree |
| Technical standard cited | "Accessible to NFB members" | **WCAG 2.0 Level AA** |
| Monetary | $6M class fund | $100K + $55K penalty |
| DOJ involvement | None | Complaint-in-intervention |
| Subsequent influence | Class-action template | Federal technical-standard template |
## Practical Shopify lessons
### 1. Name the engineering target and scope
Choose the WCAG version and level appropriate to the program, then state which storefront pages, customer-account flows, embedded apps, documents, media, viewports, and interaction states were evaluated. A version label without scope is not a conformance result.
### 2. Combine tools, people, and ownership
The decree used multiple controls rather than one scanner. A merchant program can similarly combine automated checks, manual keyboard and assistive-technology testing, a named owner, staff training, a barrier-reporting channel, and documented follow-up. The appropriate audit cadence depends on change rate, obligations, and risk; it cannot be copied from one consent decree.
### 3. Keep case amounts in context
The damages and civil penalty were negotiated for this matter. They are not a typical Shopify settlement range, an inflation calculator for a future case, or a prediction of another merchant's exposure. Current penalties and remedies depend on the enforcing authority, statute, jurisdiction, facts, and procedural posture; ask counsel about the current primary law.
### 4. Keep evidence factual
AccessComply can retain scoped automated-scan and supported-change records. Those records can help a team understand work performed, but they do not prove historical accessibility, replace an independent manual audit, create a legal defense, or guarantee a regulator or court outcome.
## Further reading
- [DOJ Press Release: Justice Department enters consent decree with H&R Block (March 2014)](https://www.justice.gov/opa/pr/justice-department-enters-consent-decree-national-tax-preparer-hr-block-requiring)
- [Consent decree, NFB et al. v H&R Block, 1:13-cv-10799-GAO (D. Mass.)](https://archive.ada.gov/hrb-cd.htm)
- [DOJ press release on H&R Block consent decree](https://www.justice.gov/archives/opa/pr/justice-department-enters-consent-decree-national-tax-preparer-hr-block-requiring)
- [DOJ Title II final rule (April 2024) — incorporates WCAG 2.1 AA for state and local government websites](https://www.federalregister.gov/documents/2024/08/09/2024-16702/nondiscrimination-on-the-basis-of-disability-accessibility-of-web-information-and-services-of-state)
- [42 U.S.C. § 12181 — ADA Title III definitions](https://www.law.cornell.edu/uscode/text/42/12181)
- [WCAG 2.1 AA full success-criteria list](https://www.w3.org/TR/WCAG21/)
- [AccessComply: NFB v Target — first major class-action settlement](/blog/nfb-v-target-shopify-lessons)
- [AccessComply: Robles v Domino\'s — the Ninth Circuit foundational ruling](/blog/robles-v-dominos-shopify-lessons)
- [AccessComply: NAD v Netflix — online-only services and ADA Title III](/blog/nad-v-netflix-shopify-lessons)
---
## EAA Compliance for French Shopify Stores: RGAA, Loi pour la Confiance Numérique, and the EAA
URL: https://accesscomply.com/blog/eaa-compliance-france-shopify
Excerpt: France has the most advanced digital accessibility legal framework in Europe, combining the RGAA national standard, pre-existing public sector obligations, and now the European Accessibility Act. Here is what French Shopify merchants need to know.
## France: Europe's Most Experienced Accessibility Jurisdiction
France has been regulating digital accessibility longer than most European countries. The **Loi pour la République Numérique** (2016) extended accessibility requirements to large private companies. The **RGAA** (Référentiel Général d'Amélioration de l'Accessibilité) provides France's national technical standard, which aligns closely with WCAG 2.1.
Now, the European Accessibility Act (EAA) — transposed into French law in 2024 — extends these obligations further, specifically to ecommerce digital services. If you operate a Shopify store targeting French customers, understanding this layered framework is essential.
## France's Accessibility Law Framework
### 1. Loi pour la République Numérique (2016)
This law applied digital accessibility obligations to:
- Public sector bodies
- Companies with more than 250 employees
- Companies with more than €50 million in annual turnover
For smaller Shopify merchants, this law historically did not apply directly. The EAA changes that for ecommerce.
### 2. The RGAA — France's Technical Standard
The RGAA provides 106 criteria for testing accessibility, organized into 13 themes. It is the French interpretation of WCAG and EN 301 549, and auditors and accessibility professionals in France use it as the benchmark.
RGAA criteria cover:
- Images and their alternatives
- Colors and contrast
- Scripts and dynamic content
- Multimedia
- Tables
- Forms
- Navigation
- Consultation (reading/comprehension)
RGAA and WCAG overlap substantially, but RGAA evaluation has its own test framework, scope, documentation, and manual-review requirements. Fixing an automated WCAG-mapped finding does not by itself establish RGAA or legal conformance.
### 3. EAA Transposition (2024)
France transposed the EAA through an ordonnance, extending accessibility obligations to:
**Ecommerce services offered to consumers** — specifically including online shopping interfaces, ordering processes, and digital payment flows.
The enforcement date for private sector ecommerce: **June 28, 2025**.
## What French Ecommerce Stores Must Do
### Publish a Déclaration d'Accessibilité
Under French law, a **déclaration d'accessibilité** (accessibility statement) is mandatory. The statement must:
1. State your conformance level (fully compliant, partially compliant, non-compliant)
2. List the non-compliant content and the WCAG/RGAA criteria it fails
3. Describe the exceptions or alternative content provided
4. Provide a contact mechanism (email, form, or phone)
5. Name the person responsible for accessibility at your organization
6. Include a reference to the enforcement authority
France's DINUM (Direction Interministérielle du Numérique) provides an official template at accessibilite.numerique.gouv.fr. The statement must be accessible from your homepage — typically linked in the footer.
### Provide an Accessible Ecommerce Interface
The core technical requirement is WCAG 2.1 Level AA for your digital commerce interface. This means the same technical fixes as EAA compliance generally:
- Alt text on product images
- Accessible forms (labels, error messages)
- Sufficient color contrast
- Keyboard navigation
- Skip navigation
- Screen reader compatibility
- Accessible media controls
### Respond to Accessibility Complaints
French accessibility law includes a formal complaints mechanism. Users who encounter inaccessible content on your store can file a complaint directly with you or with the enforcement authority. You are required to respond within a reasonable time.
The enforcement authority for private sector digital accessibility in France is the **ARCOM** (Autorité de Régulation de la Communication Audiovisuelle et Numérique), which has taken over from the previous Défenseur des droits mechanism.
## Penalties for Non-Compliance in France
France's enforcement regime includes:
- **€20,000** per violation for failure to publish a valid accessibility statement
- **Injunctive orders** from ARCOM requiring you to make content accessible within a specified deadline
- **Court-ordered remediation with daily penalties** — in June 2026 the Tribunal judiciaire de Caen ordered Carrefour to bring carrefour.fr and its mobile app into full accessibility within six months under a €500/day astreinte (a coercive daily penalty that only runs if the deadline is missed), rejecting the retailer's "71% RGAA-conformant" partial-compliance defence: accessibility is an obligation of result, not of means (Article L.412-13, French Consumer Code)
- **Repeated violation penalties** can escalate significantly
- **DGCCRF** (France's consumer protection authority) also has authority over ecommerce accessibility as a consumer rights matter
This is more active enforcement than most EU countries had before the EAA, because France already had enforcement infrastructure from its pre-EAA public sector accessibility laws.
## Special Considerations for French Shopify Stores
### Language and Accessibility
WCAG 3.1.1 requires the correct `lang` attribute on the HTML element. French-language stores must have `lang="fr"`. If your Shopify store serves multiple language markets via Shopify Markets, ensure that the correct language attribute is set for each locale.
Shopify's `request.locale.iso_code` Liquid variable should automatically populate the correct language code:
```liquid
```
### French Consumer Law Integration
France's **Code de la consommation** already requires that ecommerce interfaces be clear, accessible, and usable. Accessibility violations that prevent users from completing a purchase may also trigger consumer protection complaints — separate from accessibility law.
### RGAA Audit Requirements
For larger French companies (250+ employees or €50M+ turnover), French law historically required a periodic RGAA audit. The EAA extends accessibility obligations to smaller entities, but the audit requirement mechanism is still evolving in the private sector context.
AccessComply can provide scoped automated findings mapped to relevant WCAG criteria and remediation records for supported changes. These records may support an engineering work log, but they are not an RGAA audit, a legal opinion, or documentation of legal conformance.
## Getting Started with EAA/RGAA Compliance for Your French Store
**Step 1:** Combine a scoped automated scan with manual keyboard, assistive-technology, content, and journey testing. AccessComply reports automated WCAG-mapped findings with severity and page evidence only for the states and rules reached.
**Step 2:** Remediate confirmed barriers in the owning theme, content, app, media, or third-party surface. A runtime tool should not be represented as proof of conformance, and source changes still require verification and manual review.
**Step 3:** Write your déclaration d'accessibilité using DINUM's template. Be honest about your conformance level — stating "fully compliant" when you have open violations is a legal risk.
**Step 4:** Add the accessibility statement to your footer with a prominent link.
**Step 5:** Establish a monitoring process. French law requires ongoing compliance — theme updates, new content, and new apps can all introduce new violations.
France takes digital accessibility seriously. With an established regulatory framework, active enforcement authority, and a population of disability advocates familiar with their rights, non-compliant French-market ecommerce stores face real consequences.
## Further Reading
- [European Accessibility Act 2025: What Shopify Merchants Selling to the EU Must Do Now](/blog/eaa-enforcement-deadline-shopify)
- [EAA Compliance for German Shopify Stores: What the BFSG Requires](/blog/eaa-compliance-germany-shopify)
- [UK Web Accessibility Law for Shopify Stores: Equality Act 2010](/blog/eaa-compliance-uk-shopify)
- [WCAG 2.1 AA Compliance Checklist for Shopify Store Owners](/blog/wcag-21-aa-checklist-shopify)
---
## EAA Compliance for German Shopify Stores: What the Barrierefreiheitsstärkungsgesetz Requires
URL: https://accesscomply.com/blog/eaa-compliance-germany-shopify
Excerpt: Germany implemented the European Accessibility Act as the Barrierefreiheitsstärkungsgesetz (BFSG). Since June 28, 2025, German ecommerce businesses and EU merchants selling to German customers must comply. Here is what it means for Shopify stores.
## Germany's Accessibility Law: The BFSG
Germany implemented the European Accessibility Act (EAA) through the **Barrierefreiheitsstärkungsgesetz** (BFSG — "Barrier Reduction Strengthening Act"). The BFSG entered into force on July 28, 2021, and became fully enforceable for new digital products and services on **June 28, 2025**.
For Shopify merchants operating in Germany or selling to German customers, the BFSG is the primary legal framework to understand.
## What the BFSG Requires for Ecommerce
The BFSG defines "services of electronic commerce" as a covered category. This includes:
- Online stores (Shopify stores)
- Ordering and checkout processes
- Order confirmation and tracking interfaces
- Customer account portals
- Any digital service supporting the ecommerce transaction
The technical standard referenced is **EN 301 549**, which maps to **WCAG 2.1 Level AA**. The four principles are Perceivable, Operable, Understandable, and Robust.
### What WCAG 2.1 AA Means for Your Store
Practically speaking, BFSG compliance for a Shopify store means:
**Images must have text alternatives (WCAG 1.1.1)**
Every product image needs descriptive alt text. Icon buttons need ARIA labels. Decorative images need empty alt attributes. This is the most commonly failed criterion on Shopify stores.
**Text contrast must meet minimum ratios (WCAG 1.4.3, 1.4.11)**
Body text: 4.5:1 minimum. Large text (18px+ normal or 14px+ bold): 3:1 minimum. UI components: 3:1 minimum.
**Forms must be fully accessible (WCAG 1.3.1, 3.3.x)**
Every form input needs a programmatic label. Error messages must be specific and associated with the relevant field. Required fields must be indicated programmatically, not just visually.
**Keyboard navigation must be fully functional (WCAG 2.1.1, 2.4.x)**
Every function available via mouse must be available via keyboard. No keyboard traps. Visible focus indicators. Logical tab order.
**Content must be understandable (WCAG 3.1.1)**
The `lang` attribute must be set correctly on the HTML element. Error messages must use plain language.
## Who the BFSG Applies To
The BFSG has an exemption for **microenterprises** — companies with fewer than 10 employees AND annual turnover/balance sheet total not exceeding €2 million. Microenterprises providing services (not products) are exempt.
However, this exemption is narrow. Most Shopify merchants above these thresholds — or those selling products rather than services — are fully subject to the BFSG.
**Important:** The microenterprise exemption applies to service providers. Merchants selling physical products to German customers should seek legal advice on whether the exemption applies to their specific situation, as the interpretation is still developing.
## Accessibility Statement Requirements
Under the BFSG, covered ecommerce providers must publish an **accessibility statement** (Barrierefreiheitserklärung) on their website. The statement must include:
1. Which WCAG 2.1 AA criteria your service conforms to
2. Any known aspects of non-conformance
3. Any alternatives available for inaccessible content
4. A mechanism for users to report accessibility barriers
5. Contact information for the responsible authority (Durchsetzungsstelle)
Germany's federal government provides guidance on the required format and content through the Federal Commissioner for Accessibility (Beauftragter der Bundesregierung für die Belange von Menschen mit Behinderungen).
AccessComply includes a merchant-editable accessibility statement starting point. Review its scope, claims, required disclosures, contact route, and current German requirements before publication; the template does not establish BFSG compliance.
## The Enforcement Mechanism in Germany
Unlike the ADA in the United States — which primarily generates civil lawsuits — the BFSG uses a **regulatory enforcement** model:
1. **Market surveillance authorities** (Marktüberwachungsbehörden) at the Bundesland level are responsible for enforcement
2. **Complaints mechanism:** Users can file complaints with the enforcement authorities if a service is inaccessible
3. **Mediation procedure:** Before formal enforcement, a mediation process may be required
4. **Orders and penalties:** Enforcement authorities can order companies to make services accessible and impose administrative fines
The specific authorities and fine amounts vary by Bundesland. Bavaria's Gewerbeaufsichtsbehörden and North Rhine-Westphalia's LANUV are two examples of bodies responsible for BFSG enforcement.
## Practical Compliance Timeline for German Shopify Merchants
**If you launched your store before June 28, 2025:** You had until June 28, 2025 to comply for services (some product exceptions apply through 2030). If you have not yet addressed accessibility, you are operating in violation of the BFSG now.
**If you launched after June 28, 2025:** Compliance was required from day one. New services launched after the enforcement date must be compliant immediately.
**Ongoing obligation:** The BFSG is not a one-time fix. Every time your store content changes — new products, updated banners, theme changes, new apps — there is a risk of introducing new violations. The BFSG requires that you maintain compliance, not just achieve it once.
## Steps to Achieve BFSG Compliance for Your Shopify Store
### Step 1: Conduct an Accessibility Audit
Scan representative storefront pages to identify eligible automated findings in the reported scope. Manual keyboard, assistive-technology, content, and task-flow testing is also needed; neither automated nor finite manual sampling guarantees every possible state has been covered.
AccessComply's automated scanner provides:
- Axe-core findings detected in the pages, states, and automated rules reached, with severity, location, and WCAG mapping
- An automated accessibility score for the reported scan scope
- An automated finding-priority band (CRITICAL / HIGH / MEDIUM / LOW) based on finding volume in the reported scan scope
### Step 2: Fix Violations at the Source Code Level
The customer journey itself must meet applicable requirements. Runtime tools and source remediation use different mechanisms; neither architecture establishes legal conformance without testing the served experience and the required manual criteria.
Fix violations in your Shopify theme files:
- Add alt text to product images
- Associate labels with form inputs
- Fix color contrast in CSS
- Add skip navigation
- Fix heading hierarchy
- Add ARIA labels to icon buttons
AccessComply can apply merchant-approved changes for eligible findings that map safely to supported theme or content sources; the remaining findings still require manual review.
### Step 3: Publish an Accessibility Statement
If a statement is required for your service, prepare and publish a reviewed Barrierefreiheitserklärung with the disclosures and contact route required by current German law. Do not label a generated template compliant without verifying it.
### Step 4: Establish Ongoing Monitoring
Choose a monitoring cadence that matches store change frequency and the selected plan, then repeat manual journey testing after material theme, content, or app changes. Monitoring is evidence of an ongoing process, not a conformance determination.
## Working with a German Accessibility Specialist
For a full technical and legal assessment, consider working with a German accessibility specialist or a BITV/EN 301 549 audit provider. AccessComply can support scoped automated discovery and eligible merchant-approved remediation, while complex widgets, multimedia, documents, manual criteria, and legal scope require separate review.
The BFSG is enforceable now. For German merchants and international merchants selling into Germany, accessibility compliance is not optional.
## Further Reading
- [European Accessibility Act 2025: What Shopify Merchants Selling to the EU Must Do Now](/blog/eaa-enforcement-deadline-shopify)
- [EAA Compliance for French Shopify Stores: RGAA and the EAA](/blog/eaa-compliance-france-shopify)
- [UK Web Accessibility Law for Shopify Stores: Equality Act 2010](/blog/eaa-compliance-uk-shopify)
- [WCAG 2.1 AA Compliance Checklist for Shopify Store Owners](/blog/wcag-21-aa-checklist-shopify)
---
## UK Web Accessibility Law for Shopify Stores: Equality Act 2010 and Beyond
URL: https://accesscomply.com/blog/eaa-compliance-uk-shopify
Excerpt: The UK is not subject to the EAA post-Brexit, but the Equality Act 2010 still requires accessible websites. UK merchants are increasingly targeted by accessibility complaints and tribunal claims. Here is what Shopify store owners need to know.
## UK Web Accessibility: The Legal Framework
Post-Brexit, UK businesses are no longer subject to the European Accessibility Act. But that does not mean UK Shopify stores have no accessibility obligations. The primary legal framework is the **Equality Act 2010**, which has applied to digital services for over a decade.
If you operate a Shopify store in the UK or sell to UK customers, understanding the Equality Act's implications for your website is essential.
## The Equality Act 2010 and Your Website
The Equality Act 2010 prohibits discrimination against people with protected characteristics, including disability. Under the Act:
**Services providers must not treat disabled people less favorably** than non-disabled people. A website that is inaccessible to screen reader users, keyboard-only users, or users with cognitive disabilities treats those users less favorably than sighted users with full motor function.
**Service providers must make reasonable adjustments** to remove barriers that put disabled persons at a substantial disadvantage. For a Shopify store, this means making reasonable efforts to ensure the website can be used by people with disabilities.
### What "Reasonable Adjustments" Mean for Websites
The Equality Act's "reasonable adjustments" duty is context-dependent. Courts and tribunals consider:
- The nature and size of the business
- The cost of making the adjustment
- The practicality of the adjustment
- The impact of not making the adjustment
For most Shopify merchants, fixing common accessibility violations (alt text, form labels, color contrast, keyboard navigation) is both practical and inexpensive. What counts as a reasonable adjustment under the Equality Act is decided case by case on the facts, so treat automated remediation as one input, not a determination.
### No Specific Technical Standard in UK Law
Unlike the EAA (which references EN 301 549/WCAG 2.1 AA), the Equality Act 2010 does not specify a technical standard. Courts use WCAG as a benchmark when evaluating whether a website is accessible, and WCAG 2.1 Level AA is the widely accepted target.
The **Government Digital Service (GDS)** publishes guidance recommending WCAG 2.1 AA for all government and public sector websites. This sets the precedent that the same standard is appropriate for private sector commerce.
## Public Sector Bodies Accessibility Regulations 2018
Separate from the Equality Act, UK public sector bodies (government, NHS, councils, universities, etc.) are subject to the **Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018**. These specifically require WCAG 2.1 AA compliance and a published accessibility statement.
These regulations do not apply to private Shopify merchants, but they establish a clear UK government position on what accessible digital services look like.
## The Risk Profile for UK Shopify Merchants
UK web accessibility enforcement is less systematic than in the US (no private right of action under a statute equivalent to the ADA), but the risk is growing:
### EHRC Investigations
The **Equality and Human Rights Commission (EHRC)** can investigate organizations for systemic discrimination, including inaccessible digital services. The EHRC has publicly called on private sector organizations to make websites accessible and has enforcement powers.
### Civil Claims
Disabled customers can bring civil claims for disability discrimination in goods and services. UK courts have awarded damages in cases where inaccessible digital services caused genuine disadvantage. While these cases are not as numerous as US ADA lawsuits, they exist and are increasing.
### Reputational Risk
UK disability charities and advocacy organizations — Scope, AbilityNet, RNIB — regularly audit websites for accessibility and publish findings. Being named in a poor accessibility report can cause reputational damage with customers and business partners.
### Customer Loss
Approximately 22% of the UK population has a disability (ONS data). Inaccessible websites exclude these customers. The UK disability market has an estimated annual spending power of £274 billion (Purple Pound). This is both a compliance risk and a commercial opportunity.
## What the UK Government Recommends
The Government Digital Service (GDS) maintains detailed accessibility guidance at gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps.
While this guidance applies to public sector, it reflects UK government expectations and provides a practical roadmap:
1. Meet WCAG 2.1 Level AA
2. Test with disabled users (not just automated tools)
3. Publish an accessibility statement
4. Respond to accessibility issues raised by users
The RNIB (Royal National Institute of Blind People) and AbilityNet (a leading UK accessibility charity) also provide guidance on website accessibility that is widely referenced in UK legal contexts.
## WCAG 2.1 AA for UK Shopify Stores: The Technical Requirements
Meeting WCAG 2.1 AA is the practical standard for Equality Act compliance with respect to your website. For Shopify stores, the most important criteria:
**1.1.1 Non-text Content** — All images, icons, and non-text UI elements must have text alternatives. Product images need descriptive alt text. Icon buttons need aria-labels.
**1.4.3 Contrast (Minimum)** — Text must maintain 4.5:1 contrast against its background. Buttons, links, and navigation elements must be distinguishable.
**1.3.1 Info and Relationships** — Form inputs must have programmatic labels. Data tables must have headers. Semantic HTML is required.
**2.1.1 Keyboard** — All functionality must be operable via keyboard. No mouse-only interactions.
**2.4.3 Focus Order** — Tab order must be logical and match the visual reading order.
**3.3.x Forms** — Error messages must be specific, associated with the relevant field, and provide guidance on correction.
## A Practical Accessibility Process for a UK Store
### 1. Scan Your Store
Run scoped automated checks and manual journey testing to identify confirmed barriers. AccessComply reports axe-core findings detected in the pages, states, and rules reached, with severity and WCAG mapping; it is not a complete audit.
### 2. Fix Source-Code Violations
Address confirmed barriers in the system that owns them, which may be the theme, Shopify content, an app, media, a document, or a third-party service. Verify the served experience after any source or runtime change; neither mechanism proves compliance on its own.
### 3. Publish an Accessibility Statement
Create a plain-language statement describing:
- Your conformance target (WCAG 2.1 AA)
- Any known limitations
- How users can request assistance or report issues
- A point of contact
### 4. Test with Keyboard and Screen Reader
Automated tools cover only eligible machine-testable patterns in the states they reach. Manual testing — including keyboard navigation and relevant assistive technology — is still required, and no finite test guarantees that every barrier has been found. At minimum, review representative purchase journeys and document the scope.
### 5. Monitor After Store Changes
Theme updates, new products, apps, and promotional campaigns can introduce new barriers. Choose a plan-supported scan cadence that matches store change frequency and repeat manual customer-journey testing after material changes.
## The UK's Direction of Travel
The UK government has indicated that private sector web accessibility obligations will be strengthened. The Disability Unit's work on the National Disability Strategy (which survived a High Court challenge on process grounds) included web accessibility as a priority area.
UK accessibility enforcement is heading toward greater oversight. Merchants who establish good accessibility practices now are better positioned as requirements tighten.
## Further Reading
- [European Accessibility Act 2025: What Shopify Merchants Selling to the EU Must Do Now](/blog/eaa-enforcement-deadline-shopify)
- [EAA Compliance for German Shopify Stores: What the BFSG Requires](/blog/eaa-compliance-germany-shopify)
- [EAA Compliance for French Shopify Stores: RGAA and the EAA](/blog/eaa-compliance-france-shopify)
- [WCAG 2.1 AA Compliance Checklist for Shopify Store Owners](/blog/wcag-21-aa-checklist-shopify)
---
## European Accessibility Act 2025: What Shopify Merchants Selling to the EU Must Do Now
URL: https://accesscomply.com/blog/eaa-enforcement-deadline-shopify
Excerpt: The European Accessibility Act began enforcement June 28, 2025. Learn which ecommerce services are covered, which exemptions matter, and how WCAG and EN 301 549 support a practical Shopify accessibility program.
## EAA Enforcement Has Begun
On June 28, 2025, the European Accessibility Act became enforceable across all 27 EU member states.
This is not a future deadline. Merchants offering covered ecommerce services to EU consumers may be in scope even when established elsewhere, subject to exclusions and exemptions. Each member state implements and enforces the Directive through national law.
## What the EAA Requires
The EAA expressly covers "e-commerce services," defined around services provided at a distance, through websites and mobile-device-based services, at a consumer\'s individual request with a view to concluding a consumer contract. That is broader than online marketplaces, but it is not shorthand for every website that can receive an EU order.
The Directive\'s binding requirements are functional requirements in Annex I. **EN 301 549 v3.2.1** is a commonly used technical reference and its web chapter incorporates **WCAG 2.1 Level AA**. AccessComply also checks applicable WCAG 2.2 criteria separately.
WCAG remediation overlaps across ADA, EAA, EN 301 549, procurement, and usability programs, but those legal regimes are not interchangeable. A stronger WCAG program reduces duplicated technical work; it does not replace jurisdiction-specific scope, information, process, and manual-evaluation requirements.
## Who Does This Apply To?
Your Shopify service may be in scope when:
✓ You sell physical products shipped to EU countries
✓ You sell digital products (ebooks, software, downloads) to EU customers
✓ You operate a subscription service accessible to EU residents
✓ You provide a covered consumer service at a distance through the storefront
**Exemptions that require a real assessment:**
The EAA exempts "microenterprises providing services." The ecommerce service and the goods sold through it are distinct concepts, so a merchant selling products should not assume the exemption is unavailable—or available—without analyzing the entity and covered activity. Microenterprises dealing with products have narrower documentation relief under the Directive.
## EU Member State Enforcement
EAA enforcement is handled nationally by each member state. Here's a snapshot of key markets:
### Germany (Barrierefreiheitsstärkungsgesetz, BFSG)
Germany's implementation law (BFSG) went into force June 28, 2025. The enforcement body is the Bundesnetzagentur.
Penalties: up to **€100,000** per violation (can aggregate to higher amounts for systematic failures). Germany has historically been aggressive in consumer protection enforcement.
### France
France has multiple accessibility regimes and authorities depending on entity and service type. Merchants should use the current French EAA transposition and official competent-authority guidance for private ecommerce rather than assuming public-sector RGAA rules apply unchanged.
Enforcement status: France produced the EAA's first court order against a retailer. On 4 June 2026 the Tribunal judiciaire de Caen ordered Carrefour to make carrefour.fr and its mobile app fully accessible within six months, under a €500-per-day astreinte — a coercive daily penalty that only accrues if the deadline passes with the work unfinished, not a fine for past conduct. Carrefour's defence that it had reached 71% RGAA conformity was rejected: the court held accessibility is an obligation of result, not of means. The case was brought by disability associations apiDV and Droit Pluriel under Article L.412-13 of the French Consumer Code. The parallel Auchan case was dismissed in May 2026 on a revenue-threshold technicality and is under appeal; E.Leclerc is listed for 22 September 2026 in Créteil; the Picard case is postponed without a new date.
### Netherlands (Wet gelijke behandeling op grond van handicap of chronische ziekte)
The Netherlands' enforcement body is the Netherlands Institute for Human Rights (College voor de Rechten van de Mens). Individual complaints can be filed by disabled users.
### UK (PSBAR 2018)
The UK is no longer in the EU but has parallel accessibility requirements under the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018. The private sector requirements are developing under the UK Equality Act.
### Italy (AgID)
Italy's enforcement body is AgID (Agenzia per l'Italia Digitale). Enforcement typically begins with a complaint from a disabled user, followed by an investigation, a request for the business to demonstrate compliance, and — if necessary — a formal compliance order or fine. This complaint-driven pattern is common across member states.
### Cross-Border Note
Customer location and the market where a covered service is offered can create obligations even when a merchant is incorporated elsewhere. Cross-border scope still depends on how the service is offered, applicable exemptions, and the member state\'s implementing law.
## What "WCAG 2.1 Level AA" Means for Your Store
The practical requirements for WCAG 2.1 AA compliance on a Shopify store:
**Perceivable**:
- All images have descriptive alt text (1.1.1)
- Videos have captions (1.2.2)
- Color is not the only way to convey information (1.4.1)
- Text has sufficient contrast (4.5:1 for normal text) (1.4.3)
- Text can be resized to 200% without loss of function (1.4.4)
- Content doesn't rely on color, size, shape, or spatial position alone (1.3.3)
**Operable**:
- All functionality available by keyboard (2.1.1)
- No keyboard traps (2.1.2)
- Skip navigation to main content (2.4.1)
- Pages have descriptive titles (2.4.2)
- Headings and labels describe topic or purpose (2.4.6)
- Keyboard focus is visible (2.4.7)
**Understandable**:
- Page language is set (3.1.1)
- Navigation is consistent across pages (3.2.3)
- Error suggestions are provided (3.3.3)
- Error prevention on legal and financial transactions (3.3.4)
**Robust**:
- HTML is valid and well-formed (4.1.1 — removed in WCAG 2.2 but still best practice)
- ARIA roles and states are correctly implemented (4.1.2)
- Status messages are programmatically determinable (4.1.3)
## Accessibility service information
For covered services, Annex I requires information explaining how the service meets accessibility requirements to be available in an accessible form. A public accessibility statement can organize useful elements such as:
1. Your WCAG 2.1 AA / EN 301 549 conformance level (full, partial, or non-conformant)
2. Any known non-compliant content
3. Alternative means of access for inaccessible content
4. A contact mechanism for users to report barriers
5. A reference to the relevant national enforcement authority
A persistent footer link is a practical way to make this information easy to find, but exact format and placement depend on national law. AccessComply includes a merchant-reviewed statement workflow on the Free plan and can publish the approved text to a Shopify page; see the [accessibility statement template guide](/blog/shopify-accessibility-statement-template-guide).
## The Overlay Problem Under the EAA
An overlay widget is not evidence that a service meets the EAA\'s functional accessibility requirements. Some user controls can be useful, but they do not replace accessible source markup, keyboard behavior, content, testing, or service information. If a runtime script fails or cannot correct a complex interaction, the underlying barrier remains. [Why overlays don't work](/blog/accessibility-overlay-widgets-dont-work) covers the architecture in depth.
Genuine remediation means modifying the code that generates your pages: `alt` attributes and `aria-label`s in your Liquid templates, contrast-safe color values and focus styles in your CSS, and working keyboard behavior in your JavaScript. AccessComply can apply merchant-approved changes for eligible, safely mapped findings in supported categories, after a backup, and then re-scan the affected pages. Unsupported or judgment-heavy findings remain for manual review. [Run a free scan](/) to see the automated findings on your storefront today.
## The EAA + ADA Combined Risk
For a Shopify merchant selling globally:
- **US customers**: ADA Title III risk (federal + state lawsuits)
- **EU customers**: EAA enforcement risk (national regulatory penalties)
- **UK customers**: UK Equality Act risk (developing)
These regimes share substantial technical accessibility work, but they are not identical. Reuse the WCAG remediation program while evaluating each law\'s scope, procedures, documentation, and remedies separately.
## Getting Started
For merchants in scope, the practical path is:
1. **Scan your store** — review detected findings, the reported scan scope, and the automated accessibility score
2. **Fix critical violations** — keyboard access, alt text, form labels are the highest-priority
3. **Publish accurate accessibility information** — use a statement where it fits the applicable national requirements
4. **Set up monitoring** — theme updates can introduce new findings; use the cadence included in your plan to review regressions promptly
5. **Document your remediation** — timestamps, fix history, and scoped scan reports can record the work performed without establishing legal conformance
The good news: many source-code and content fixes benefit both US and EU accessibility programs. Keep one remediation backlog and evidence trail, then add the jurisdiction-specific review each market requires.
---
*[Scan supported accessibility checks on your Shopify storefront](/){/* →homepage */} — free, no account required.*
## Further Reading
- [EAA Compliance for German Shopify Stores: What the BFSG Requires](/blog/eaa-compliance-germany-shopify)
- [EAA Compliance for French Shopify Stores: RGAA and the EAA](/blog/eaa-compliance-france-shopify)
- [ADA Lawsuits Against Ecommerce Stores: 2025–2026 Statistics and How to Protect Your Business](/blog/ada-lawsuits-ecommerce)
---
## EqualWeb Alternative for Shopify: A Current-Product Comparison Guide
URL: https://accesscomply.com/blog/equalweb-alternative-shopify
Excerpt: Compare EqualWeb’s current vendor-described offering with a Shopify-native remediation workflow using evidence, a live demonstration, and current plan documents.
An EqualWeb-alternative search should lead to due diligence, not a stale matrix. Accessibility vendors can combine software, runtime controls, monitoring, and human remediation in different ways. Ask what is included today and what changes the actual Shopify storefront.
## A proof-based comparison
Request a development-theme demonstration and record:
1. The exact page and state scanned.
2. The finding and rule that triggered.
3. The proposed source, content, runtime, or service action.
4. The merchant approval boundary.
5. The post-change result in the rendered storefront.
6. The restore or removal path.
7. The remaining manual work.
Confirm EqualWeb’s current architecture, services, prices, and plan limits from EqualWeb. Vendor offers change, and an old comparison article is not a reliable contract.
## What AccessComply currently provides
AccessComply scans discoverable public storefront pages within the reported scope and crawler limits. For eligible automated-rule findings with a safe source mapping, it can present a candidate for merchant approval before a supported theme or Shopify content write.
Supported writes create restore records and run a post-change check. Only confirmed findings are marked resolved. Cases that are unsafe, unsupported, unresolved, third-party, or dependent on human judgment remain for manual review.
This workflow does not establish full WCAG conformance or legal compliance.
## Persistence and restore details
Supported theme writes remain in the specific modified theme until overwritten. They do not migrate automatically to another published theme. Supported Shopify content changes remain in the resource. Optional extension behavior stops when the app or embed is removed.
Restore is merchant-confirmed because an older value can overwrite later edits. Ask every vendor to explain the same lifecycle in concrete terms.
## Pricing diligence
AccessComply’s current monthly plans are Free, Starter at $29, Shield at $79, and Citadel at $199, with optional annual Shopify billing for paid plans. Check [pricing](/pricing) for current limits and annual amounts.
Confirm EqualWeb pricing and any managed-service scope directly with EqualWeb. Compare like with like: automated software, expert audit hours, manual remediation, reporting, and support are different deliverables.
## Final check
No app or widget proves compliance by itself. Use automated findings to prioritize work, manually test critical journeys, remediate third-party and content issues, and keep monitoring after store changes.
Start with a [free automated scan](/), then validate important findings with qualified people.
---
## Fashion Ecommerce Accessibility Risk: A Shopify Remediation Guide
URL: https://accesscomply.com/blog/fashion-apparel-ada-lawsuit
Excerpt: How product imagery, swatches, size guides, quick-shop dialogs, filters, and third-party apps can block disabled shoppers—and how to test and remediate them carefully.
Fashion storefronts are visually and interactively dense. That makes them a useful place to focus accessibility engineering—not because a blog can predict a lawsuit, but because barriers can prevent customers from understanding or buying a product.
## High-value test areas
### Product imagery
Review meaningful product images for useful, non-duplicative text alternatives. Decorative images should use empty alt text. Automated checks can find missing attributes, but a person must judge whether a description conveys the product information a shopper needs.
### Color and size swatches
Ensure each option has an accessible name and current state, works by keyboard, does not rely on color alone, and communicates unavailable combinations. Test the real variant-selection and cart behavior rather than only the static markup.
### Size guides and quick shop
Dialogs need an accessible name, managed focus, an operable close path, correct keyboard containment, and focus return. Tables need meaningful headers. Responsive drawers and app-injected modals need separate tests.
### Filters and sorting
Test names, states, result announcements, focus behavior, applied-filter removal, and URL changes. Do not assume a desktop result represents the mobile filter drawer.
### Cart and checkout handoff
Verify quantity controls, validation errors, status announcements, discount controls, and the transition into checkout. Shopify, extensions, and third-party apps may divide ownership of the experience.
## A safe remediation workflow
1. Define representative product, collection, search, cart, account, and editorial journeys.
2. Record theme, apps, market, viewport, and user state.
3. Run automated checks and retain the exact scan scope.
4. Test critical tasks manually with keyboard and relevant assistive technology.
5. Change only approved, understood source or content paths.
6. Verify the served result and related states.
7. Track unresolved third-party and content work.
8. Repeat after theme, app, and merchandising changes.
AccessComply can support the automated portion and propose eligible merchant-approved changes. Supported writes create restore records and receive post-change checks. It does not establish legal compliance, replace a full manual audit, or guarantee protection from a claim.
Start with a [free automated scan](/), then manually test the product-selection and purchase journey that matters most to your customers.
---
## How to Fix Common Accessibility Issues on Shopify: A Technical Guide
URL: https://accesscomply.com/blog/fix-accessibility-issues-shopify
Excerpt: Ten accessibility patterns worth checking on Shopify storefronts, with technical examples, automated-rule boundaries, and guidance for reviewed remediation.
This guide explains ten useful accessibility patterns to review on a Shopify storefront, why each matters, and a possible technical remediation. It is not based on a published representative sample and does not imply that every store contains these issues. Confirm the finding, source ownership, and customer impact before changing code.
Eligible first-party theme or content patterns may have a safely source-mapped remediation candidate. Complex widgets, media alternatives, third-party app output, documents, content meaning, and novel interaction patterns require human or vendor review.
## 1. Missing Alternative Text on Images
**WCAG Criterion:** 1.1.1 Non-text Content | **axe-core Rule:** `image-alt` | **Severity:** Critical
Meaningful images without usable text alternatives can prevent screen-reader users from understanding products or content. Decorative images should instead use an empty alternative, and functional icons need an accessible control name. Inspect both the stored metadata and the published theme output.
**Manual fix:** In your Liquid template, ensure image tags include the alt attribute:
```liquid
{% assign img_alt = image.alt | escape | default: product.title | escape %}
```
**AccessComply handling:** Eligible missing-alt findings may be reported on reached pages. AI-assisted description or template candidates are limited to supported paths and plan entitlements, require merchant review, and must be verified in the published storefront.
## 2. Insufficient Color Contrast
**WCAG Criterion:** 1.4.3 Contrast (Minimum) | **axe-core Rule:** `color-contrast` | **Severity:** Serious
Text that does not meet the 4.5:1 contrast ratio against its background is difficult or impossible to read for users with low vision or color deficiencies. This violation frequently appears in sale badges, footer text, placeholder text, and secondary navigation links.
**Manual fix:** Adjust the color values in your CSS. For example, change light gray text on a white background from `color: #999` to `color: #595959` to achieve 4.5:1 against white.
**AccessComply handling:** A safely source-mapped first-party color candidate may be proposed for merchant approval. Shared variables, imagery, component states, and brand decisions still require manual review and post-change testing.
## 3. Missing Form Labels
**WCAG Criterion:** 1.3.1 Info and Relationships | **axe-core Rule:** `label` | **Severity:** Critical
Form inputs without associated labels are announced as "edit text" by screen readers with no indication of what information to enter. This is especially problematic in checkout, account login, and newsletter signup forms.
**Manual fix:** Wrap each input in a label or use the `for` attribute:
```html
```
**AccessComply handling:** Automated rules may report eligible unlabeled controls. Selecting accurate label text and changing first- or third-party markup requires source ownership, safe mapping, merchant approval, and manual form-flow testing.
## 4. Icon Buttons Without Accessible Names
**WCAG Criterion:** 4.1.2 Name, Role, Value | **axe-core Rule:** `button-name` | **Severity:** Critical
Cart icons, search icons, and hamburger menus that contain only an SVG icon with no text alternative announce as "button" to screen readers — providing no context. Users with visual impairments cannot tell what the button does.
**Manual fix:** Add `aria-label` to icon buttons and `aria-hidden` to the decorative SVG:
```html
```
**AccessComply handling:** Automated rules may report eligible unnamed controls. The correct accessible name and mechanism require contextual review; third-party app controls usually require vendor coordination.
## 5. Missing Skip Navigation
**WCAG Criterion:** 2.4.1 Bypass Blocks | **axe-core Rule:** `bypass` | **Severity:** Serious
Without a skip navigation link, keyboard users must tab through your entire header — logo, navigation links, account icon, cart icon — on every page before reaching the main content. For stores with extensive navigation, this creates a frustrating barrier.
**Manual fix:** Add a skip link as the first element in `layout/theme.liquid`:
```liquid
Skip to main content
```
With CSS to show it on focus:
```css
.skip-link {
position: absolute;
top: -40px;
left: 0;
background: #000;
color: #fff;
padding: 8px 16px;
z-index: 9999;
text-decoration: none;
}
.skip-link:focus {
top: 0;
}
```
Add the target ID to your main content section: ``.
**AccessComply handling:** A skip-link candidate may be offered when the relevant first-party template and target are safely source-mapped. A merchant must approve the change and verify it with keyboard and assistive technology.
## 6. Missing Page Language
**WCAG Criterion:** 3.1.1 Language of Page | **axe-core Rule:** `html-has-lang` | **Severity:** Serious
Screen readers use the `lang` attribute on the `` element to determine which language rules and pronunciation to use. Missing or incorrect language attributes cause screen readers to mispronounce content, which is particularly severe for non-English stores.
**Manual fix:** In `layout/theme.liquid`, ensure:
```liquid
```
The `request.locale.iso_code` Liquid variable provides the correct ISO 639-1 language code (e.g., `en`, `fr`, `de`) based on the active store locale.
**AccessComply handling:** Missing or invalid page-language attributes are automated candidates; the actual locale and multilingual behavior must be verified before a supported source change.
## 7. Duplicate IDs
**WCAG Criterion:** 4.1.1 Parsing | **axe-core Rule:** `duplicate-id` | **Severity:** Serious
When the same `id` attribute value appears multiple times on a page, ARIA attributes that reference those IDs (like `aria-labelledby` and `aria-describedby`) break. Screen readers and assistive technologies rely on unique IDs to build accurate accessibility trees.
Repeated sections or custom product grids can generate duplicate IDs when a template does not include a stable unique suffix. Confirm whether any ID reference is ambiguous before editing the source.
**Manual fix:** In Liquid templates that generate IDs dynamically, include a unique identifier:
```liquid
```
**AccessComply handling:** Automated rules may report eligible duplicate-ID candidates. Changing IDs can break labels, descriptions, scripts, deep links, and app integrations, so remediation needs dependency review and post-change testing.
## 8. Missing Focus Indicators
**WCAG Criterion:** 2.4.7 Focus Visible | **axe-core Rule:** `focus-visible` | **Severity:** Serious
Custom theme or app CSS can suppress the browser focus ring with `outline: none` or `outline: 0`. If no visible replacement is supplied, keyboard users may not be able to see which element is focused.
**Manual fix:** Remove `outline: none` from your CSS or replace it with a visible custom focus style:
```css
/* Remove this: */
*:focus { outline: none; }
/* Add this instead: */
*:focus-visible {
outline: 2px solid #F97316;
outline-offset: 2px;
border-radius: 2px;
}
```
**AccessComply handling:** Eligible source-mapped focus-style candidates may be proposed, but contrast, area, clipping, forced-colors behavior, and component-specific states need manual verification.
## 9. Missing Frame Titles
**WCAG Criterion:** 4.1.2 Name, Role, Value | **axe-core Rule:** `frame-title` | **Severity:** Serious
Inline frames (`
```
**AccessComply handling:** An automated rule may report untitled frames on reached pages. The correct title and ability to change app-owned embeds require manual or vendor review.
## 10. Table Structure Issues
**WCAG Criterion:** 1.3.1 Info and Relationships | **axe-core Rule:** `td-headers-attr` | **Severity:** Serious
Data tables without correctly associated headers can be difficult to understand with a screen reader. Size charts, comparison tables, and specification sheets are useful places to inspect, including responsive or app-rendered versions.
**Manual fix:** Add `
` for column headers and `
` for row headers:
```html
Size
Chest (in)
Waist (in)
S
34-36
28-30
```
**AccessComply handling:** Automated rules may flag structural candidates, but identifying true headers and relationships requires understanding the data. Treat this as manual content review unless the source mapping and semantics are unambiguous.
## Automating vs. Manual Fixes
Some first-party findings above may be eligible for a supported, safely source-mapped candidate. Eligibility is not a promise that a change is safe or sufficient. Complex form flows, third-party widgets, documents, captions, and custom interactive components need developer, merchant, specialist, or vendor review.
An AccessComply scan can report eligible automated findings and sample locations on public pages and states it reaches. It cannot determine every issue, route, dynamic state, or manual-only requirement, and a proposed change still needs approval and post-change verification.
## Further Reading
- [WCAG 2.1 AA Compliance Checklist for Shopify Store Owners](/blog/wcag-21-aa-checklist-shopify)
- [How to Fix Shopify Accessibility Issues Without Hiring a Developer](/blog/fix-accessibility-without-developer)
- [Shopify Dawn Theme Accessibility Issues: Common WCAG Violations and How to Fix Them](/blog/shopify-dawn-theme-accessibility-issues)
- [ADA Lawsuits Against Ecommerce Stores: 2025–2026 Statistics](/blog/ada-lawsuits-ecommerce)
---
## Shopify Accessibility Without a Developer: What Merchants Can Safely Do
URL: https://accesscomply.com/blog/fix-accessibility-without-developer
Excerpt: A practical split between merchant-editable content, eligible app-assisted candidates, and work that still needs a developer or accessibility specialist.
You do not need a developer for every accessibility improvement. You also should not let a “no-code” promise push unsafe or judgment-heavy changes into production.
## Work merchants can often do in Shopify admin
- Write and review useful text alternatives for meaningful product images.
- Mark truly decorative imagery appropriately through supported theme settings.
- Improve link, button, heading, instruction, and error-message wording.
- Review theme color settings with a contrast checker across real states.
- Add captions, transcripts, and accessible document alternatives.
- Publish an accurate accessibility statement and feedback channel.
These tasks still require judgment. For example, an alt attribute can exist and still be misleading or redundant.
## Where app-assisted remediation can help
AccessComply checks eligible automated rules on storefront pages reached within the reported scan scope. If a finding can be mapped safely to a supported theme or Shopify content path, the app can present a candidate for merchant approval.
Supported writes create restore records and receive a post-change check. Only confirmed findings are marked resolved. A theme edit remains only in the modified theme until overwritten and does not transfer automatically to another theme.
Availability depends on the exact theme, source mapping, app output, entitlement, and current storefront state. A category name such as “contrast” or “form label” is not a promise that every instance can be fixed automatically.
## When to bring in a developer or specialist
- Custom menus, dialogs, carousels, swatches, and focus management.
- Third-party app or checkout-extension output.
- Authenticated customer journeys and complex error recovery.
- Screen-reader and mobile assistive-technology testing.
- PDFs, video, audio, and document remediation.
- Content meaning, reading order, and cognitive accessibility.
- Procurement deliverables or a comprehensive independent audit.
- Legal questions, complaints, or demand letters.
## Safe workflow
1. Define representative customer journeys and current theme/app state.
2. Run automated checks and record the exact page scope.
3. Separate merchant-content work, eligible app candidates, developer work, and specialist work.
4. Review every proposed production change.
5. Verify the served storefront, not only the code diff.
6. Test critical journeys manually with keyboard and assistive technology.
7. Track unresolved work and repeat after store changes.
AccessComply’s installed Free plan currently includes three app scans per calendar month and three eligible deterministic fixes per rolling 30 days. Paid plans add broader entitlements, monitoring, and reports. See [pricing](/pricing) for current terms.
No app, developer, or single dated audit guarantees ADA, EAA, or WCAG compliance. Start with a [free automated scan](/), then choose people and tools based on the uncovered work.
---
## Gil v Winn-Dixie: The 2021 Panel Opinion Was Vacated as Moot
URL: https://accesscomply.com/blog/gil-v-winn-dixie-shopify-lessons
Excerpt: An Eleventh Circuit panel issued a website-accessibility opinion in April 2021, then granted rehearing, vacated that opinion and the underlying judgment, and dismissed the appeal as moot in December 2021. The vacated panel opinion is not binding precedent.
Gil v Winn-Dixie Stores, Inc. is often summarized using an April 2021 Eleventh Circuit panel opinion. That summary is incomplete: on 28 December 2021, the court granted rehearing, held the appeal moot, **vacated its earlier opinion and the underlying judgment**, dismissed the appeal, and remanded for dismissal. A vacated opinion is not binding precedent.
On rehearing, the Eleventh Circuit vacated its opinion and the underlying judgment, dismissed the appeal, and remanded for dismissal because the case was moot. Read the December 2021 order before relying on quotations from the vacated April panel opinion.
## The facts
Juan Carlos Gil is a Cuban-American Florida resident who has cerebral palsy and is legally blind. He uses screen-reader software (JAWS) to navigate the web. In 2016 he sued Winn-Dixie, a large grocery-store chain operating physical stores throughout the southeastern United States, alleging that winndixie.com was inaccessible to him as a screen-reader user.
Specifically, Gil alleged he could not use the website to:
- Refill his prescriptions for in-store pickup.
- Access the digital coupons that were available only on the website.
- Find store locations and hours in a screen-reader-accessible format.
Gil could not complete those tasks at the website level, so he could not access services that were available *only* through the website — even though Winn-Dixie\'s physical stores were accessible.
## The 2017 trial-court verdict
The case went to a bench trial in the Southern District of Florida. Judge Robert Scola Jr. ruled for Gil. The court ordered Winn-Dixie to:
- Make its website conform to WCAG 2.0 Level AA.
- Implement an accessibility-policy training program for its web developers and content vendors.
- Set up ongoing testing and a feedback mechanism for users with disabilities.
The judgment became part of the developing website-accessibility case law, but later procedural events are essential to understanding its status.
## The April 2021 panel opinion
Winn-Dixie appealed. In April 2021 the Eleventh Circuit reversed the district-court judgment.
The Eleventh Circuit\'s reasoning rested on textual interpretation of ADA Title III\'s statutory definition of "place of public accommodation". The list in the statute (12 enumerated categories) consists entirely of physical locations: "an inn, hotel, motel," "a restaurant," "a hardware store," etc. Reading the list as the legislature wrote it, the court concluded that "place" means a physical place — and a website is not a physical place.
The court further held that the website was not a "service" of Winn-Dixie\'s physical stores in the relevant sense, because the website itself was not the conduit for accessing the in-store goods and services in a way that would make its inaccessibility a denial of equal access to those goods and services.
The now-vacated panel opinion reasoned that:
- The ruling was an interpretation of the statutory text, not a policy preference. Congress could amend the ADA to explicitly reach websites at any time.
- The ruling did not foreclose all ADA web-accessibility theories — only the theory that the website itself is a place of public accommodation. Plaintiffs could still bring claims under other theories where the website is a barrier to accessing physical-location goods or services.
- The ruling did not affect state-law claims (e.g. the California Unruh Civil Rights Act, where Robles also brought claims) which are independent of ADA Title III.
## The December 2021 vacatur controls the citation status
The court later granted rehearing because the injunction had expired and no formal declaratory relief remained. It vacated the April opinion and the underlying judgment, dismissed the appeal, and remanded for dismissal as moot. That means the April reasoning may be discussed as procedural history, but it cannot honestly be advertised as binding Eleventh Circuit precedent or used to assign a merchant a circuit-level risk score.
## What Gil means for Shopify merchants
For a Shopify merchant, the reliable lessons are procedural and operational:
1. **Check current controlling authority.** Do not rely on a quotation without checking whether the opinion was vacated, superseded, reheard, or appealed.
2. **Separate legal frameworks.** Federal Title III, state civil-rights law, and European accessibility rules have different coverage, exemptions, remedies, and geographic reach.
3. **Test the actual customer journey.** Product information, store services, forms, cart, account, and checkout can present barriers regardless of which legal theory applies.
4. **Keep claims factual.** Automated findings and AccessComply change records describe a tested scope and work performed; they do not establish legal compliance or a defense.
## Why the case became moot
The December 2021 order identifies the expiration of the injunction while the appeal was pending and the absence of a formal declaratory-relief award as the basis for mootness. It does not attribute mootness to a later bankruptcy. Read that two-page disposition together with any archived panel opinion.
## Further reading
- [Gil v Winn-Dixie — December 2021 order vacating the opinion and judgment as moot](https://law.justia.com/cases/federal/appellate-courts/ca11/17-13467/17-13467-2021-12-28.html)
- [Gil v Winn-Dixie — archived April 2021 panel opinion (vacated; not binding)](https://media.ca11.uscourts.gov/opinions/pub/files/201713467.pdf)
- [Andrews v Blick Art Materials, LLC — Eastern District of New York website-as-place-of-public-accommodation ruling (2017)](https://app.midpage.ai/case/andrews-v-blick-art-materials-7244752)
- [AccessComply: Robles v Domino\'s deep-dive](/blog/robles-v-dominos-shopify-lessons)
- [AccessComply: ADA lawsuits against ecommerce stores](/blog/ada-lawsuits-ecommerce)
- [AccessComply: How to respond to an ADA demand letter](/blog/ada-demand-letter-response-template)
---
## How Much Does a Shopify Accessibility Audit Cost?
URL: https://accesscomply.com/blog/how-much-does-shopify-accessibility-audit-cost
Excerpt: A quote-based budgeting guide for automated scans, independent manual audits, remediation, verification, monitoring, and legal review—without invented market averages.
The honest answer is that a Shopify accessibility audit has no trustworthy universal price. A five-template review, a full purchase-journey evaluation, and an enterprise engagement with documents, mobile assistive technology, retesting, and procurement deliverables are different services.
Ask qualified providers for a written scope and quote. This article does not invent consultant rates, settlement savings, or a return-on-investment guarantee.
## The six cost buckets
Build the budget from the work you actually need:
1. **Discovery and automated scanning** — representative routes, viewports, states, crawl exclusions, and machine-testable rules.
2. **Manual evaluation** — keyboard, screen reader, zoom, reflow, content meaning, error handling, and task completion.
3. **Remediation** — theme code, Shopify content, design, copy, media, documents, and third-party coordination.
4. **Verification and retesting** — the affected state after each change, plus regression checks on related journeys.
5. **Documentation** — finding details, evidence, remediation records, accessibility statement input, and any procurement deliverable.
6. **Ongoing monitoring** — changes to products, themes, apps, content, and customer journeys after the dated evaluation.
Legal review is a separate professional service when applicability, a demand letter, contract language, or a regulatory question is involved.
## What changes the quote
- Number of representative templates and unique components.
- Theme complexity and custom JavaScript interactions.
- Customer accounts, checkout extensions, localization, and market-specific states.
- Third-party apps and content the merchant cannot edit directly.
- PDFs, video, audio, and other non-HTML assets.
- Desktop and mobile assistive-technology combinations.
- Whether the provider fixes issues or only reports them.
- Number of retest rounds and expected response time.
- Required ACR, procurement, or governance deliverables.
- Access to development environments, design files, and engineering support.
## Questions for an audit proposal
- Which pages, templates, states, and user journeys are in scope?
- Which WCAG version and conformance level guide the evaluation?
- Which browser and assistive-technology combinations are included?
- How are third-party content, checkout, media, and documents handled?
- Does the deliverable distinguish automated from manually verified findings?
- Are false positives, duplicate patterns, and severity reviewed by a person?
- Is remediation included, and who owns the code changes?
- How many retests are included?
- What does the provider explicitly exclude?
- Does the provider promise an outcome it cannot guarantee?
## Where AccessComply fits
AccessComply offers a free public automated scan and an installed Free plan with three app scans per calendar month plus three eligible deterministic fixes per rolling 30 days. Paid monthly plans are Starter at $29, Shield at $79, and Citadel at $199; optional annual Shopify billing is available. See [current pricing](/pricing) for exact entitlements and annual amounts.
The product checks eligible automated rules on discoverable pages within its reported scope. For safely source-mapped candidates, a merchant approves the candidate or operation before a supported write. Supported writes create restore records and receive a post-change check.
AccessComply does not replace an independent manual audit. It cannot establish WCAG, ADA, or EAA compliance and cannot promise that every theme, third-party component, document, state, or customer journey is covered.
## A sensible purchasing sequence
1. Run an automated baseline and record its exact scope.
2. Identify the highest-value customer journeys and representative templates.
3. Obtain written manual-audit and remediation quotes for the uncovered work.
4. Separate product subscription, professional audit, remediation, and legal review in the budget.
5. Require retesting and define who owns each unresolved item.
6. Keep monitoring after publication because a dated audit does not cover future storefront changes.
Use the [accessibility response budget worksheet](/tools/lawsuit-cost-calculator) to total your own provider estimates. It is a planning tool, not a forecast of legal exposure.
---
## How to Add Alt Text to Shopify Product Images: 4 Methods (Manual + Bulk + AI)
URL: https://accesscomply.com/blog/how-to-add-alt-text-shopify-product-images
Excerpt: Add reviewed alt text to Shopify product images through admin, current supported bulk tools, theme-level Liquid passthrough, or eligible AI-assisted candidates. Includes WCAG guidance and verification boundaries.
Missing or unhelpful text alternatives can stop a customer from understanding a product image. Shopify supports image alt-text metadata, and merchants can use admin, supported bulk workflows, theme rendering, or reviewed AI-assisted candidates depending on current platform and plan capabilities. This guide covers practical options and the verification each one still needs.
WCAG 2.1 Success Criterion 1.1.1 (Non-text Content) at Level A requires every meaningful image to have descriptive alt text. Decorative images use `alt=""`. On Shopify, alt text is per-image admin metadata that the theme passes through to `` in the rendered storefront HTML.
## Why alt text matters — three layers
### 1. Accessibility (the original purpose)
Screen readers — JAWS, NVDA, VoiceOver, TalkBack — convert on-screen content to synthesized speech for blind and low-vision users. When a screen reader encounters `` without an `alt` attribute, it announces "image" or reads the filename. When it encounters ``, it skips silently. When it encounters ``, it announces the description as if it were the visual content.
For ecommerce specifically, missing alt text on product photos is functionally a denial of access — the screen-reader user cannot tell what they are buying.
### 2. ADA + EAA legal exposure
Missing text alternatives are machine-testable in many cases and may appear in accessibility complaints or evaluations. An automated result is a technical finding, not a legal conclusion; it also cannot judge whether existing alt text conveys equivalent meaning.
The DOJ's 2024 web rule applies to state and local governments under ADA Title II; it does not create a technical standard for private ecommerce under Title III. *Robles v. Domino's Pizza* addressed a website and app alleged to impede access to a physical restaurant's goods and services in the Ninth Circuit, so it should not be generalized into a nationwide rule for every online store. EU and member-state obligations also depend on scope, implementation, exemptions, and the service offered. Use WCAG as a technical baseline and obtain qualified advice for legal applicability.
### 3. SEO + AI shopping discovery
Google Image Search uses alt text alongside the surrounding HTML, file name, and structured-data Product schema to understand what an image depicts. Alt text is one signal search systems can read; it is not a guaranteed path into any AI shopping result, and Shopify syndicates product data to agentic-commerce surfaces from your structured catalog rather than from rendered page markup.
Descriptive alt text can improve the information available to customers and search systems, but it does not by itself establish accessibility conformance or guarantee discovery.
## What "good alt text" looks like
The W3C\'s alt-text decision tree breaks images into four categories:
- **Functional**: describes the function, not the visual. A magnifying-glass icon button → `alt="Open search"`, not `alt="magnifying glass"`.
- **Informative product photo**: describes the product. → `alt="Navy linen wide-leg trousers, model wearing size M"`.
- **Decorative**: adds no information beyond visual flourish. → `alt=""` (empty, intentional). Screen readers skip silently.
- **Complex**: charts, infographics, sizing guides need a longer description in adjacent text plus a short alt.
For Shopify product images specifically:
- Include the product name + a visually-distinguishing detail.
- Avoid filler ("image of...", "photo of...") — screen readers already announce that it is an image.
- Avoid stuffing keywords for SEO — Google penalizes this and screen-reader users get a worse experience.
- Match length to purpose and complexity; concise text is useful, but there is no universal word-count rule.
## Method 1 — Per-image, in the Shopify admin
Best for: small catalogs, one-off image updates, the merchant editing manually.
1. Log in to Shopify admin.
2. Open **Products** → click the product → scroll to **Media**.
3. Click the image. The image preview opens.
4. Click **Edit alt text** (button under the image).
5. Type the alt text. Save.
Shopify stores alt-text metadata for product media, but a custom theme or app must still render the value correctly. Inspect the published HTML. For programmatic updates, use Shopify's current Admin GraphQL documentation and supported media mutations rather than relying on a mutation name copied from an older article.
## Method 2 — Bulk via Shopify Products CSV
Best for: catalogs of 50+ products, one-time backfill, no app installs.
1. **Shopify admin → Products → Export**. Choose "All products" + "Plain CSV file for Excel, Numbers, etc."
2. Open the CSV. The column you want is `Image Alt Text` (column AC in the standard export, may shift in future Shopify schema changes).
3. Edit the alt-text column. Tip: use a spreadsheet formula like `="Navy "&B2&", model wearing size M"` to template alt text from the existing product title column.
4. Save the CSV.
5. **Shopify admin → Products → Import**. Choose the edited CSV and check "Overwrite any current products that have the same handle".
6. Shopify processes the import; alt text updates on every image with a matching `Image Position` and `Handle`.
For a large catalog, confirm current Shopify limits and behavior, test a small reversible batch, preserve identifiers, and verify both admin metadata and published output before scaling the import.
## Method 3 — Bulk via Matrixify (third-party app)
Best for: catalogs that need capabilities beyond the current native workflow, after reviewing the app's present fields, permissions, pricing, and rollback behavior.
[Matrixify](https://matrixify.app/) is one third-party option. Verify its current documentation, supported media and locale fields, import matching rules, pricing, and trial availability before using it. Run a small reversible test and review generated or templated descriptions rather than assuming its workflow matches Shopify's native import.
## Method 4 — Reviewed AI-assisted candidates (AccessComply)
Best for: eligible supported content paths where a merchant can review description candidates before an approved write.
AccessComply can report eligible automated image findings on public pages and states it reaches. When a supported Shopify content path and current plan entitlement apply, it may generate a description candidate for merchant review, apply an approved change, record the affected value where supported, and run a post-change check. It does not guarantee that every image was reached, that generated text is accurate, or that a technical record proves legal compliance. Decorative intent, functional purpose, complex images, localization, and app-owned output still require human or vendor review.
## The Liquid template — what your theme should be doing
A product-image template commonly passes through reviewed media alt text. Inspect the installed theme and adapt the following illustrative pattern:
```liquid
{% assign image = product.featured_image %}
```
The key line is `alt="{{ image.alt | escape | default: product.title }}"`. This:
1. Reads the alt text from the image record.
2. Escapes any HTML to prevent XSS.
3. Shows a product-title fallback as a candidate only; it still needs review and may duplicate nearby text or fail to describe the image.
If a meaningful image is rendered with an empty or missing alternative, stored admin text alone does not solve the customer barrier. AccessComply may report the reached-page finding and, when the first-party source is safely mapped, propose a merchant-approved change through a supported theme path. App-owned markup and ambiguous image purpose require manual or vendor review.
## Common alt-text mistakes on Shopify
- **Filename as alt text**: `alt="IMG_4567.JPG"` — happens when the theme falls back to the file name. Always set explicit alt text.
- **Keyword stuffing**: `alt="navy trousers buy navy trousers cheap navy trousers Shopify"` — it is unhelpful for screen-reader users and should not replace an equivalent description.
- **Repeating the product title verbatim**: technically valid but adds no information for screen-reader users beyond what the surrounding HTML already provides. Add a visually-distinguishing detail.
- **`alt="image"` or `alt="photo"`**: zero information — equivalent to no alt text from the screen-reader user\'s perspective.
- **Different alt text on every variant of the same product**: typically wrong unless the variants visually differ. Use the product-level alt text and let variants inherit unless visually different.
- **Decorative-image alt text**: spacer GIFs, ornamental flourishes, and brand-mark icons next to a labeled link should use `alt=""`, not a description. Screen readers skip silently.
## Quick checklist
- [ ] Every product\'s featured image has alt text describing the product.
- [ ] Variant-specific images that look different from the master have variant-specific alt text.
- [ ] Decorative images (background flourishes, spacer GIFs, ornamental icons) use `alt=""`.
- [ ] Functional images (icon-only buttons) use `aria-label` on the button + `aria-hidden="true"` on the inner SVG.
- [ ] Theme `` tags read `image.alt` not hardcoded strings.
- [ ] The accessibility statement on `/pages/accessibility-statement` documents the alt-text remediation effort.
## Verify your work — free scan
Run a free public [AccessComply scan](/) to sample eligible automated image findings across public, discoverable pages and states it reaches, subject to crawler safety and time limits. It does not guarantee every image or state was reached. Check the [pricing page](/pricing) for current scan, remediation, and AI-assisted entitlements, then manually review descriptions and the published storefront.
## Further reading
- [W3C — Alt text decision tree](https://www.w3.org/WAI/tutorials/images/decision-tree/)
- [WCAG 2.1 SC 1.1.1 Non-text Content](/wcag/1-1-1)
- [WCAG glossary — alt text](/glossary/alt-text)
- [WCAG glossary — empty alt attribute](/glossary/alt-text-empty)
- [Shopify Help — Add alt text to product images](https://help.shopify.com/en/manual/products/product-media/add-alt-text)
- [Shopify GraphQL — productMedia mutation reference](https://shopify.dev/docs/api/admin-graphql/latest/mutations/productCreateMedia)
- [AccessComply — Why accessibility overlays don't work](/blog/accessibility-overlay-widgets-dont-work)
- [AccessComply — How to fix accessibility issues on Shopify](/blog/fix-accessibility-issues-shopify)
- [AccessComply — WCAG 2.1 AA checklist for Shopify](/blog/wcag-21-aa-checklist-shopify)
---
## Isonomy vs AccessComply: A Shopify Accessibility Due-Diligence Guide
URL: https://accesscomply.com/blog/isonomy-vs-accesscomply
Excerpt: Compare Isonomy’s current vendor-described offering with AccessComply’s documented Shopify workflow using a live test, current plan documents, and clear manual-review boundaries.
Isonomy and AccessComply may appear in the same Shopify App Store search, but a useful comparison requires current evidence about what each product does today.
Confirm Isonomy’s current rating, pricing, architecture, services, and limits from its current listing and documentation. This article intentionally avoids frozen competitor statistics and unverified implementation claims.
## AccessComply’s documented workflow
AccessComply scans discoverable public storefront pages within the reported page scope and crawler limits. It reports eligible automated-rule findings. When a finding can be mapped safely to a supported Shopify theme or content path, the app can present a candidate for merchant approval.
Supported writes create restore records and run a post-change check. Only confirmed findings are marked resolved. Unsupported, stale, risky, third-party, and judgment-heavy work remains for manual review.
AccessComply does not support every theme pattern, does not perform a complete human WCAG audit, and does not guarantee ADA, EAA, or WCAG compliance.
## What to ask Isonomy and AccessComply
| Question | Why it matters |
|---|---|
| Which pages and UI states are scanned? | A public crawl cannot reach every customer, checkout, dialog, or third-party state. |
| What is the exact change mechanism? | Source, Shopify content, runtime output, and recommendations have different lifecycles. |
| Can the merchant preview and approve it? | Production writes need a clear scope and change-control boundary. |
| What happens when source changed meanwhile? | Stale candidates should fail closed rather than overwrite newer merchant work. |
| How is the result verified? | A targeted automated check is useful but not a full conformance audit. |
| Is restore automatic? | Unattended restore can overwrite later work; AccessComply requires merchant confirmation. |
| What remains manual? | Content meaning, complex interactions, third-party apps, media, and documents often require people. |
| What happens on uninstall or theme switch? | Ask about source, content, runtime behavior, stored data, and newly published themes separately. |
## AccessComply persistence details
Supported theme changes remain only in the specific modified theme until another edit or update overwrites them. They do not automatically transfer to a different published theme. Supported Shopify content changes remain in the underlying resource. Optional Theme App Extension behavior stops when the app or embed is removed.
Those details are more useful than the blanket phrase “fixes persist.” Ask Isonomy for the equivalent product-lifecycle explanation.
## Pricing
AccessComply currently offers Free, Starter at $29 per month, Shield at $79 per month, and Citadel at $199 per month, with optional annual Shopify billing for paid plans. Check [pricing](/pricing) for current limits and annual amounts.
Verify Isonomy’s current pricing directly. Do not compare a widget, automated scan, source-change workflow, and managed audit as if they were interchangeable.
## Decision rule
Use a development theme, request a live demonstration, inspect the before-and-after storefront, review exclusions, and manually test critical journeys. Choose the product and service mix that makes the remaining work explicit instead of promising a complete outcome.
You can [run an AccessComply automated scan](/) without signup before comparing current vendor proposals.
---
## NAD v Netflix: How a 2012 Caption Lawsuit Established That Title III Reaches Online-Only Services
URL: https://accesscomply.com/blog/nad-v-netflix-shopify-lessons
Excerpt: In 2012 the District of Massachusetts denied Netflix\
National Association of the Deaf v Netflix, Inc. is a 2012 District of Massachusetts decision denying a motion to dismiss an ADA Title III claim against an online streaming service. It applied First Circuit precedent and is not a nationwide appellate holding. Courts have taken different approaches to online-only services, so its facts should not be converted into a universal legal conclusion for every Shopify business.
"The legislative history of the ADA makes clear that Congress intended the ADA to adapt to changes in technology. Now that the Internet plays such a critical role in the personal and professional lives of Americans, excluding disabled persons from access to covered entities that use it as their principal means of reaching the public would defeat the purpose of this important civil rights legislation." — National Association of the Deaf v Netflix, Inc., 869 F. Supp. 2d 196 (D. Mass. 2012), Judge Michael A. Ponsor
## The facts
The plaintiffs were the National Association of the Deaf (NAD), the Western Massachusetts Association of the Deaf and Hearing-Impaired, and individual deaf and hard-of-hearing Netflix subscribers. They alleged that Netflix's "Watch Instantly" streaming service — at the time, Netflix's growing online-only product, distinct from its DVD-by-mail business — failed to provide closed captions on the majority of streaming titles, in violation of ADA Title III.
The case was filed in June 2011 in the District of Massachusetts. Netflix moved to dismiss on two main grounds:
1. **No physical place.** Netflix argued ADA Title III applies only to physical places of public accommodation, and Watch Instantly has no brick-and-mortar location.
2. **CVAA preemption.** Netflix argued that Congress's 2010 Twenty-First Century Communications and Video Accessibility Act (CVAA) — which addresses captions on internet video that previously aired on television — preempted the ADA claim.
## The ruling
Judge Michael A. Ponsor denied the motion to dismiss in a 24-page opinion in June 2012, becoming the first federal court to squarely hold that a digital-only service can be an ADA Title III "place of public accommodation". The reasoning rested on four points:
### 1. First Circuit precedent supports broad coverage
The First Circuit had previously held in *Carparts Distribution Center, Inc. v Automotive Wholesaler's Association of New England* (1994) that ADA Title III is not limited to physical structures. *Carparts* involved a health-benefits plan administered remotely; the court held the plan administrator was a "public accommodation" within the statutory list. *NAD v Netflix* extended that reasoning to streaming media.
### 2. The statutory list is illustrative, not exhaustive
Like Judge Weinstein in *Andrews v Blick* five years later, Judge Ponsor read the 12 categories in 42 U.S.C. § 12181(7) as a non-exhaustive list of examples. Netflix's Watch Instantly service fit naturally within categories like "place of exhibition or entertainment", "place of recreation", and "service establishment" — even though the service was delivered over the internet rather than at a physical theater.
### 3. CVAA does not preempt the ADA
The court rejected Netflix's preemption argument. The CVAA addresses captions on internet video that previously aired on television (e.g., a streamed rebroadcast of a network show). Netflix's library included substantial original and made-for-streaming content the CVAA did not reach, and the CVAA contained no language indicating it was the exclusive remedy for online captioning. The ADA and CVAA were held complementary, not preemptive.
### 4. Discrimination on the basis of disability
The plaintiffs' core allegation — that millions of deaf and hard-of-hearing subscribers paid the same monthly fee but received a materially inferior product because the bulk of streaming titles lacked captions — stated a textbook ADA Title III "full and equal enjoyment" claim under 42 U.S.C. § 12182(a).
## The consent decree
Four months after the motion-to-dismiss denial, on **October 9, 2012**, the parties entered a consent decree resolving the case. The decree's headline terms:
- **100% captioning by September 2014.** Netflix agreed to caption every streaming title in its library by the end of September 2014.
- **48-hour SLA on new content.** Netflix agreed that any new title added to the streaming library after May 2013 would be captioned within 48 hours of the title becoming available; by 2014 the SLA tightened to "at the time of streaming".
- **$755,000 in attorneys' fees.** Netflix paid the NAD plaintiffs' attorneys' fees but no monetary damages to the class.
- **Ongoing reporting.** Netflix submitted compliance reports to NAD throughout the consent-decree term.
## How NAD v Netflix differs from Robles, Gil, and Andrews
These matters arose in different courts, procedural postures, and factual settings. NAD v Netflix and Andrews v Blick were district-court decisions; Robles was a Ninth Circuit decision involving a connection to physical restaurants; and later Winn-Dixie litigation had its own procedural history. Binding effect depends on the jurisdiction and level of court. Verify the current status of any cited decision before relying on it for legal analysis.
## What NAD v Netflix means for Shopify merchants
### 1. Online-only coverage requires a jurisdiction-specific analysis
Digital downloads, online courses, subscriptions, and content libraries resemble some aspects of the service discussed in NAD v Netflix. But Title III coverage and available claims can differ by circuit, state law, business facts, and service model. Make the customer experience accessible while qualified counsel assesses any legal question.
### 2. Evaluate prerecorded synchronized media carefully
WCAG 2.1 SC 1.2.2 (Captions, Prerecorded) at Level A addresses captions for prerecorded synchronized media, subject to its media-alternative exception. Review automated captions for accuracy, speaker identification, meaningful sounds, timing, and completeness; a player exposing a captions control does not prove the captions are usable.
### 3. Live and audio-only content also have obligations
WCAG 2.1 SC 1.2.4 (Captions, Live) at Level AA covers live audio in synchronized media — a livestreamed product launch, a live shopping event. WCAG 2.1 SC 1.2.1 covers prerecorded audio-only content (a podcast embed); transcripts satisfy 1.2.1.
### 4. Do not treat one media rule as proof of broader compliance
The court rejected Netflix's CVAA preemption argument at the motion-to-dismiss stage. That does not let a marketing article determine which federal or state duties apply to another merchant. Inventory the media, follow the applicable WCAG criteria as an engineering target, and verify legal obligations separately.
### 5. The consent-decree amount is not a merchant cost model
The decree included case-specific fee and captioning terms. It does not establish a typical Shopify settlement, likely legal spend, or guaranteed savings from a particular remediation timeline. The durable product lesson is simpler: accurate captions improve access and are easier to plan before a rushed response.
## Further reading
- [National Association of the Deaf v Netflix, Inc., 869 F. Supp. 2d 196 (D. Mass. 2012) — full opinion](https://www.leagle.com/decision/infdco20120620b47)
- [Carparts Distribution Center v Automotive Wholesalers, 37 F.3d 12 (1st Cir. 1994)](https://law.justia.com/cases/federal/appellate-courts/F3/37/12/509454/)
- [42 U.S.C. § 12181 — ADA Title III definitions](https://www.law.cornell.edu/uscode/text/42/12181)
- [WCAG 2.1 SC 1.2.2 Captions (Prerecorded)](/wcag/1-2-2)
- [AccessComply: Robles v Domino's deep-dive](/blog/robles-v-dominos-shopify-lessons)
- [AccessComply: Andrews v Blick — websites as places of public accommodation](/blog/andrews-v-blick-shopify-lessons)
- [AccessComply: Gil v Winn-Dixie — Eleventh Circuit reversal](/blog/gil-v-winn-dixie-shopify-lessons)
---
## NFB v Target: An Early ADA Web-Accessibility Class Action and Its Lessons
URL: https://accesscomply.com/blog/nfb-v-target-shopify-lessons
Excerpt: In 2008 the National Federation of the Blind and Target Corporation resolved a class-action accessibility lawsuit with a $6 million settlement fund and accessibility commitments. This case study separates the documented terms from broader legal conclusions.
National Federation of the Blind v Target Corporation is an important early US ecommerce-accessibility case. Its motion-to-dismiss and class-certification history, followed by a 2008 settlement with a $6 million class fund and accessibility commitments, is useful context. It is not a universal template for later cases, and this article is not legal advice.
The cited NFB summary describes a $6 million class settlement fund, separate attorneys' fees, accessibility certification work, and monitoring during the agreement. Those are terms of this settlement, not a floor or forecast for another dispute.
## The procedural history
The National Federation of the Blind, the country\'s largest blind-advocacy membership organization, has long pursued litigation as a strategy when other channels fail. By 2006 NFB members had documented for several years that target.com was not accessible to screen-reader users. The site lacked alt text on product images, did not expose form labels to assistive technology, did not handle keyboard-only navigation, and did not announce dynamic content updates.
NFB and three individual plaintiffs filed suit in February 2006 in the Northern District of California against Target Corporation. The complaint alleged violations of:
- Title III of the Americans with Disabilities Act (federal).
- The California Unruh Civil Rights Act (state).
- The California Disabled Persons Act (state).
Target moved to dismiss on multiple theories, including the argument that target.com was not a "place of public accommodation" within the meaning of ADA Title III. In September 2006 Judge Marilyn Hall Patel denied the motion to dismiss in significant part. The court held that the plaintiffs had stated a claim under ADA Title III to the extent that the website inaccessibility prevented access to the goods and services of Target\'s physical stores. The state-law claims survived in full.
The court certified a nationwide class for the ADA claim and a California subclass for the state-law claims in October 2007. Class certification — even though it was based on the trial court\'s ruling rather than an appellate decision — signaled to the plaintiff bar that ADA Title III website cases could survive past the motion-to-dismiss stage and proceed to discovery.
The parties entered into settlement negotiations in 2008 and announced terms in August of that year.
## The settlement terms
The settlement had three substantive components:
### 1. Monetary relief
Target paid $6 million into a settlement fund for class members. Individual class members who had attempted to use target.com between February 2003 and the settlement date were eligible for compensation from the fund. Attorneys\' fees were paid separately.
### 2. Technical compliance — the "NFB Nonvisual Accessibility Web Certification"
Target agreed that target.com would meet the technical accessibility standard then maintained by the NFB (now superseded by industry adoption of WCAG). The standard required, among other things:
- Alt text on every meaningful image.
- Programmatic labels on every form field.
- Keyboard operability for every interactive element.
- Skip-navigation links allowing screen-reader users to bypass repetitive navigation.
- Heading-structure semantic markup so screen readers could navigate the page hierarchy.
These items remain practical areas to include in a current storefront accessibility review.
### 3. Ongoing monitoring and reporting
Target agreed to engage independent third-party accessibility consultants on an ongoing basis to verify the site\'s continued compliance, and to submit periodic compliance reports during the settlement\'s term. Public reports of compliance status were also required.
## Why the case still matters
NFB v Target predated Robles by eleven years and predated WCAG 2.0\'s formal adoption by two. But it did three things that still shape the legal landscape:
1. **The court certified classes in this case.** That procedural result was based on the pleaded claims, record, and applicable law; it does not mean another ecommerce case will be certified.
2. **The settlement had a documented monetary component.** The $6 million fund describes this agreement and should not be used as a benchmark for another claim.
3. **Federal and California claims were pleaded together.** Available claims, standing, damages, defenses, and remedies depend on current law and case-specific facts. Qualified counsel should assess them.
## What Shopify merchants should take from NFB v Target
1. **Treat customer barriers as operational issues.** Test product discovery, variants, cart, account, and checkout-related handoffs with keyboard and assistive technology.
2. **Keep factual remediation records.** Preserve scan scope, manual-test notes, approvals, diffs, and post-change checks without presenting a tool log as proof of legal compliance.
3. **Review familiar technical patterns.** Text alternatives, form labels, keyboard operability, bypass mechanisms, and semantic structure remain useful review areas, while complete conformance also requires manual evaluation.
4. **Do not infer legal exposure from company size or this settlement.** If a complaint or demand arrives, preserve relevant evidence and obtain advice from qualified counsel in the applicable jurisdiction.
## Further reading
- [National Federation of the Blind: Target case archive](https://nfb.org/sites/default/files/images/nfb/publications/bm/bm09/bm0901/bm090111.htm)
- [Northern District of California court records, NFB v Target](https://dockets.justia.com/docket/california/candce/3:2006cv01802/175019)
- [California Unruh Civil Rights Act — text](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV§ionNum=51.)
- [AccessComply: Robles v Domino\'s deep-dive](/blog/robles-v-dominos-shopify-lessons)
- [AccessComply: Gil v Winn-Dixie Eleventh Circuit reversal](/blog/gil-v-winn-dixie-shopify-lessons)
- [AccessComply: How to respond to an ADA demand letter](/blog/ada-demand-letter-response-template)
---
## Restaurant Website Accessibility: Menus, Ordering, and Reservations
URL: https://accesscomply.com/blog/restaurant-website-ada-lawsuit
Excerpt: A practical Shopify guide to accessible menus, ordering, reservations, location details, media, and third-party services—without lawsuit predictions or invented settlement ranges.
Restaurant accessibility is about whether a customer can read the menu, understand allergens and prices, find a location, reserve a table, order food, and correct errors without relying on sight, a mouse, or one device configuration.
## Menus
Prefer semantic HTML for menu content. If a PDF is also provided, evaluate the PDF separately; a linked file is not made accessible by fixing the surrounding webpage. Avoid image-only menus, and make names, prices, descriptions, and allergen information available as text.
## Online ordering
Test the complete task: choose a location, configure an item, select required options, change quantities, apply a discount, review the cart, correct validation errors, and reach checkout. Names, states, focus movement, announcements, and error recovery all matter.
## Reservations and third-party widgets
Embedded reservation, delivery, loyalty, and map services may be outside the theme’s source-control path. The merchant still needs to test the customer experience, report barriers to the vendor, track remediation, and provide an accessible alternative where appropriate.
## Location and contact information
Provide addresses, hours, phone numbers, service notes, and directions as structured text. Do not rely only on a map, icon, color, or image. Ensure contact and feedback methods are keyboard and assistive-technology accessible.
## Media and promotions
Caption video with audio, review text alternatives, provide controls for motion and sound, and test promotional dialogs. A scanner can find some media markup issues but cannot judge caption accuracy or equivalent meaning.
## Response when a complaint arrives
Preserve the communication and relevant technical records, notify appropriate internal and insurance contacts, and consult qualified counsel promptly. Verify technical allegations carefully, coordinate evidence preservation, and remediate confirmed customer barriers through controlled change management.
Do not use an online settlement range, install a tool as proof of historical compliance, or send a generic legal response from a marketing article.
AccessComply can scan eligible automated rules on reachable storefront pages and present safely source-mapped candidates for merchant approval. Supported writes create restore records and receive post-change checks. Third-party, judgment-heavy, and unresolved work remains manual. None of this is legal advice or a compliance guarantee.
Run a [free automated scan](/), then manually test the actual menu, reservation, and ordering journeys.
---
## Robles v Domino\
URL: https://accesscomply.com/blog/robles-v-dominos-shopify-lessons
Excerpt: In 2019 the Ninth Circuit held that ADA Title III applied to Domino\
Robles v Domino\'s Pizza, LLC is an important Ninth Circuit ADA Title III website-accessibility decision. Its holding was specific: Domino\'s website and app connected customers to goods and services at Domino\'s physical restaurants. The opinion expressly declined to decide whether the ADA covers every business website, so merchants should not turn it into a nationwide rule for all ecommerce models.
"The ADA applies to Domino\'s website and app, which connect customers to the goods and services of Domino\'s physical restaurants. We need not decide whether the ADA covers the websites of all businesses... we hold only that the ADA applies to Domino\'s website and app." — Robles v Domino\'s Pizza, LLC, 913 F.3d 898 (9th Cir. 2019)
## The facts
Guillermo Robles is blind and uses screen-reader software. In 2016 he attempted to order a customized pizza from Domino\'s through both the company\'s website and its iOS mobile app. His complaint alleged that accessibility barriers prevented him from completing the transaction.
Robles filed suit in the Central District of California alleging violations of Title III of the Americans with Disabilities Act and California\'s Unruh Civil Rights Act.
## The arguments
Domino\'s moved to dismiss on two main theories:
**1. Lack of fair notice / due process.** Domino\'s argued that without specific Department of Justice regulations explaining what websites must do to comply with Title III, businesses had no fair warning of what was required. Imposing liability would violate due process.
**2. The "primary jurisdiction doctrine".** Domino\'s asked the court to stay the case until the DOJ issued regulations, on the theory that the agency had primary jurisdiction over the technical question.
The trial court agreed with Domino\'s and dismissed. Robles appealed to the Ninth Circuit.
## The Ninth Circuit ruling
The Ninth Circuit reversed. Its core reasoning:
1. **Statutory coverage is broad.** The ADA itself is the source of the legal duty. The statute prohibits discrimination against people with disabilities by "any place of public accommodation". Domino\'s restaurants are unquestionably places of public accommodation; the website and app connect customers to those restaurants; the ADA reaches that connection.
2. **The lack of regulations is not a fair-notice problem.** "The Constitution only requires that Domino\'s receive fair notice of its legal duties, not a blueprint for compliance." Domino\'s had been on notice that the ADA covers website-accessibility issues since at least the DOJ\'s 1996 guidance and a long line of district-court cases.
3. **The court did not make WCAG the exclusive legal standard.** The requested injunction referenced WCAG 2.0, but the Ninth Circuit left the precise remedy for the trial court and did not hold that one WCAG version is the only way to satisfy Title III.
4. **No primary-jurisdiction stay.** The court declined to wait for DOJ regulations. The legal duty exists in the statute itself; the absence of further rulemaking does not strip courts of authority to enforce it.
The Supreme Court denied certiorari on 7 October 2019. A denial of certiorari is not a ruling on the merits; it left the Ninth Circuit decision in place without adopting its reasoning nationwide.
## What happened next
The case returned to the trial court after certiorari was denied and was later resolved. That procedural history does not prove a nationwide rule, a particular remediation cost, or a predictable outcome for another merchant.
## What Robles means for Shopify merchants
Practical lessons for a Shopify accessibility program are narrower than the old legal extrapolation:
1. **Test the connected customer journey.** Product selection, store location information, ordering, cart, and checkout can be closely tied to goods or services offered at a physical location.
2. **Do not wait for a perfect technical regulation before removing known barriers.** Robles rejected Domino\'s due-process argument on the facts before the court.
3. **Use WCAG as an engineering framework, not an automatic legal conclusion.** Identify the exact version and evaluation scope, and combine automated checks with manual testing.
4. **Get jurisdiction-specific advice.** Circuit law, state statutes, business facts, physical nexus, and exemptions can materially change the analysis.
5. **Keep factual records.** A scan history, approved-change record, accessibility statement, and manual-test evidence can document work performed, but AccessComply does not create a legal defense or guarantee an outcome.
## Further reading
- [Robles v Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019) — full opinion](https://cdn.ca9.uscourts.gov/datastore/opinions/2019/01/15/17-55504.pdf)
- [Supreme Court order denying certiorari — Domino\'s Pizza v Robles, 140 S. Ct. 122 (2019)](https://www.supremecourt.gov/orders/courtorders/100719zor_8m58.pdf)
- [DOJ web accessibility guidance](https://www.ada.gov/resources/web-guidance/)
- [AccessComply: ADA Lawsuits Against Ecommerce Stores](/blog/ada-lawsuits-ecommerce)
- [AccessComply: How to respond to an ADA demand letter](/blog/ada-demand-letter-response-template)
- [AccessComply: Shopify accessibility complete guide](/blog/shopify-accessibility-complete-guide)
---
## Shopify Accessibility Checker: Free Tools to Test Your Store (2026)
URL: https://accesscomply.com/blog/shopify-accessibility-checker
Excerpt: A practical guide to checking a Shopify store with Lighthouse, axe DevTools, WAVE, manual assistive-technology testing, and an AccessComply multi-page public scan.
## The Short Answer: Use Several Tools, and Don't Trust Any One Alone
There is no single "best" Shopify accessibility checker because automated tools cover only machine-testable patterns in the pages and states they evaluate. Use automated results as candidates, then test representative journeys manually with keyboard, zoom/reflow, and assistive technology. This guide compares common free options and their boundaries.
We build AccessComply, so we'll be upfront about that. We'll also be upfront about what our scanner does and doesn't do, and about when the other tools here are the better choice.
## The Free Tools Compared at a Glance
| Tool | Scope | Best for | Key limit |
| --- | --- | --- | --- |
| **Lighthouse** (Chrome DevTools) | One page | Quick dev-time spot check, perf + a11y together | Subset of axe rules; one URL at a time |
| **axe DevTools** (browser extension) | One page | Deep, accurate per-page audit during development | Manual, page-by-page; deeper checks need paid tier |
| **WAVE** (browser extension / web) | One page | Visual, annotated overview for non-developers | One page at a time; visual clutter on complex pages |
| **Screen reader** (NVDA / VoiceOver) | Whole flows | Real usability — the ground truth | Slow; requires learning the tool |
| **AccessComply free scan** | Reached public pages | Multi-page discovery and automated samples | Crawler and automated-rule limits; manual testing still needed |
None of these alone equals "compliant." They're complementary.
## Browser Lighthouse: The Zero-Install Starting Point
Lighthouse is built into Chrome DevTools and needs nothing installed. Open your store page, press F12, go to the **Lighthouse** tab, check **Accessibility**, and run it. You get a 0–100 score and a list of failed audits with affected elements.
**Good for:** a fast first read during development, especially because it reports performance and SEO in the same run. **Where it stops:** Lighthouse runs a *subset* of the axe-core ruleset, scores one URL at a time, and its single number can lull you into thinking a high score means "accessible." It doesn't — a 95 can still ship with broken keyboard flows. Use it as a smoke test, not a verdict.
## axe DevTools: The Most Accurate Per-Page Audit
axe DevTools is a free browser extension built on the same axe-core engine that legal testing firms and professional auditors use. Install it, open the **axe DevTools** panel in DevTools, and run "Scan all of my page." It returns precise violations grouped by impact, with the exact failing selector and a "learn more" link for each rule.
**Good for:** developers fixing one page at a time — it's the most accurate automated per-page tool in this list, with very few false positives. **Where it stops:** it's manual and page-by-page, so auditing a 40-page store means 40 runs. Its deeper "guided" and "intelligent" checks sit behind a paid tier. It's a precision instrument for a page, not a way to survey a whole store.
## WAVE: The Best Visual Overview for Non-Developers
WAVE (from WebAIM) renders its findings as icons overlaid directly on your page — a red icon where a contrast error sits, a flag where alt text is missing. There's a web version (paste a URL) and a browser extension for pages behind a login.
**Good for:** merchants and content people who aren't comfortable in a DevTools console. Seeing the error sitting *on* the element makes issues concrete. **Where it stops:** like the others, one page per run, and on dense, modern Shopify themes the overlay icons can pile up and become hard to read. It's an explainer, not a bulk auditor.
## Manual Screen-Reader Testing: The Ground Truth No Tool Replaces
This is the step most merchants skip and the one that matters most. Automated tools tell you a label is *missing*; only a human can tell you the label is *wrong*, the reading order is *confusing*, or a custom swatch is *technically labeled but unusable*.
How to do a basic pass for free:
- **Windows:** [NVDA](https://www.nvaccess.org/) + Firefox (both free).
- **Mac:** VoiceOver (Cmd-F5) + Safari (built in).
Then, with your eyes closed or the monitor off:
1. Tab through the homepage — can you reach every link and button, and is the focus order logical?
2. Open a product page — are images described meaningfully? Can you pick a size and color by keyboard?
3. Add to cart and start checkout — does it announce what's happening, including errors?
If you get stuck or confused at any step, that's a real defect — and it's frequently one no automated checker flagged.
## The Limit: Automation Does Not Cover Every Requirement
Automation is useful for eligible *machine-checkable* patterns, but no universal percentage describes a particular storefront or tool configuration:
- Missing or empty alt text
- Color contrast below threshold
- Missing form labels
- Broken or misused ARIA
- Missing document language, duplicate IDs, empty links/buttons
It cannot judge the *human* criteria: whether alt text is meaningful, whether headings describe the content, whether focus order matches visual order, whether a drag interaction has a keyboard alternative, or whether an error message actually makes sense. Anyone — including any vendor — who tells you a one-click scan makes you "compliant" is overselling. Real conformance work always pairs automated scanning with manual testing.
## Where AccessComply's Free Scanner Fits
The gap the per-page tools leave is **coverage**: Lighthouse, axe DevTools, and WAVE each test one URL at a time, so surveying multiple store routes is tedious. AccessComply's free public scanner automates discovery across up to 10 pages, subject to crawler safety and time limits.
- **It runs axe-core** — the same engine behind axe DevTools and the testing firms — so the detection quality is comparable to the per-page tools.
- **It scans multiple page types across your store** (home, collection, product, cart) in one pass, instead of making you run a tool URL-by-URL.
- **You can review automated results without signing up** — including detected counts, severity, sample locations, and scan scope, subject to current service limits.
What it is *not*: a compliance guarantee or complete audit. AccessComply may offer merchant-approved remediation for eligible, safely source-mapped findings through supported Shopify theme or content paths, record affected source or prior values where supported, and run a post-change check. Manual testing and third-party vendor work remain necessary. See the [pricing page](/pricing) for current limits and entitlements. None of this is legal advice.
## A Practical Testing Routine
Put together, here's a routine that doesn't require being an accessibility expert:
1. **Survey the discoverable scan scope** with the AccessComply free public scan (up to 10 pages, subject to crawler limits) to find where detected findings cluster.
2. **Drill into the worst pages** with axe DevTools or WAVE for exact, element-level detail.
3. **Fix the detectable issues** — alt text, contrast, labels, ARIA — at the source-code level (in your theme, not via an overlay).
4. **Test the key flows manually** with NVDA or VoiceOver: browse, add to cart, check out.
5. **Re-scan and manually retest after material theme or app changes** because they can alter the rendered accessibility behavior.
## The Bottom Line
The best Shopify accessibility-checking approach is layered. Lighthouse and axe DevTools provide per-page automated results; WAVE makes findings visual; a multi-page crawler broadens the sampled scope; and manual keyboard and assistive-technology testing evaluates behavior automation cannot judge. Start with a documented scope and keep the limitations visible.
---
*See an automated sample of accessibility findings across key storefront page types — axe-core powered, no account required. [Run a free scan now](/).*
## Further Reading
- [The Complete Shopify Accessibility Guide](/blog/shopify-accessibility-complete-guide)
- [Best Shopify Accessibility App: An Honest Comparison](/blog/best-shopify-accessibility-app)
- [WCAG 2.1 AA Checklist for Shopify Stores](/blog/wcag-21-aa-checklist-shopify)
- [Why Accessibility Overlay Widgets Don't Work (And What Actually Does)](/blog/accessibility-overlay-widgets-dont-work)
---
## Shopify Accessibility: A Practical ADA, EAA, and WCAG Guide
URL: https://accesscomply.com/blog/shopify-accessibility-complete-guide
Excerpt: A practical guide to accessibility planning for Shopify: legal context, WCAG engineering targets, common storefront barriers, scoped remediation, manual testing, and ongoing monitoring.
This guide is a practical starting point for Shopify accessibility work in 2026. It covers legal context, engineering targets, common storefront patterns, remediation options, manual testing, and ongoing maintenance. It is not a complete audit, legal opinion, or promise that every theme pattern has one safe code-level fix.
If you want a 2-minute orientation, jump to the [TL;DR](#tldr). For the full structured walkthrough, read straight through.
## The legal target — what "accessible" actually means in 2026
In 2026, **WCAG 2.1 Level AA plus applicable WCAG 2.2 Level AA criteria** is a practical technical target for Shopify accessibility work. It is not a universal statement of law: some regimes incorporate a specific WCAG version, some use WCAG as a benchmark, and others state functional requirements.
- **United States — ADA Title III.** The DOJ says the ADA applies to goods and services businesses open to the public provide online. Title III has no detailed web technical regulation; DOJ identifies WCAG as helpful technical guidance. The separate 2024 Title II rule for state and local governments uses WCAG 2.1 AA. Business-specific scope can depend on facts and jurisdiction.
- **European Union — European Accessibility Act.** [Directive 2019/882](/blog/eaa-enforcement-deadline-shopify) became enforceable on 28 June 2025 for covered products and services. It sets functional accessibility requirements for specified ecommerce services, subject to scope rules and exemptions. EN 301 549 v3.2.1 incorporates WCAG 2.1 for web content; WCAG 2.2 is a useful separate target. Penalties and procedures vary by member state.
- **United Kingdom — Equality Act 2010.** Post-Brexit the UK is not subject to the EAA, but [the Equality Act still requires reasonable adjustments](/blog/eaa-compliance-uk-shopify), including accessible websites. WCAG 2.1 AA remains the practical target.
- **Canada — AODA / federal ACA.** Ontario\'s AODA and the federal Accessible Canada Act both reference WCAG 2.1 AA for digital services.
The headline takeaway: customer location can matter even when the merchant is established elsewhere, but a single order is not a complete legal-scope test. Product or service category, consumer targeting, microenterprise status, national implementation, and other exemptions all matter. Confirm jurisdiction-specific exposure with qualified counsel.
## What WCAG 2.2 added — and what changes for Shopify in 2026
WCAG 2.2, published in October 2023, added [nine new success criteria](/blog/wcag-22-whats-new-shopify) on top of WCAG 2.1. Relevant additions for Shopify include:
- **2.4.11 Focus Not Obscured (Min)** — sticky headers must not cover focused links. Affects Shopify stores with sticky announcement bars, sticky cart drawers, and sticky mega-menus.
- **2.4.13 Focus Appearance (AAA)** — a stronger optional target for focus-indicator size and contrast; it is not a Level AA requirement.
- **2.5.7 Dragging Movements** — drag-only interactions need a single-pointer alternative. Affects [image carousels](/wcag/2-5-8) and any sortable UI.
- **2.5.8 Target Size (Min)** — pointer targets must be ≥24×24 CSS pixels. Many themes ship with 16-18px tap targets in mobile navigation.
- **3.3.8 Accessible Authentication (Min)** — login flows cannot depend on cognitive function tests (typing memorized passwords, transcribing CAPTCHAs) without an alternative.
For Shopify merchants, the practical impact is that themes that passed WCAG 2.1 AA in 2023 typically have new failures under 2.2 — usually around mobile tap targets, sticky-header focus obscuring, and CAPTCHA accessibility on customer-account flows.
## The Shopify-specific failure map
Shopify storefront findings commonly cluster around a predictable set of patterns. The list below is a practical review order, not a claim that every store or dataset has the same distribution:
1. **Missing alt text on product images** — [WCAG 1.1.1 Non-text Content](/wcag/1-1-1). Attribute presence can be automated; description quality needs judgment.
2. **Insufficient color contrast** — [WCAG 1.4.3 Contrast (Minimum)](/wcag/1-4-3). Some rendered pairs are machine-testable; real states and brand decisions need review.
3. **Missing form labels** — [WCAG 3.3.2 Labels or Instructions](/wcag/3-3-2). Some standard patterns may have eligible source candidates.
4. **Icon buttons without accessible names** — [WCAG 4.1.2 Name, Role, Value](/wcag/4-1-2). The correct name and state depend on component behavior.
5. **Generic "Read more" link text** — [WCAG 2.4.4 Link Purpose](/wcag/2-4-4). Context and editorial review matter.
6. **Custom dropdowns / swatches not keyboard-reachable** — [WCAG 2.1.1 Keyboard](/wcag/2-1-1). Complex interactions usually require manual testing and development.
7. **Hidden focus indicators** — [WCAG 2.4.7 Focus Visible](/wcag/2-4-7). Some CSS patterns may be eligible, but each background and state needs verification.
8. **Missing semantic structure on spec / nutrition tables** — [WCAG 1.3.1 Info and Relationships](/wcag/1-3-1). Table meaning and structure require human review.
9. **Tap targets smaller than 24×24 CSS px** — [WCAG 2.5.8 Target Size](/wcag/2-5-8). Responsive layout and exceptions must be evaluated.
10. **Login flows blocking paste / using CAPTCHAs without alternatives** — [WCAG 3.3.8 Accessible Authentication](/wcag/3-3-8). Usually requires platform, app-vendor, or manual remediation.
Addressing all 10 removes important barriers, but it does not establish WCAG or legal conformance. Manual keyboard, screen-reader, zoom/reflow, content-quality, and purchase-flow testing is still necessary.
## Theme-by-theme — what each major Shopify theme gets right and wrong
The shipping accessibility quality of Shopify themes varies more than most merchants realize.
- **[Dawn](/blog/shopify-dawn-theme-accessibility-issues)** — Shopify\'s reference OS 2.0 theme and the most-installed theme on the platform. Better than most premium themes on accessibility, but still ships with predictable WCAG gaps: low contrast on secondary buttons, missing `aria-current` on cart drawer, inconsistent skip-nav behavior on mobile.
- **[Debut](/blog/shopify-debut-theme-accessibility)** — the legacy free theme. Pre-dates OS 2.0 and ships with structural accessibility issues — non-semantic dropdown menus, missing form labels on the newsletter capture, contrast failures in the default purple palette.
- **[Craft](/blog/shopify-craft-theme-accessibility)** — premium theme popular with artisan and lifestyle brands. Ships with the same accessibility gaps as most premium themes: insufficient color contrast on muted palettes, missing focus styles on custom dropdowns.
- **Studio, Sense, Refresh, Origin** — newer OS 2.0 themes. Generally good baseline; per-store failures concentrate in merchant-customized sections.
## How to actually fix this — the practical workflow
There are four ways to make a Shopify store accessible. They are not equivalent.
### 1. Manual remediation by an accessibility consultant
Cost and scope vary widely by store size, page templates, testing depth, and whether remediation is included. Best for: teams that need manual assistive-technology testing, formal procurement deliverables, or jurisdiction-specific expert review.
### 2. Backed-up source-code remediation (AccessComply)
Current monthly plans range from Free to $199, with plan-specific fixes, monitoring, and reports. Coverage is limited to eligible findings where source mapping and entitlements permit a candidate; risky or judgment-heavy items remain manual. Check [pricing](/pricing) for current details.
### 3. Manual remediation by your in-house developer
Cost and timing depend on the confirmed backlog, theme architecture, third-party ownership, testing depth, and developer expertise. Obtain a written scope and estimate.
### 4. Overlay widgets (AccessiBe, UserWay, Isonomy, etc.)
Runtime products and service bundles vary. Confirm current functionality, data practices, services, and pricing directly. In 2025 the FTC approved a final order requiring accessiBe to pay $1 million and restricting specified unsupported claims; that order does not establish that every runtime tool is identical.
## What an accessible Shopify store looks like from the merchant side
Run a [free AccessComply scan](/) on your storefront. You\'ll get:
- A 0-100 automated check score for the rules run—not a WCAG conformance percentage.
- A categorized violation list — alt text, contrast, keyboard, focus, forms, structure, mobile, authentication.
- An issue-volume band — CRITICAL / HIGH / MEDIUM / LOW — that is not a lawsuit probability.
- Suggested remediation and fix eligibility for each detected issue.
AccessComply can apply merchant-approved changes through supported theme and Shopify content paths. The installed Free plan includes 3 eligible deterministic fixes per rolling 30 days; Starter makes deterministic fixes unlimited, while AI-assisted fixes require Shield or Citadel. Supported writes record the affected source or prior value and run a post-fix check. Only confirmed fixes are marked resolved; unresolved or regressed work is marked for review, with recorded restore points available through an explicit merchant-confirmed restore.
## Compliance documentation — what to publish
Accessibility work is easier to maintain when it is documented. Two artifacts are especially useful:
- **[An accessibility statement](/templates/accessibility-statement)** — can present scope, assessment method, known limitations, and feedback channels. EAA and national information duties vary; a public statement is useful documentation but is not automatically a complete legal deliverable.
- **An audit trail** — scan history, fix history, backup records. AccessComply produces this automatically; if you remediate manually, keep your own log so you can show what changed and what still needs review.
## Free tools to verify your store
Three tools you can use right now without signing up:
- **[Free Shopify accessibility scanner](/)** — paste your store URL, get an axe-core scan with per-criterion violations across desktop and mobile viewports.
- **[WCAG color contrast checker](/tools/contrast-checker)** — paste any two hex codes, get the WCAG luminance ratio and AA/AAA pass/fail for normal and large text.
- **[Accessibility response budget planner](/tools/lawsuit-cost-calculator)** — total audit, remediation, monitoring, internal, and legal-review estimates that you enter; it does not forecast a claim or settlement.
- **[ADA accessibility quiz (10 questions)](/tools/ada-compliance-quiz)** — a self-assessment starting point, not a legal or conformance determination.
For program documentation: [free accessibility statement template](/templates/accessibility-statement) — 8 sections based on W3C guidance. Copy, customize, and verify jurisdiction-specific requirements before publishing to `/pages/accessibility-statement`. Pricing tiers for the AccessComply auto-fix subscription are at [/pricing](/pricing).
## Common questions — what to do when…
### …you receive an ADA demand letter
Do not ignore it or rely on a generic response deadline from a blog. Preserve the complete communication and relevant records, notify appropriate internal and insurance contacts, and obtain qualified counsel promptly. Coordinate evidence collection and remediation with counsel. [Evidence checklist here.](/blog/ada-demand-letter-response-template)
### …you sell to EU customers
Determine whether the service and merchant are in scope under the EAA and applicable national law. If covered, assess the full customer journey, use WCAG 2.1 AA and relevant EN 301 549 web clauses as technical references, add applicable WCAG 2.2 checks, and document remediation. [Country-specific guides for France](/blog/eaa-compliance-france-shopify), [Germany](/blog/eaa-compliance-germany-shopify), and [the UK](/blog/eaa-compliance-uk-shopify).
### …you already have an overlay installed
No tool protects you from a claim. Review what the runtime product currently changes, test the storefront with and without it where feasible, inspect the underlying source, and plan remediation for verified barriers. The [FTC’s accessiBe order](/blog/accessibe-alternative-shopify-after-ftc-fine) is a warning against unsupported automated-conformance claims, not proof that another architecture guarantees compliance.
## Further reading by topic
- **Lawsuit landscape** — [ADA website accessibility risk guide](/blog/ada-lawsuits-ecommerce), [5 real Shopify stores sued](/blog/5-shopify-stores-sued-ada-accessibility), [demand letter response guide](/blog/ada-demand-letter-response-template).
- **EAA / Europe** — [EAA pillar guide](/blog/eaa-enforcement-deadline-shopify), [France](/blog/eaa-compliance-france-shopify), [Germany](/blog/eaa-compliance-germany-shopify), [UK](/blog/eaa-compliance-uk-shopify).
- **WCAG references** — [WCAG 2.1 AA checklist](/blog/wcag-21-aa-checklist-shopify), [WCAG 2.2 new criteria](/blog/wcag-22-whats-new-shopify), [per-criterion deep-dives](/wcag).
- **Overlay critique** — [why overlays don\'t work](/blog/accessibility-overlay-widgets-dont-work), [overlay vs source-code comparison](/blog/accesscomply-vs-accessibe-comparison), [best Shopify accessibility app — 7-vendor comparison](/blog/best-shopify-accessibility-app).
- **By industry** — [fashion](/industry/fashion), [beauty](/industry/beauty), [food](/industry/food), [electronics](/industry/electronics).
## Primary sources
- [W3C — Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- [DOJ — Web accessibility under the ADA](https://www.ada.gov/resources/web-guidance/)
- [EUR-Lex — Directive (EU) 2019/882 (European Accessibility Act)](https://eur-lex.europa.eu/eli/dir/2019/882/oj)
- [ETSI — EN 301 549 v3.2.1](https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf)
- [FTC — final order requiring accessiBe to pay $1 million (2025)](https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million)
---
## Shopify Accessibility Baselines: How to Build a Defensible Index
URL: https://accesscomply.com/blog/shopify-accessibility-index
Excerpt: A transparent methodology for measuring Shopify storefront accessibility without presenting an unpublished convenience sample as a platform-wide statistic.
An accessibility index is useful only when readers can understand the sample, reproduce the measurement, and separate automated findings from conformance claims.
AccessComply does not currently publish a representative Shopify-wide failure percentage. Earlier convenience-sample claims were removed because the underlying store list and reproducible aggregate dataset were not published. A selected automated sample should not be marketed as a fact about every Shopify store.
A scanner reports eligible findings on pages and states it reaches. It does not test every success criterion, customer journey, assistive-technology combination, third-party surface, document, or future storefront state.
## Minimum methodology for a credible index
### Sampling
Define the population and selection method before scanning. A credible Shopify benchmark should disclose store geography, industry, catalog size, traffic or ranking source, theme type, app usage, and inclusion or exclusion rules. A hand-picked list cannot support a platform-wide percentage.
### Scan scope
Report the number and types of pages reached per store, desktop and mobile viewports, authentication status, crawl limits, timeouts, robots behavior, redirects, password protection, and failed pages. A one-page homepage test is not comparable to a multi-template crawl.
### Rule engine
Publish the engine and version, standards tags, configuration, custom rules, impact mapping, and date. Rule changes can alter results even when the storefront does not change.
### Counting and deduplication
Separate unique rule patterns, affected nodes, affected pages, and store-level prevalence. Repeated navigation can create hundreds of node occurrences from one theme defect. Presenting raw occurrences alone can exaggerate the amount of distinct remediation work.
### Manual review
State whether people reviewed false positives, severity, duplicate patterns, content meaning, keyboard behavior, screen-reader output, and task completion. An automated-only index should be labeled automated-only.
### Uncertainty and publication
Publish aggregate data and enough methodology to reproduce it without exposing merchant-sensitive information. Distinguish observations in the sample from inferences about the wider Shopify population. Correct or withdraw claims when source data cannot be audited.
## How to interpret an individual AccessComply scan
The public scanner checks up to 10 discoverable pages, subject to crawler safety and time limits, at desktop and mobile viewports. The installed app uses plan-specific scan limits. Results are automated WCAG-mapped findings in the reported scope.
Use the result to prioritize technical work. Do not read a high score as conformance or a low score as legal exposure. Confirm important journeys manually and document pages or states the scan could not reach.
## What a future AccessComply index should include
Before publishing new aggregate claims, AccessComply should provide:
- a dated, documented sampling method;
- the exact scanner build and rules configuration;
- crawl-success and exclusion data;
- store-level normalized aggregate tables;
- deduplicated pattern counts alongside raw node counts;
- an independent manual-review sample;
- limitations and confidence intervals where applicable;
- a privacy-preserving reproducibility package.
Until then, merchants should scan and test their own storefront rather than using an unsupported industry percentage as a proxy.
[Run a free automated scan](/) and review the reported scope before acting on the results.
---
## Shopify Accessibility Statement: Template + 8-Section Guide (Free)
URL: https://accesscomply.com/blog/shopify-accessibility-statement-template-guide
Excerpt: An accessibility statement can document scope, assessment methods, limitations, feedback channels, and remediation work. Here is an 8-section template, where to publish it on Shopify, and how to keep it current.
A published accessibility statement is one of the most useful pieces of accessibility documentation a Shopify merchant can ship. The EAA requires covered service providers to make accessibility information available in an accessible form; a public statement can help present it, while exact obligations come from the Directive and national law. France\'s RGAA and the UK\'s public-sector rules have their own statement requirements. For private US ecommerce, it is not a standalone ADA requirement, but it helps document scope, known limitations, contact channels, and remediation work. The template below is open and free to use.
EAA enforcement began on 28 June 2025 for covered services. Annex I includes accessible service-information duties, but this template is not a substitute for checking national implementation. France\'s RGAA has more specific publication rules for entities in its scope. The W3C publishes a free Accessibility Statement Generator as practical guidance, not as legal certification.
## Why publish a statement — three reasons
### 1. Remediation documentation
Active remediation records matter when a merchant needs to respond to a complaint, regulator, marketplace, or demand letter. The published statement is the public-facing summary: it names the standard the storefront targets, declares the current conformance level, lists known limitations with timelines, and provides a feedback mechanism for users to report issues.
In a complaint or demand-letter response, counsel may ask what the storefront\'s accessibility documentation and remediation record show. A truthful statement plus scan, fix, and manual-review records gives them concrete evidence to assess.
### 2. EAA-related service information
The European Accessibility Act requires covered service providers to explain in an accessible form how the service meets applicable accessibility requirements. A public statement is one practical way to organize that information, but member-state implementation determines the exact content, authority, and format.
EAA enforcement is delegated to member-state authorities. Clear service information, known limitations, feedback handling, assessments, and remediation records can all matter during a complaint review.
### 3. User experience
The feedback mechanism in the statement (typically `accessibility@.com`) lets users with disabilities report issues directly. That feedback loop catches issues automation misses — content authoring problems, third-party app regressions, screen-reader-specific quirks — and feeds the merchant\'s remediation backlog.
## The 8-section template
The full template, ready to paste into a Shopify Page at `/pages/accessibility-statement`, lives at [/templates/accessibility-statement](/templates/accessibility-statement). The structure:
### 1. Commitment statement
> [Store name] is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards.
One sentence establishes the commitment. Treat it as clear program communication, not proof of conformance.
### 2. Conformance status
> The Web Content Accessibility Guidelines (WCAG) define requirements for designers and developers to improve accessibility for people with disabilities. They define three levels of conformance: Level A, Level AA, and Level AAA. [Store name] is **partially conformant** with WCAG 2.1 and WCAG 2.2 Level AA. Partially conformant means that some parts of the content do not fully conform to the standard.
Use only a status supported by the stated assessment scope. Automated scanning alone cannot establish full conformance. "Partially conformant" with documented limitations is more accurate than a full-conformance claim unsupported by manual evaluation.
### 3. Compatibility with browsers and assistive technology
> [Store name] is designed to be compatible with the following assistive technologies: the latest versions of JAWS, NVDA, VoiceOver (macOS and iOS), and TalkBack (Android). The website is compatible with the latest versions of Chrome, Firefox, Safari, and Edge.
Names the assistive technology + browser combinations the merchant has tested. If you have not tested with a particular AT, do not list it — listing untested AT is a misrepresentation.
### 4. Technical specifications
> Accessibility of [Store name] relies on the following technologies to work with the particular combination of web browser and any assistive technologies or plugins installed on your computer: HTML, WAI-ARIA, CSS, JavaScript. These technologies are relied upon for conformance with the accessibility standards used.
Documents the underlying tech stack so users with non-standard browsers / AT understand the compatibility scope.
### 5. Limitations and alternatives
> Despite our best efforts to ensure accessibility of [Store name], there may be some limitations. Below is a description of known limitations and potential solutions.
This is the section that converts the statement from boilerplate into useful documentation. List specific known limitations:
- "Some product images do not yet have descriptive alt text. We are addressing this on a rolling basis. In the meantime, customers can email accessibility@store.com with the product URL to receive a description."
- "Our accessibility statement is currently available in English only. Translations to French and German are scheduled for [date]."
- "Some third-party app embeds (reviews widget, chat widget) have not been independently audited. We are working with vendors to verify their accessibility."
Specific limitations + remediation timelines + workarounds is exactly what an accessibility-firm audit produces. AccessComply\'s scan output feeds this section directly.
### 6. Assessment approach
> [Store name] assesses selected storefront pages through automated scanning powered by AccessComply (Playwright + axe-core), targeting WCAG 2.1 Level AA and applicable WCAG 2.2 Level AA criteria at desktop and mobile viewports. Automated scanning cannot evaluate every success criterion. Manual evaluation is performed periodically by [team / external auditor].
Documents the methodology so users + regulators understand the rigor of the conformance claim.
### 7. Feedback mechanism
> We welcome your feedback on the accessibility of [Store name]. Please let us know if you encounter accessibility barriers:
> - Email: accessibility@[your-domain].com
> - Phone: [phone number]
> - Visitor address: [postal address]
>
> We try to respond to feedback within [number] business days.
A monitored feedback channel is a strong accessibility-program practice and may be required in some frameworks. Set up forwarding so the address reaches the merchant\'s actual ticket queue, not a black hole.
### 8. Date prepared and last reviewed
> This statement was prepared on [date]. It was last reviewed on [date].
The "last reviewed" date helps users and reviewers understand how current the statement is. Update it after every meaningful assessment or remediation pass.
## How to publish on Shopify
1. **Shopify admin → Online Store → Pages → Add page**.
2. Title: `Accessibility Statement`.
3. Page handle: `accessibility-statement` (so the URL becomes `/pages/accessibility-statement`).
4. Paste the 8-section template (full text at [/templates/accessibility-statement](/templates/accessibility-statement)).
5. Customize the placeholders: `[Store name]`, `[date]`, `[email]`, `[team]`.
6. Set Visibility: Visible.
7. **Online Store → Themes → Customize → Footer**. Add a navigation link to `/pages/accessibility-statement` so the statement is reachable from every page.
8. Save and publish.
For multilingual stores using Shopify Markets, provide the information in the languages needed by the storefront and applicable law. Use the W3C guidance at [w3.org/WAI/planning/statements](https://www.w3.org/WAI/planning/statements/) as a starting point, then have native speakers and counsel review jurisdiction-specific versions.
## App-generated statements — keep the merchant in control
AccessComply includes a merchant-reviewed statement workflow on the Free plan. It helps structure organization name, scope, known limitations, feedback contacts, and an optional jurisdiction-specific accessibility contact, then publishes the approved text through the Shopify Admin API. It deliberately makes no WCAG conformance claim from automated scanning alone and explains the measured scope; it does not turn a numerical scan score into a legal conformance status or silently rewrite a live statement after each scan.
## What NOT to put in the statement
- **Do not claim full conformance you cannot verify.** Listing assistive technology you have not tested or claiming "100% WCAG AA conformance" without a real audit is a misrepresentation that backfires in litigation.
- **Do not omit known limitations.** A statement that says "fully conformant" while the storefront has a documented violation is worse than no statement — it documents bad faith.
- **Do not over-claim auto-fix coverage.** Say what was fixed, what still needs review, and what requires a third-party vendor or human decision.
- **Do not promise unrealistic remediation timelines.** A 30-day timeline that slips becomes evidence of inactivity.
## Quick checklist
- [ ] Statement published at `/pages/accessibility-statement`.
- [ ] Linked from a persistent, easy-to-find location; verify any jurisdiction-specific placement rule.
- [ ] All 8 sections completed with merchant-specific content.
- [ ] Conformance status is honest (partially conformant with limitations is fine).
- [ ] Feedback mechanism (email + at least one other channel) is monitored.
- [ ] "Last reviewed" date is current.
- [ ] Multilingual versions exist for Markets serving non-English EAA countries.
## Further reading
- [Free Shopify accessibility statement template (full 8-section text)](/templates/accessibility-statement)
- [W3C Accessibility Statement Generator (multilingual)](https://www.w3.org/WAI/planning/statements/)
- [EAA pillar guide for Shopify merchants](/blog/eaa-enforcement-deadline-shopify)
- [RGAA / France EAA implementation](/blog/eaa-compliance-france-shopify)
- [BFSG / Germany EAA implementation](/blog/eaa-compliance-germany-shopify)
- [Glossary — accessibility statement](/glossary/accessibility-statement)
- [Glossary — RGAA](/glossary/rgaa)
- [Glossary — BFSG](/glossary/bfsg)
- [Glossary — Equality Act 2010 (UK)](/glossary/equality-act-2010)
- [AccessComply — Shopify accessibility complete guide](/blog/shopify-accessibility-complete-guide)
---
## Cart Drawer aria-live Fix: Screen-Reader-Friendly
URL: https://accesscomply.com/blog/shopify-cart-drawer-aria-live-fix
Excerpt: When an add-to-cart action updates content without moving focus, verify that the status is programmatically exposed. This guide shows an adaptable live-region pattern and manual screen-reader testing.
Cart feedback is important to a purchase journey. When focus does not move after an add-to-cart action, WCAG 4.1.3 may require the resulting status to be programmatically determinable without receiving focus. Implementations differ by theme and app, so confirm the actual failure before adapting this pattern.
Open your storefront. Activate macOS VoiceOver (Cmd+F5) or Windows NVDA. Click "Add to cart" on a product page. Listen for an audible announcement like "Added to cart" or "Cart updated, X items". If you hear nothing — or if focus moves into the cart drawer without the screen reader saying anything about why — you need the fix in this guide.
## What 4.1.3 actually requires
WCAG 4.1.3 has three legitimate implementation patterns:
1. **`role="status"`** — an implicit `aria-live="polite"` region. Updates are announced without interrupting the screen reader\'s current speech. Best for non-urgent confirmations.
2. **`role="alert"`** — an implicit `aria-live="assertive"` region. Updates are announced immediately, interrupting current speech. Reserve for genuinely urgent conditions (errors, time-sensitive failures).
3. **`aria-live="polite"`** or **`aria-live="assertive"`** — explicit live region. Same effect as the role-based equivalents but on an element that needs other ARIA semantics.
For cart-drawer "Added to cart" announcements, **`role="status"`** is the right choice. It is non-urgent, the user is voluntarily continuing to shop, and the polite delivery doesn\'t interrupt anything.
## The Liquid + JavaScript fix
### Step 1 — Add the live-region container in cart-drawer.liquid
Open your cart-drawer template (in Dawn: `sections/cart-drawer.liquid`; in legacy themes: `templates/cart.liquid` or a partial). Add this near the top of the template, immediately inside the outermost wrapper:
```liquid
```
The element starts empty. JavaScript writes the announcement text into it when the cart updates. The visually-hidden class hides the text from sighted users (the visible toast/drawer handles that); the `role="status"` and `aria-live="polite"` make screen readers announce changes.
### Step 2 — Visually-hidden CSS (skip if your theme already has it)
Add the visually-hidden utility class to `assets/base.css` if it isn\'t already defined:
```css
.visually-hidden {
position: absolute !important;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0 0 0 0);
clip-path: inset(50%);
white-space: nowrap;
border: 0;
}
```
Critical detail: do NOT use `display: none`. That removes the element from the accessibility tree entirely, so the live region never fires.
### Step 3 — Write announcement text from cart-update JavaScript
In your cart-update JavaScript (Dawn: `assets/cart.js` or `assets/cart-drawer.js`; other themes: similar), find the function that runs after a successful add-to-cart fetch. Add this snippet:
```js
function announceCartUpdate(message) {
const region = document.getElementById('cart-status-message');
if (!region) return;
// Clear and rewrite to ensure the live region fires even if the same
// message would otherwise be deduped by the screen reader.
region.textContent = '';
setTimeout(() => {
region.textContent = message;
}, 50);
}
// After a successful add-to-cart fetch:
announceCartUpdate(`Added to cart. ${cartCount} ${cartCount === 1 ? 'item' : 'items'} total.`);
```
Some implementations clear and then update the region asynchronously to help repeated messages announce, but timing behavior varies across browsers and assistive technologies. Treat 50 milliseconds as an example, not a guarantee, and test repeated additions with supported combinations.
### Step 4 — Clear the announcement on drawer close
When the user closes the cart drawer, clear the live region so a subsequent identical add still announces:
```js
function onCartDrawerClose() {
const region = document.getElementById('cart-status-message');
if (region) region.textContent = '';
}
```
## Common mistakes to avoid
### Live region inside a hidden parent
If the live region is inside a parent that has `display: none` until the drawer opens, the announcement fires only when the drawer is visible — which means the screen reader hears it after the visual toast has already disappeared, or not at all. Place the live region in a permanent location (top of ``, inside ``) and have the drawer toggle visibility independently.
### Using `aria-live="assertive"` for routine confirmations
Reserve `aria-live="assertive"` for genuinely urgent conditions. A cart-update toast set to assertive interrupts whatever the user is currently doing — frustrating for users who continue shopping after adding an item.
### Writing the same text twice without clearing
```js
// WRONG — second identical write may be silently deduped
region.textContent = "Added to cart. 1 item.";
region.textContent = "Added to cart. 1 item."; // doesn\'t fire
```
If repeated messages are not announced, clearing before an asynchronous rewrite is one pattern to test. It is not universal; avoid rapid or duplicate announcements and verify behavior manually.
### Hiding the live region with `display: none`
`display: none` removes the element from the accessibility tree. Use the `visually-hidden` clip pattern shown above instead.
### Multiple live regions for the same announcement
Some themes have inherited two live regions from partial migrations. Two regions cause double announcements ("Added to cart. Added to cart."). Keep one.
## How to verify the fix works
### Manual test with VoiceOver (macOS)
1. Open your storefront in Safari.
2. Press Cmd+F5 to start VoiceOver.
3. Tab to a product card. Press Enter on "Add to cart".
4. Listen for an announcement like "Added to cart. 1 item total."
5. Add another product. Listen for the same pattern with the new count.
### Manual test with NVDA (Windows)
1. Open NVDA. Open your storefront.
2. Tab to a product. Press Enter on "Add to cart".
3. NVDA should announce the live-region text without focus moving.
### Browser DevTools verification
1. Open DevTools and inspect the cart-status-message element.
2. Confirm `role="status"` and `aria-live="polite"` are present.
3. Add to cart and watch DevTools — the element\'s text content should update with the announcement.
## Why manual verification still matters
Automation can inspect structural parts of a live region in a reached state, but presence alone does not prove announcement timing, message accuracy, focus behavior, or compatibility. AccessComply may propose an eligible, safely source-mapped first-party change for merchant approval through a supported theme path and run a post-change check; verify the purchase interaction manually and coordinate app-owned code with its vendor.
## Further reading
- [WCAG 2.1 SC 4.1.3 Status Messages — full understanding doc](https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html)
- [W3C ARIA Authoring Practices — Live Regions](https://www.w3.org/WAI/ARIA/apg/practices/live-regions/)
- [MDN: ARIA: status role](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/status_role)
- [AccessComply: WCAG 4.1.3 Status Messages reference](/wcag/4-1-3)
- [AccessComply: Glossary — aria-live](/glossary/aria-live)
- [AccessComply: Dawn theme accessibility audit](/themes/dawn)
---
## Shopify Checkout Accessibility Guide: Storefront, Extensions + Hydrogen
URL: https://accesscomply.com/blog/shopify-checkout-accessibility-guide
Excerpt: Shopify storefront carts, hosted checkout, Checkout UI Extensions, and Hydrogen each expose different accessibility responsibilities. Here is the WCAG checklist and the customization patterns that introduce risk.
Shopify commerce in 2026 has several accessibility ownership surfaces: the merchant storefront and cart, Shopify-hosted checkout, Checkout UI Extensions, and—when used—a Hydrogen storefront. Hydrogen does not replace Shopify checkout: customers follow the cart\'s checkout URL to a Shopify-hosted checkout. This guide separates those boundaries so merchants test the code they actually control.
Covered ecommerce services should evaluate the whole customer journey, while exact legal scope varies by jurisdiction. WCAG 2.1 Level AA is a widely used technical benchmark, and applicable WCAG 2.2 Level AA criteria are a sensible additional target. Shopify owns the hosted-checkout foundation; merchants remain responsible for storefront code, branding, content, and extensions they control.
## The checkout ownership surfaces
### 1. Shopify-hosted checkout
Shopify\'s native one-page checkout, served at `checkout.shopify.com` or the merchant\'s checkout subdomain. Renders a single page with three sections (Customer / Shipping / Payment) progressively revealed. Built by Shopify, accessibility-engineered against WCAG 2.1 AA.
**Merchant accessibility surface**: limited. The merchant controls:
- Branding (logo, colors via theme settings + Shop Pay branding API).
- Custom order-status-page content.
- Custom email templates.
- Cart attributes / line-item properties added from the cart page.
**Where regressions appear**: custom branding that produces sub-4.5:1 contrast; custom order-status-page Liquid content with sensory-only instructions; custom email templates that ignore alt text; cart attributes added via merchant scripts that lack labels.
### 2. Checkout UI Extensions
Plus merchants add UI to the standard checkout via Checkout UI Extensions. Extensions are built with the Polaris design system\'s checkout components — ``, `
```
The key line is `alt="{{ image.alt | escape | default: product.title }}"`. This:
1. Reads the alt text from the image record.
2. Escapes any HTML to prevent XSS.
3. Shows a product-title fallback as a candidate only; it still needs review and may duplicate nearby text or fail to describe the image.
If a meaningful image is rendered with an empty or missing alternative, stored admin text alone does not solve the customer barrier. AccessComply may report the reached-page finding and, when the first-party source is safely mapped, propose a merchant-approved change through a supported theme path. App-owned markup and ambiguous image purpose require manual or vendor review.
## Common alt-text mistakes on Shopify
- **Filename as alt text**: `alt="IMG_4567.JPG"` — happens when the theme falls back to the file name. Always set explicit alt text.
- **Keyword stuffing**: `alt="navy trousers buy navy trousers cheap navy trousers Shopify"` — it is unhelpful for screen-reader users and should not replace an equivalent description.
- **Repeating the product title verbatim**: technically valid but adds no information for screen-reader users beyond what the surrounding HTML already provides. Add a visually-distinguishing detail.
- **`alt="image"` or `alt="photo"`**: zero information — equivalent to no alt text from the screen-reader user\'s perspective.
- **Different alt text on every variant of the same product**: typically wrong unless the variants visually differ. Use the product-level alt text and let variants inherit unless visually different.
- **Decorative-image alt text**: spacer GIFs, ornamental flourishes, and brand-mark icons next to a labeled link should use `alt=""`, not a description. Screen readers skip silently.
## Quick checklist
- [ ] Every product\'s featured image has alt text describing the product.
- [ ] Variant-specific images that look different from the master have variant-specific alt text.
- [ ] Decorative images (background flourishes, spacer GIFs, ornamental icons) use `alt=""`.
- [ ] Functional images (icon-only buttons) use `aria-label` on the button + `aria-hidden="true"` on the inner SVG.
- [ ] Theme `