Salesforce

Salesforce admins and developers use Lightning components, design-system markup, and accessibility status reports to build CRM workflows that disabled workers can use when sales and service work runs through Salesforce.

ENABLE Model location

• Builder-side Interventions → Set Requirements that Include Accessibility
• Builder-side Interventions → Design Accessible Experiences
• Builder-side Interventions → Develop Accessible Implementations
• Builder-side Interventions → Iterate to Address Shortcomings
• builder-side/support-channels

What it is

Salesforce sells the CRM platform that IDC ranked first worldwide for the twelfth consecutive year in 2025, with a 20.7% share of the CRM market in 2024.¹ Organizations run sales, service, and related administrative work through it.¹

Salesforce grew a formal accessibility layer over that platform across the Lightning era. Its own design-system history traces the current stack back to a 2013 pattern library, a 2015 redesign of Salesforce Classic into Lightning Experience, and the 2015 to 2016 rollout of the Salesforce Lightning Design System into core product code.² Catherine Nichols leads Salesforce's Office of Accessibility, and Derek Featherstone has publicly described the company's "shift left" approach as moving disability participation and inclusive design earlier into research, design, and development.³⁴ Salesforce now says product teams' definition of done must conform to WCAG 2.2 AA, that products are reviewed through research, internal testing, audits, and customer feedback, that accessibility conformance reports are completed both internally and through third-party vendors, and that an accessibility support desk works with customers to build accessible Salesforce environments.³⁵

People use that infrastructure in different ways. Salesforce engineers use Lightning base components and SLDS markup to ship more accessible interfaces upstream through design and development.⁶ Salesforce admins and consultants use page layouts, design patterns, accessibility guidance, and conformance reports to configure orgs for disabled coworkers and customers.⁷⁸ Disabled workers then meet the platform with screen readers, magnifiers, browser settings, and other assistive technologies when the builder-side care lands unevenly across products, implementations, and local customizations.⁷⁹

Why it matters

Enterprise software became workplace infrastructure before any legal framework required it to work with screen readers or keyboard navigation. The commercial market for business applications, from HR and ERP systems through the 1980s to web-based CRM platforms through the late 1990s, organized itself around sighted users operating mouse-driven graphical interfaces. Section 508 of the Rehabilitation Act, substantially strengthened in 1998, established enforceable accessibility requirements for federal electronic information technology, but its reach stopped at the federal agency boundary.¹⁰ Private-sector employers were governed by ADA Title I's reasonable accommodation requirement, which placed the compliance obligation on employers rather than on the software vendors they purchased from.¹¹ When the National Federation of the Blind sued Oracle and the State of Texas in 2007 over inaccessible PeopleSoft HR software that blind state employees were required to use, it was the first major litigation naming an enterprise software product as inaccessible to blind workers.¹² Oracle was dismissed from that lawsuit; the legal architecture confirmed that the employer, not the vendor, bore the accessibility obligation. A 2020 federal ruling dismissing the NFB's claim against Epic Systems, over an EHR update that broke screen-reader compatibility for blind hospital dispatchers, reaffirmed the same structure: Epic sold the software; Brigham and Women's Hospital bore the accommodation duty.¹³ Salesforce entered this legal landscape in 2000, a company selling platforms to employers who held the accessibility obligation while Salesforce designed the product. Its own design-system history traces the gradual institutionalization of accessibility inside software already running workplace operations: a 2013 pattern library, a 2015 Lightning redesign, a 2015 to 2016 SLDS rollout, and a current stated standard of WCAG 2.2 AA conformance.²⁵ Access followed the product migration path.

Salesforce accessibility depends on social organization inside customer workplaces as much as on code from San Francisco. Salesforce tells teams to make WCAG 2.2 AA part of the product definition of done, operates an accessibility support desk, and writes accessibility expectations into its supplier code.³ But disabled workers still rely on local admins, consultants, accessibility offices, and coworkers to decide which page layouts, builders, tabs, accordions, themes, and third-party apps will structure the workday. Salesforce Ben reported that JAWS and NVDA "generally handle the front end of Salesforce quite well," but that blind professionals still need workarounds in the backend.⁷ The University of Wisconsin's testing found keyboard, screen-reader, and magnification barriers in both the general platform and Experience Builder, including drag-and-drop patterns that were impossible for keyboard-only and screen-reader users to operate.⁸¹⁴ The sociology here is the delegated labor of local configuration, not product design alone.

