Case Studies

Salesforce Accessibility for Enterprise: Lightning, VPATs, and Compliance

By EZUD Published · Updated

Salesforce Accessibility for Enterprise: Lightning, VPATs, and Compliance

Salesforce is the world’s largest CRM platform, used by organizations of all sizes including government agencies, healthcare systems, financial institutions, and educational institutions that face strict accessibility requirements. When an enterprise platform like Salesforce is inaccessible, it can prevent employees with disabilities from doing their jobs. This case study examines Salesforce’s accessibility posture, what the platform offers, and what customers should evaluate.

Salesforce’s Accessibility Commitment

Salesforce aligns its products with Section 508 of the Rehabilitation Act and the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA. The company publishes Accessibility Conformance Reports (ACRs), often referred to as Voluntary Product Accessibility Templates (VPATs), which document how well each Salesforce product conforms to accessibility standards.

Salesforce uses the International edition of the VPAT, which maps to multiple standards including Section 508, WCAG 2.x, and the European standard EN 301 549. The ACR portfolio covers Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud, and other products, with each report updated per release cycle.

Lightning Experience vs. Salesforce Classic

This distinction matters significantly for accessibility. Salesforce Classic, the older interface, is no longer maintained or enhanced for accessibility. Salesforce explicitly recommends that organizations migrate to Lightning Experience, which offers the latest accessibility features and ongoing improvements.

Lightning Experience was built with accessibility as a design consideration from the start. Key accessibility features include:

  • Keyboard navigation throughout the interface, including record pages, list views, dashboards, and the App Launcher.
  • Screen reader support tested with JAWS, NVDA, and VoiceOver.
  • ARIA landmarks and roles that help screen reader users orient themselves within the complex Salesforce interface.
  • Skip navigation links that allow keyboard users to bypass repetitive header content.
  • High-contrast mode available through the platform’s theme settings.

The Lightning Web Runtime, used for Experience Cloud (formerly Community Cloud), received a VPAT update in March 2025, documenting conformance with WCAG standards for both desktop and mobile web.

What Customers Should Evaluate

Salesforce is a platform, not a single product. The accessibility of any given Salesforce implementation depends on both the base platform and the customizations built on top of it. Organizations should evaluate:

Base platform conformance. Review the latest ACR for the specific Salesforce product being used. ACRs are available on Salesforce’s Product Accessibility Status page and are updated regularly.

Custom components. Lightning Web Components, Visualforce pages, Apex-driven UIs, and AppExchange packages built by third parties may not conform to the same accessibility standards as the base platform. Every custom component should be tested independently.

Content accessibility. Data entered into Salesforce, including help text, field descriptions, email templates, and knowledge articles, must be created accessibly. The platform cannot compensate for inaccessible content.

Configuration choices. Page layouts, record types, and Lightning pages can be configured in ways that help or hinder accessibility. Keeping page layouts clean, using clear field labels, and avoiding overly complex dashboards all contribute to an accessible experience.

The Blind Salesforce Developer Perspective

Matt Ater, a blind Salesforce developer, has spoken publicly about using Salesforce with a screen reader. His experience highlights both the platform’s strengths (functional keyboard navigation in Lightning, well-labeled standard components) and its challenges (complex dashboards that generate excessive screen reader output, third-party AppExchange packages with poor accessibility). His perspective underscores the importance of testing with real assistive technology users, not just automated scanners.

Recommendations

Organizations deploying Salesforce in regulated environments should require Lightning Experience for all users, include accessibility requirements in any custom development specifications, test AppExchange packages with screen readers before deployment, and train administrators and content authors on accessible content creation. Salesforce’s accessibility team can be contacted at [email protected] for specific conformance questions.

For related enterprise accessibility content, see accessible workplace tools: Slack, Teams, and Zoom and banking and finance accessibility guide. For the full collection, visit the universal design case studies guide.

Key Takeaways

  • Salesforce publishes Accessibility Conformance Reports (VPATs) for each product, aligned with Section 508, WCAG 2.0 AA, and EN 301 549.
  • Lightning Experience is the only actively maintained interface for accessibility; organizations should migrate from Salesforce Classic.
  • Custom components, AppExchange packages, and content entered into Salesforce must be separately tested for accessibility compliance.
  • Real-user testing with screen readers reveals issues that automated checks and VPATs cannot capture, particularly in complex dashboards and third-party integrations.

Sources

More in Case Studies

Universal Design Case Studies Guide: How Leading Organizations Build Accessibility Guide Worst Accessibility Fails and Lessons Learned Accessible Startup Design From Day One: Building Inclusion Into Your Product Accessible Nonprofit Websites: Compliance, Best Practices, and Legal Landscape

View all Case Studies articles →