Key Takeaways (TL;DR)
- What are accessibility overlays? Third-party JavaScript widgets (accessiBe, EqualWeb, UserWay, AudioEye) that inject code on top of your site claiming to automate WCAG compliance — but they don't
- Key Risk: The FTC fined accessiBe $1 million in 2025 for deceptive compliance claims, and ~100 companies have been sued after installing overlay widgets
- Salesforce's Native Baseline: Experience Cloud already provides WCAG 2.2 AA–aligned components through the Lightning Design System (SLDS) with 900+ accessible HTML blueprints
- Where Real Gaps Exist: Custom components, CSS overrides, content authoring failures, and third-party AppExchange packages — none of which overlays fix
- Cost Comparison: Overlay subscription ($350–$6,000/year) provides zero legal protection vs. proper audit + remediation ($15,000–$30,000) that produces documented VPAT/ACR, actual fixes, and governance
- Bottom Line: Overlays are a legal liability, not a legal shield. Invest in native platform accessibility with expert audit, remediation, and governance
Introduction
If you manage a Salesforce Experience Cloud site — whether it's a customer portal, partner community, or self-service help center — you've likely received a pitch from an accessibility overlay vendor. The promise is seductive: install one line of JavaScript, and your site becomes WCAG compliant. No code changes. No audits. No expensive consultants.
It sounds too good to be true because it is.
In 2025, the Federal Trade Commission (FTC) finalized a $1 million enforcement order against accessiBe, one of the largest overlay providers, for deceptively claiming its AI product could make any website compliant with Web Content Accessibility Guidelines (WCAG). The same year, over 5,100 ADA digital accessibility lawsuits were filed in U.S. courts — a 20% increase over 2024 — and research from UsableNet found that approximately 100 companies were sued after installing overlay widgets, with overlay features sometimes cited as additional accessibility barriers.
Meanwhile, Salesforce's own platform has been investing heavily in native accessibility. The Lightning Design System (SLDS) provides 900+ HTML blueprints with built-in accessibility guidelines. Salesforce publishes Accessibility Conformance Reports (ACRs) using the VPAT International Edition format. And the open-source sa11y testing framework runs daily in Salesforce's own build pipelines.
This post provides a comprehensive, technical analysis of why accessibility overlays fail on Salesforce Experience Cloud, what the platform already provides natively, where the real accessibility gaps exist, and how to build a sustainable compliance program that actually protects your organization.
What Are Accessibility Overlays?
Accessibility overlays are third-party JavaScript widgets that inject code on top of a website's rendered HTML. They typically provide a floating toolbar with controls for:
- Contrast adjustment
- Font size enlargement
- Cursor size changes
- Text spacing modifications
- Screen reader–like read-aloud features
Some vendors go further, claiming "automated remediation" — using AI to add alt text to images, adjust ARIA attributes, and correct heading structures on the fly.
Major overlay products include: accessiBe, AudioEye, EqualWeb, FACIL'iti, MaxAccess, ReciteMe, TruAbilities, UserWay, and WebAbility.
EqualWeb, for example, markets an AI-powered SaaS widget with 27 accessibility functions across 32 languages, with pricing starting around $29/month. At the premium tier, some vendors offer managed services with manual auditing — but the vast majority of customers purchase the widget-only tier that promises automated compliance.
Why Overlays Fail: 5 Critical Problems
1. They Duplicate Existing Assistive Technology — Poorly
Users who need contrast enhancement, font enlargement, screen reading, or keyboard navigation already have these capabilities through their operating system, browser, or dedicated assistive technology (JAWS, NVDA, VoiceOver, ZoomText). An overlay duplicates this functionality less reliably, within a single page, and often conflicts with the tools users already depend on.
2. Automated Remediation Is Unreliable
AI-generated alt text consistently fails on complex images — charts, diagrams, infographics, and context-dependent visuals. ARIA attribute injection can conflict with existing ARIA on the page, creating worse accessibility than the original markup. Automated heading structure "repairs" cannot infer the author's intended content hierarchy.
3. They Produce Zero Governance Documentation
ADA Title II and Title III enforcement increasingly requires organizations to demonstrate a systematic accessibility program. This means:
- Dated baseline audit reports
- Risk-based prioritization frameworks
- Timestamped remediation logs
- Monitoring records
- Training documentation
- Vendor VPAT review records
- Executive reporting history
No overlay product produces any of these documents. Without governance documentation, organizations have no defensible position in litigation — regardless of what widget is installed on their site.
4. Users with Disabilities Actively Reject Overlays
The accessibility community has been vocal: overlays create barriers rather than removing them. The Overlay Fact Sheet — a community resource signed by over 800 accessibility professionals including contributors to WCAG standards, the Chair of the W3C ARIA Authoring Practices Task Force, and accessibility leads at Microsoft, Google, and Amazon — catalogs all major overlays as "unnecessary and limited in accuracy." Some users actively block overlay scripts because they interfere with their existing assistive technology.
The National Federation of the Blind (NFB) has issued concerns about overlay products, and multiple lawsuits have been filed against companies using overlays — with overlay features cited as additional barriers rather than solutions.
5. Federal Regulators Have Taken Action
In April 2025, the FTC finalized a $1 million enforcement order against accessiBe for deceptively claiming its AI tool could make any website WCAG compliant. The order bars accessiBe from representing that automated products can ensure compliance. In its April 2025 blog post, the FTC stated plainly: accessiBe's advertisements "overstated how well its plug-in performed."
This isn't an isolated case. Research from UsableNet found that approximately 100 companies received ADA lawsuits after investing in overlay widgets, with some lawsuits listing widget features as additional burdens to users with disabilities.
Can Overlays Even Work on Salesforce Experience Cloud?
Technically Yes — But with Significant Friction
Salesforce Experience Cloud enforces strict Content Security Policy (CSP) controls over external scripts. This is a security feature — the platform is deliberately designed to prevent arbitrary third-party JavaScript from executing on your site.
There are four implementation paths for loading an overlay widget into Experience Cloud:
| Method | Complexity | Template Support | Stability |
|---|---|---|---|
| Static Resource + Custom LWC/Aura Component | High (requires developer) | Both Aura and LWR | Most controlled |
| Trusted Sites / CSP Configuration | Medium | Both (with limitations) | Requires ongoing CSP allowlist maintenance |
| Head Markup Injection | Low | Aura templates only | Does NOT work on LWR |
| Visualforce Page Component | Medium | Both (as embedded component) | Workaround approach |
The LWR Problem
Salesforce's strategic direction is Lightning Web Runtime (LWR)–based templates, which enforce stricter security than legacy Aura templates. Loading arbitrary third-party JavaScript is significantly harder on LWR sites. Organizations building new Experience Cloud sites or migrating existing Aura sites to LWR will face increasing friction maintaining an overlay dependency.
Every Salesforce release could potentially break the overlay integration through CSP changes, requiring emergency fixes and creating a maintenance burden that grows over time.
The Architectural Mismatch
Even when technically functional, adding an overlay to Experience Cloud is architecturally awkward. You're injecting an external dependency into a platform that was deliberately designed to control external scripts. The overlay operates on the rendered DOM, potentially conflicting with Lightning component lifecycle management, Shadow DOM boundaries, and SLDS styling conventions.
Bottom line: The technical friction of implementing overlays on Experience Cloud is itself a signal. The platform already provides accessibility infrastructure — overlays work against it rather than with it.
What Salesforce Provides Natively
Before spending a dollar on third-party widgets, understand what Salesforce has already built into the platform.
Platform-Level Accessibility Commitment
Salesforce has made a public commitment to WCAG 2.2 AA conformance across its products. This commitment includes:
- Accessibility Conformance Reports (ACRs) published using the VPAT International Edition format for major products and releases
- SLDS (Lightning Design System): 900+ HTML blueprints with detailed accessibility guidelines, including proper ARIA roles/states/properties, keyboard navigation patterns, focus management, and color contrast compliance
- An internal accessibility team that ensures product teams' "definition of done" includes WCAG 2.2 AA conformance
Experience Cloud–Specific Accessibility Features
The Experience Cloud LWR ACR shows "Partially Supports" for most WCAG 2.x categories — indicating a strong baseline with documented exceptions. Specific features include:
- Alt text support for images in the Rich Content Editor
- Accessible navigation menus and buttons with proper ARIA tags and keyboard operability
- Heading structure (H1–H6) support in the Rich Content Editor for proper document hierarchy
- Branding sets for centralized color palette management — enabling enforcement of contrast-compliant color combinations across the entire site
- Standard Lightning components (data tables, forms, tabs, accordions, carousels) built to SLDS accessibility standards
- Built-in pause controls on SLDS Carousel components for users with vestibular disorders
The Platform Does the Heavy Lifting
When you use standard Experience Cloud components and follow SLDS guidelines, the vast majority of WCAG 2.2 AA requirements are already met. The platform handles focus management, keyboard navigation, ARIA labeling, and color contrast — the same things overlays claim to fix.
Where the Real Accessibility Gaps Exist
If the platform provides a strong baseline, where do Experience Cloud sites actually fail accessibility standards? The answer is almost always in the areas overlays cannot reach.
1. Custom Components with Non-Standard HTML
Custom Lightning Web Components (LWC) or Aura components that don't follow SLDS patterns are the #1 source of accessibility failures. Common issues include:
- Missing ARIA attributes (roles, states, properties)
- No keyboard navigation support
- Incorrect focus management (focus not returning to trigger after modal close, focus trapped in components)
- Missing or incorrect form labels
- Custom interactive elements not announced by screen readers
Overlays can't fix this because the issues are structural — they exist in the component's internal DOM, often behind Shadow DOM boundaries that overlay scripts cannot penetrate.
2. Custom CSS Overrides Breaking Contrast
Brand CSS that overrides SLDS defaults frequently fails WCAG AA contrast ratios:
- Normal text: Requires 4.5:1 contrast ratio
- Large text (18px+ or 14px+ bold): Requires 3:1 contrast ratio
Organizations apply brand colors without validating contrast, creating failures across buttons, links, headings, and body text. While overlays offer a contrast toggle, this puts the burden on the user to fix what should be correct by default — and it doesn't work consistently across all page elements.
3. Content Authoring Failures
The most common — and most preventable — accessibility gaps come from content, not code:
- Missing alt text on images (or meaningless alt text like "image1.jpg")
- Improper heading hierarchy (jumping from H1 to H4, using headings for visual styling rather than structure)
- "Click here" link text that provides no context when read by screen readers
- Inaccessible uploaded PDFs linked from portal pages
- Videos without captions or transcripts
Overlays attempt to address some of these through AI, but AI-generated alt text is unreliable, and no overlay can fix a PDF that was created without accessibility in mind.
4. Third-Party AppExchange Packages
Experience Cloud sites frequently include AppExchange components that may or may not meet accessibility standards. Salesforce has introduced an "Accessible Solutions" tag in partnership with its Office of Accessibility, requiring ISVs to conduct self-audits and link to ACRs in their listings. However, adoption is still early, and many installed packages lack accessibility documentation.
5. Complex Interaction Patterns
Multi-step forms, dynamic content loading, modals, search/filter interactions, and real-time data updates often lack:
- ARIA live regions to announce dynamic changes
- Proper focus trapping in modal dialogs
- Loading state announcements for screen readers
- Error message association with form fields
These patterns require deliberate accessibility engineering — something no overlay can automate.
Salesforce Ecosystem Accessibility Tools
Salesforce and the broader ecosystem provide purpose-built tools for identifying and fixing accessibility issues — tools that produce actionable results overlays cannot match.
sa11y — Salesforce's Open-Source Accessibility Testing Framework
sa11y (combining "Salesforce" + "a11y") is Salesforce's own open-source accessibility testing framework, built on the widely trusted axe-core engine.
- What it does: Provides JavaScript libraries for Jest, Vitest, and WebdriverIO tests that validate custom LWC components against WCAG standards
- CI/CD integration: Designed to run in continuous integration pipelines, catching accessibility regressions before code reaches production
- Internal usage: Salesforce runs sa11y daily in its own Jest and Selenium build frameworks — including testing Agentforce updates
- Reduced false positives: Engineered to minimize false positives and negatives so developers trust the results
- Best for: Validating custom LWC components on Experience Cloud sites as part of the development process
As detailed in Salesforce's developer blog, sa11y integrates directly into the development workflow, making accessibility testing a natural part of building Experience Cloud components.
WAVE (Web Accessibility Evaluation Tool)
WAVE is a free browser extension (Chrome, Firefox, Edge) by WebAIM that evaluates rendered pages for accessibility issues.
- Identifies missing alt text, heading problems, contrast violations, and ARIA errors
- Visual overlay shows exactly where issues occur on the page
- Non-technical — content authors, designers, and QA can all use it
- Best for: First-pass audit of every Experience Cloud page template
WebAIM Contrast Checker
WebAIM Contrast Checker is a web-based tool that evaluates color combinations against WCAG contrast ratios.
- Enter foreground and background colors to instantly see pass/fail for AA and AAA standards
- Best for: Validating brand colors in Experience Cloud branding sets before applying them site-wide
axe DevTools (Deque Systems)
axe DevTools is a browser extension and commercial product from the creators of axe-core (the engine powering sa11y).
- Free browser extension covers automated checks on any rendered page
- Paid tier adds guided manual testing workflows
- Best for: Comprehensive in-browser accessibility analysis during development and QA
AppExchange "Accessible Solutions" Tag
Salesforce's Accessible Solutions tag helps identify AppExchange packages that have undergone accessibility self-audits.
- ISVs must conduct a self-audit and link to an ACR in their listing
- Best for: Evaluating third-party components before installing them on your Experience Cloud site
The Right Approach: Audit, Remediate, Govern
Instead of bolting on a widget that creates new problems, organizations should invest in a systematic approach that produces documented, defensible accessibility compliance.
Phase 1: Accessibility Audit
A thorough audit establishes your baseline and identifies every gap that needs attention:
- Automated scanning using WAVE, axe-core, and sa11y against every page template
- Manual keyboard testing across all primary user flows — tab through every page, operate every interactive element
- Screen reader testing with NVDA (Windows) and VoiceOver (Mac/iOS) on critical paths
- Browser zoom testing at 200% and 400% magnification
- Content audit reviewing all images, headings, link text, and linked documents
- Custom component review checking ARIA attributes, keyboard navigation, and focus management
- AppExchange package review verifying Accessible Solutions tags and VPATs for installed packages
Deliverable: An Accessibility Conformance Report (ACR) in VPAT International Edition format, plus a prioritized remediation backlog with severity ratings.
Phase 2: Remediation
With a prioritized backlog, remediation addresses issues systematically:
- Branding set corrections to achieve WCAG AA contrast ratios across all color combinations
- Content fixes — adding meaningful alt text, correcting heading hierarchy, rewriting link text, remediating PDFs
- Custom component updates — adding missing ARIA attributes, implementing keyboard navigation, fixing focus management
- Template-level fixes — ensuring proper page structure, skip navigation links, and landmark regions
- sa11y integration into CI/CD — preventing accessibility regressions in future development
Phase 3: Governance and Sustainability
Accessibility isn't a one-time fix — it requires ongoing governance:
- Content authoring guidelines and training for everyone who publishes to the portal
- Pre-publish QA checklist including accessibility checks
- Quarterly automated rescanning to catch regressions
- VPAT maintenance updated with each significant site change
- Documented processes that demonstrate ongoing commitment to accessibility
Cost Comparison: Overlay vs. Proper Accessibility Program
| Factor | Accessibility Overlay | Audit + Remediation + Governance |
|---|---|---|
| Annual Cost | $350–$6,000/year | $15,000–$30,000 (initial) |
| Legal Documentation | None | Full VPAT/ACR, remediation logs, governance records |
| Actual Remediation | Cosmetic only | Structural fixes to code, content, and components |
| ADA Lawsuit Defense | None (often cited as additional barrier) | Strong documented compliance program |
| FTC Risk | High (deceptive compliance claims) | None |
| Ongoing Value | Dependency with no cumulative benefit | Each fix permanently improves the site |
| User Experience | Interferes with existing assistive technology | Works seamlessly with all assistive technology |
A typical Experience Cloud site with 10–20 page templates and moderate custom components can expect an audit and initial remediation engagement in the $15,000–$30,000 range — delivering documented compliance, actual fixes, and a governance framework. Optional ongoing managed services maintain compliance over time.
Compare this to an overlay subscription that provides zero legal protection, zero documentation, and zero actual remediation — while actively increasing your risk profile.
Best Practices for Experience Cloud Accessibility
- Start with SLDS components. Use standard Lightning components wherever possible — they carry the strongest accessibility baseline.
- Validate branding sets with contrast checkers. Before applying brand colors, verify every combination meets WCAG AA ratios (4.5:1 for normal text, 3:1 for large text).
- Integrate sa11y into your CI/CD pipeline. Catch accessibility regressions in custom components before they reach production.
- Train content authors. Most accessibility failures come from content, not code. Invest in training for everyone who publishes to the portal.
- Require VPATs for AppExchange packages. Before installing any third-party component, verify it has an Accessibility Conformance Report.
- Test with real assistive technology. Automated tools catch roughly 30–40% of accessibility issues. Manual testing with NVDA, VoiceOver, and keyboard-only navigation is essential.
- Document everything. Your accessibility program's value in litigation depends on documentation — audit reports, remediation logs, training records, and governance processes.
- Remove any installed overlays. If you currently have an overlay widget, remove it. It provides no legal protection and may be actively harming your users and your legal position.
Frequently Asked Questions
Can EqualWeb or other overlays work with Salesforce Experience Cloud?
Yes, it's technically possible through CSP configuration and custom components, but it requires workarounds that add an external dependency to a platform designed to control external scripts. More importantly, installing an overlay provides no legal protection and may actually increase legal risk — the FTC fined accessiBe $1 million for deceptive compliance claims, and approximately 100 companies have been sued after installing overlay widgets.
Does Salesforce Experience Cloud support WCAG compliance?
Yes. Salesforce strives for WCAG 2.2 AA conformance and publishes Accessibility Conformance Reports (ACRs) for its products. Standard Experience Cloud components built on the Lightning Design System (SLDS) include proper ARIA roles, keyboard navigation, focus management, and color contrast compliance. The real accessibility gaps exist in custom components, CSS overrides, and content authoring practices — not in the platform itself.
What tools should I use to test my Experience Cloud site for accessibility?
Use a combination of tools: WAVE (free browser extension) for visual page-level scanning, sa11y (Salesforce's open-source framework) for automated CI/CD testing of custom LWC components, WebAIM Contrast Checker for validating color combinations, and axe DevTools for comprehensive in-browser analysis. Supplement automated tools with manual keyboard navigation testing and screen reader testing using NVDA and VoiceOver.
Is an accessibility overlay enough for ADA compliance?
No. Overlays produce none of the governance documentation required for an ADA enforcement defense — no dated audit reports, no remediation logs, no training records, no VPATs. Approximately 100 companies have been sued after installing overlays, and the FTC fined accessiBe $1 million for claiming its automated product could ensure compliance. Overlays address cosmetic surface-level issues while leaving structural accessibility gaps untouched.
How much does it cost to make an Experience Cloud site accessible?
A proper accessibility audit and remediation engagement for a typical Experience Cloud site (10–20 page templates, moderate custom components) costs approximately $15,000–$30,000. This delivers an ACR in VPAT format, actual structural fixes to code and content, and a governance framework — none of which an overlay subscription ($350–$6,000/year) provides.
What is sa11y and how does it help with Experience Cloud accessibility?
sa11y is Salesforce's open-source accessibility testing framework, built on the axe-core engine. It provides JavaScript libraries for Jest, Vitest, and WebdriverIO tests that validate custom Lightning Web Components against WCAG standards. Salesforce uses sa11y internally in its own build pipelines, and it's available on GitHub for any organization to integrate into their CI/CD workflow.
Do accessibility overlays interfere with screen readers?
Yes, frequently. Overlay widgets inject additional ARIA attributes and DOM modifications that can conflict with existing assistive technology configurations. Many users with disabilities report that overlays make sites harder to use, not easier. The Overlay Fact Sheet — signed by over 800 accessibility professionals — documents these conflicts and catalogs all major overlays as unnecessary and limited in accuracy.
Conclusion
Accessibility overlays promise a quick fix, but they deliver the opposite — increased legal risk, user hostility, regulatory exposure, and a false sense of compliance. On Salesforce Experience Cloud specifically, overlays fight against a platform that already provides robust native accessibility infrastructure.
The path to genuine accessibility compliance is straightforward: audit your Experience Cloud site against WCAG 2.2 AA standards, remediate the gaps that exist in custom components, content, and branding, and govern your accessibility program with documented processes and ongoing monitoring.
Vantage Point delivers the full audit → remediate → govern engagement for Experience Cloud sites. Our senior consultants understand both Salesforce platform architecture and accessibility compliance requirements — a combination most consultancies can't offer. We're vendor-agnostic on tooling, recommending sa11y, WAVE, axe DevTools, and manual testing based on your specific site's needs.
Don't wait for a demand letter or a lawsuit to take accessibility seriously. Contact Vantage Point to schedule an Experience Cloud accessibility assessment and build a compliance program that actually protects your organization.
About Vantage Point
Vantage Point is a technology consultancy specializing in CRM implementation, integration, and AI solutions. As partners with Salesforce, HubSpot, Anthropic (Claude AI), Aircall, and Workato, Vantage Point helps organizations across all industries optimize their technology investments for growth, efficiency, and compliance. Our services span Salesforce (Sales Cloud, Service Cloud, Experience Cloud), HubSpot CRM, MuleSoft integration, Data Cloud, and AI personalization — including specialized accessibility expertise for digital experience platforms.