Salesforce's 20.7% global CRM market share means disabled workers in sales and service organizations often have no practical option to switch to an alternative when a workflow becomes inaccessible.¹ Organizations buy licenses and customize heavily because they expect Salesforce to become core infrastructure. Salesforce publishes accessibility conformance reports, but it also states that a public ACR does not become part of a contract unless the contract expressly says so.⁵ That matters politically and economically: accessibility evidence circulates in procurement, but enforceable obligation can still thin out at the point of sale. The platform also pushes accessibility responsibility downstream into customer build choices. Salesforce's accessibility support team, SLDS, and base components reduce some of that labor, but blind workers, low-vision workers, and the admins who support them still pay the adaptation tax in configuration time, magnification tools, browser plugins, admin hours, and delays when a specific builder or cloud product falls short.³⁷⁸

Fatigue, eye strain, stress, and lost work time build up when enterprise software requires repeated workaround loops. A 2023 workplace technology study found that 59.1% of blind and low-vision workers reported trouble accessing specific software, websites, databases, or digital documents, making that the most common challenge in workplace assistive-technology use.⁹ A 2007 study of 100 blind web users found they lost 30.4% of their time to frustrating accessibility failures.¹⁵ Salesforce-specific guidance adds the bodily detail. Salesforce Ben notes that browser zoom in the Salesforce interface is often clunky, that list views can collapse until only one or two lines remain visible, and that dark themes or plugins may become necessary for workers dealing with cataracts, migraines, photophobia, or low contrast.⁷ When enterprise systems make basic reading, navigation, or editing laborious, the result is cumulative exhaustion in the part of life that pays the rent.

Salesforce marks a real frontier in enterprise accessibility, but the frontier remains uneven across a very large product estate. Salesforce has built a formal Office of Accessibility, a design system, accessible base components, public conformance reports, supplier expectations, and customer-facing support.³⁵⁶ At the same time, its own 2025 Accessibility Conformance Report for Einstein Conversation Insights states that the audited product does not support some prerecorded audio alternatives and captions and lists multiple structural issues for screen-reader users.¹⁶ University testing of Experience Builder likewise found keyboard access impossible in critical areas and screen-reader access broken in the HTML editor and page menus.⁸ Salesforce advances the state of the possible for enterprise software, but it still distributes disabled access unevenly across clouds, builders, and local implementations.

Real-world examples

In the news

Inclusive Design Is Central to Accessible Product Development (June 2025)
-- Jeffrey Howard, InclusionHub

• Derek Featherstone described Salesforce's "shift left" practice as bringing disabled people into research and design before launch and treating them as co-creators rather than end-stage approvers.⁴ The article documents how requirement-setting, design, and iteration can be structured to move disability participation upstream rather than waiting for disabled workers to give feedback after the barrier ships.

In the news

Making Salesforce Easier for End Users With Visual Disabilities (August 2023)
-- R. Rayne Clark, Salesforce Ben

• Salesforce Ben documented how blind and low-vision professionals actually get work done in Salesforce: screen readers generally work on the front end, browser zoom can collapse list views, and admins often need to rebuild Lightning page layouts around headings and linear flow.⁷ The article is ethnography of local development and downstream user-workarounds from a practitioner community that lives inside the gap between product defaults and disabled workers' actual needs.

In the news

Blind Texas Employees File Lawsuit Against State, Oracle (February 2007)
-- Computerworld

• The National Federation of the Blind and three blind Texas state employees sued Oracle and the State of Texas over inaccessible PeopleSoft HR applications that blind state workers were required to use. The plaintiff Edwin Kunz, who directed a state rehabilitation center for the blind, stated that the inaccessible HR software forced him to rely on sighted assistance for personnel functions, violating his and his staff's privacy. Oracle was dismissed from the lawsuit in 2008; the legal outcome established what remained true for subsequent enterprise software cases: the employer bears the accessibility obligation, not the software vendor. That structure governs how enterprise software companies, including Salesforce, operate. Vendors design the platform; employers decide whether to accommodate workers who cannot use it.

In the news

Epic found not liable for product inaccessible to blind employee (2020)
-- Healthcare Dive

• A federal court dismissed the NFB's claim against Epic Systems over an EHR update that broke screen-reader compatibility for a blind hospital dispatcher at Brigham and Women's Hospital. The court ruled that Epic "simply sold and licensed its software" and that a vendor's knowing sale of inaccessible software does not trigger liability for how employer customers treat disabled employees. The ruling applies directly to the legal environment Salesforce operates in: Salesforce sells the platform; the employer configures it and bears the accommodation obligation.

• University of Wisconsin documents general Salesforce platform barriers for low-vision, keyboard-only, and screen-reader users, while separately warning that Experience Builder contains drag-and-drop and editor patterns that can make authoring impossible for blind and keyboard-only builders.⁸¹⁴
• Salesforce changed colors, icons, buttons, links, and warning messages across Lightning in 2023 after an internal low-vision study found users could not reliably distinguish key interface elements against lightly colored backgrounds.¹⁷
• Salesforce's 2025 Einstein Conversation Insights ACR states that the audited product does not support transcripts for recorded audio-only calls, does not support captions for prerecorded audio-video content, and still carries multiple screen-reader structure and announcement problems.¹⁶
• Salesforce Ben advises blind and low-vision admins to restructure Lightning record pages differently depending on whether a user navigates by screen reader or by magnification, showing how much accessibility still depends on local page configuration rather than product defaults.⁷
• The NFB adopted Resolution 2025-09 in July 2025, specifically targeting enterprise B2B SaaS tools and naming Monday.com, Smartsheet, Atlassian, Carta, and Upwork as having "significant accessibility defects." The resolution demands WCAG 2.2 AA compliance, blind user testing before release, and published accessibility roadmaps.¹⁸ Salesforce is not named. The resolution signals that the NFB is extending organized accessibility pressure from consumer-facing platforms into the enterprise software market that employs disabled workers.

What care sounds like (builder-side interventions)

Care at Salesforce involves turning accessibility into requirement-setting, design, and development work that product teams and customers can actually use:

• "Within the Salesforce ecosystem, we make sure product teams' 'definition of done' is conformant with industry standard WCAG 2.2 AA."³
• "We review issues and integrate plans to address them in our ongoing product development roadmap."⁵
• "We also operate an accessibility support desk that works with customers to build accessible Salesforce environments."³

What neglect sounds like (builder-side interventions)

Neglect appears when enterprise software treats accessibility as optional, local, or deferrable:

• "Accessibility features in Salesforce Classic are no longer maintained or enhanced."⁵
• "Use the drag-and-drop builder. Keyboard users can get help if they need it."
• "The platform is accessible enough out of the box. Admins can handle the rest."

What compensation sounds like (navigator-side compensations)

Compensation describes the labor disabled workers and local admins undertake when upstream care lands unevenly:

• "The backend is also generally screen reader friendly, though workarounds are sometimes needed to help blind Salesforce professionals do their jobs in the same manner as their fully sighted peers."⁷
• "I need a different page layout, more headings, and fewer tabs just to move through records at work."
• "Browser zoom breaks the list view, so I switch to magnification software and plugins to finish the task."

---

All observations occur within the context of U.S. enterprise CRM procurement and workplace software use, where organizations configure Salesforce as daily infrastructure while disabled workers absorb the consequences of how that infrastructure is built and customized.

Footnotes

1. Salesforce Ranked #1 CRM Provider for 12th Consecutive Year ↩ ↩² ↩³

2. Learn How and Why We Developed SLDS ↩ ↩²

3. Salesforce's Accessibility Approach ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

4. Inclusive Design Is Central to Accessible Product Development ↩ ↩²

5. Product Accessibility Status ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

6. Base Components Accessibility ↩ ↩²

7. Making Salesforce Easier for End Users With Visual Disabilities ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

8. Salesforce Experience Builder Accessibility and Usability Information ↩ ↩² ↩³ ↩⁴ ↩⁵

9. Assistive Technology Use in the Workplace by People with Blindness and Low Vision: Perceived Skill Level, Satisfaction, and Challenges ↩ ↩²

10. Section 508 — U.S. Access Board ↩

11. ADA Title I — EEOC ↩

12. Blind Texas Employees File Lawsuit Against State, Oracle — Computerworld, February 2007 ↩

13. Epic Found Not Liable for Product Inaccessible to Blind Employee — Healthcare Dive, 2020 ↩

14. Salesforce Platform Accessibility and Usability Information ↩ ↩²

15. What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users ↩

16. Salesforce Einstein Conversation Insights 258 FY26 Accessibility Conformance Report ↩ ↩²

17. Updates to the Salesforce UI That Will Improve Accessibility for Low-Vision Users ↩

18. NFB Resolution 2025-09 — National Federation of the Blind, July 2025 ↩