Accessibility¶

Accessibility is a fundamental requirement of everything built on the platform. It is not a feature, a phase, or a later remediation project: a change that introduces a barrier for people with disabilities is a defect, in the same way that a change that introduces a security vulnerability is a defect.

Why Accessibility Is Fundamental¶

A Salesforce org serves many people: customers on Experience Cloud sites, members of the public using government services, and the staff who work in the org every day. Some of them use screen readers, screen magnifiers, voice control, switch devices, or the keyboard alone, and some have cognitive, hearing, or motor disabilities that no assistive technology fully offsets. An inaccessible page, component, or screen Flow shuts those people out of the service or out of their job.

Accessibility is also the law. In both the United States and Australia, federal law requires that digital services, including internal tools used by employees, be usable by people with disabilities. The laws are summarised below.

Salesforce builds its standard products to WCAG and publishes Accessibility Conformance Reports for them (Product Accessibility Status), but those reports cover only what Salesforce ships. Custom Lightning Web Components, Aura components, Visualforce pages, screen Flows, Experience Cloud sites, and page layouts are the responsibility of the company that builds them. A company cannot rely on Salesforce's conformance to cover its own customisations.

The Standard: WCAG 2.2 Level AA¶

Everything built on the platform conforms to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. WCAG is organised around four principles: content must be perceivable, operable, understandable, and robust.

An International Standard¶

WCAG is not the standard of any one country. It is published by the World Wide Web Consortium (W3C), the international body that sets the standards for the web, to give people, organisations, and governments everywhere one standard to share for accessible web content. WCAG 2.2 is also an international standard in its own right: ISO/IEC 40500:2025. Where a law or guideline on this page names a technical standard for web content, it names WCAG or a standard built on WCAG, so one baseline can serve a company in the United States, a company in Australia, and a company in both.

One Baseline for the United States and Australia¶

The two countries name different WCAG versions, and both name Level AA.

Each WCAG 2 version builds on the last, so conforming to WCAG 2.2 Level AA meets the Level AA success criteria of WCAG 2.0 and 2.1 as well. (The one criterion removed in 2.2, 4.1.1 Parsing, is treated as always satisfied for HTML under the errata to the earlier versions.) One baseline therefore satisfies every law on this page, in both countries:

• In Australia, WCAG 2.2 Level AA is the standard that Australian guidance itself names. Nothing on this page asks an Australian company to meet a United States standard.
• In the United States, the baseline is a later version than the regulations cite, and it meets them.

There is one baseline, not one for each country. The laws are summarised under United States Law and Australian Law below.

Salesforce's own sources name different versions: its compliance pages state WCAG 2.2 AA as the definition of done for its products, while the Salesforce Lightning Design System documentation states WCAG 2.1 AA. The baseline here is WCAG 2.2 AA regardless.

Why Level AA¶

WCAG sorts its success criteria into three levels. Level A is the minimum, Level AA includes Level A and adds to it, and Level AAA includes both and adds again. The baseline is Level AA for three reasons:

• Level A is not enough. Criteria that many people depend on sit at Level AA, among them text contrast (1.4.3), text that can be resized (1.4.4), and a visible keyboard focus (2.4.7). A page can conform at Level A and still be unreadable for someone with low vision, and give someone who works with the keyboard alone no sign of where the focus is.
• Level AA is the level the law names. Every law and guideline on this page that names a level names Level AA.
• Level AAA cannot be required of everything. W3C itself advises against requiring Level AAA as a general policy for a whole site, because some content cannot meet every Level AAA criterion. Level AAA asks, for example, for sign language interpretation of the prerecorded audio in every video (1.2.6), and for a simpler version of any text that needs more than a lower secondary reading level (3.1.5). A baseline is a standard that every change can be held to (Pragmatism, with Visible Exceptions), and Level AAA as a whole is not.

Level AA is the minimum for every change, not the limit. Level AAA success criteria are adopted wherever they are practical; the SLDS mobile guidance, for example, already asks for touch targets of 44 pixels, which meets the Level AAA target size (2.5.5) rather than the 24-pixel Level AA minimum (2.5.8).

How Accessibility Is Enforced¶

Like every standard on this site, accessibility is enforced in the pipeline rather than left to good intentions:

• Lightning Web Components are tested with sa11y, Salesforce's accessibility testing library built on axe-core. The @sa11y/jest assertions run in the component Jest tests (Section 5), so an accessibility failure fails the build.
• Visualforce and Aura pages are tested in a rendered browser with @sa11y/wdio, because axe-core inspects the live page regardless of the technology that produced it.
• Static analysis catches the failures visible in source, such as the image rules ImageWithoutAltVf (Visualforce) and ImageWithoutAltHtmlLwcAura (HTML, Lightning Web Components, and Aura) in Appendix F.2, and the accessibility rules in the LWC ESLint configuration.
• Manual testing covers what automated tools cannot. Automated checks find only a subset of WCAG failures, so every user-facing change is also tested with the keyboard alone and with a screen reader before it is accepted.

Building with the Salesforce Lightning Design System makes the baseline easier to reach. Lightning base components and the styling hooks of SLDS 2 are designed to be accessible, so a page built from them starts much closer to conformance than one built from custom markup and CSS (Built-In First). They do not make a page conform on their own: the checks above still apply.

The standards for alternative text and for the names of buttons and links are on the Code Standards General page, under Accessibility. The other markup-level standards (labels, keyboard operation, focus visibility, colour and contrast) are set out on the HTML and Visualforce page.

Accessibility applies to the people who build the org too. Apex, Visualforce, HTML, JavaScript, and CSS are indented with tabs rather than spaces, because a tab's width is set by each reader: developers with low vision can choose the indent size they need, and developers using refreshable braille displays do not lose cells to runs of spaces.

United States Law¶

There is no single United States digital accessibility law. Several federal laws apply, depending on who provides the service and who funds it.

Section 508 of the Rehabilitation Act¶

Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. § 794d), as amended in 1998, requires federal agencies to make the information and communication technology (ICT) they develop, procure, maintain, or use accessible to employees and members of the public with disabilities. The Revised 508 Standards, published by the US Access Board on 18 January 2017 and enforceable from 18 January 2018 (36 CFR Part 1194), incorporate WCAG 2.0 Level A and AA by reference and apply them to web content, electronic documents, and software alike.

For Salesforce work, this means a Salesforce org used by a federal agency, and every customisation built in it, is ICT under Section 508. Vendors selling ICT to federal agencies document conformance in an Accessibility Conformance Report, usually prepared with the ITI Voluntary Product Accessibility Template (VPAT); Salesforce publishes its own on its accessibility page. OMB memorandum M-24-08, "Strengthening Digital Accessibility and the Management of Section 508", sets out how agencies are to manage their Section 508 programs.

Other Sections of the Rehabilitation Act¶

• Section 501 prohibits disability discrimination in federal employment, so the internal systems federal employees use must be accessible to them.
• Section 503 prohibits disability discrimination by federal contractors and requires affirmative action in their employment.
• Section 504 prohibits disability discrimination in programs run by federal agencies and in programs receiving federal financial assistance.

The Department of Health and Human Services' Section 504 rule of May 2024 (45 CFR Part 84) adopts WCAG 2.1 Level AA for the websites and mobile apps of organisations that receive HHS funding, which includes most hospitals and health care providers that accept Medicare or Medicaid. In May 2026, HHS extended the compliance dates by one year: recipients with 15 or more employees must comply by 11 May 2027, and smaller recipients by 10 May 2028.

Americans with Disabilities Act¶

The Americans with Disabilities Act of 1990 (42 U.S.C. § 12101 and following) prohibits disability discrimination across most of public life:

• Title I covers employment by employers with 15 or more employees. Internal systems, including a Salesforce org used by staff, must be usable by employees with disabilities, with reasonable accommodations where needed.
• Title II covers state and local governments. The Department of Justice's 2024 rule (28 CFR Part 35, Subpart H) requires their websites and mobile apps to conform to WCAG 2.1 Level AA. An interim final rule in April 2026 extended the compliance dates by one year: public entities serving a population of 50,000 or more must comply by 26 April 2027, and smaller entities and special district governments by 26 April 2028.
• Title III covers businesses open to the public. The regulations set no technical standard for websites, but the Department of Justice has long held that Title III applies to them, and WCAG 2.1 Level AA is the benchmark used in settlements and court orders. Courts differ on whether a business with no physical location is covered.

21^st Century Integrated Digital Experience Act¶

The 21^st Century Integrated Digital Experience Act (21^st Century IDEA, 2018) requires executive agencies' new and redesigned websites and digital services to be accessible to people with disabilities in accordance with Section 508, alongside its other modernisation requirements.

Communications Laws¶

Section 255 of the Communications Act requires telecommunications equipment and services to be accessible where readily achievable. The Twenty-First Century Communications and Video Accessibility Act of 2010 (CVAA) extends accessibility requirements to advanced communications services, such as electronic messaging and video conferencing, and to captioning of video programming delivered online. They matter where an org delivers communications features of this kind.

Air Carrier Access Act¶

The Air Carrier Access Act regulations (14 CFR Part 382) require airlines' websites to conform to WCAG 2.0 Level AA and set accessibility requirements for their automated kiosks. They apply to any Experience Cloud site or customer portal through which an airline sells tickets or serves passengers.

Australian Law¶

The Disability Discrimination Act is the foundation. The Australian Human Rights Commission's guidelines explain how to comply with it for digital services, and Australian Government policy and procurement rules set specific technical standards for Commonwealth agencies.

Disability Discrimination Act 1992¶

The Disability Discrimination Act 1992 (Cth) makes disability discrimination unlawful in areas that include employment (section 15), education (section 22), the provision of goods, services, and facilities (section 24), and the administration of Commonwealth laws and programs (section 29). It prohibits both direct and indirect discrimination (sections 5 and 6) and requires reasonable adjustments. The only general defence is unjustifiable hardship (sections 11 and 29A), weighed against all the circumstances of the case.

The Act sets no technical standard and offers no certification, but it plainly covers digital services. In Maguire v Sydney Organising Committee for the Olympic Games (2000), the Human Rights and Equal Opportunity Commission found that the Sydney Olympics website, which a blind user could not use, breached section 24: providing information on a website is a service under the Act, and the claim that fixing it would impose unjustifiable hardship was rejected. Complaints go to the Australian Human Rights Commission under the Australian Human Rights Commission Act 1986, and unresolved complaints can proceed to the Federal Court or the Federal Circuit and Family Court.

Disability Standards¶

Disability Standards made under section 31 of the Act set binding requirements for particular areas. The Disability Standards for Education 2005 apply to the online learning platforms, enrolment systems, and student portals of education providers, and the Disability Standards for Accessible Public Transport 2002 apply to the information that public transport operators provide. Complying with a Disability Standard is compliance with the Act for that area.

Guidelines on Equal Access to Digital Goods and Services¶

The Australian Human Rights Commission's Guidelines on Equal Access to Digital Goods and Services, released in April 2025, replace its earlier World Wide Web Access advisory notes. They set WCAG 2.2 Level AA as the minimum standard for complying with the Act and make clear that the Act's obligations extend beyond websites to software-as-a-service platforms, mobile apps, AI tools, and other digital interfaces, which squarely includes a Salesforce org. The guidelines are not law in themselves, but they are the Commission's view of how the Act applies, and the Commission and the courts take them into account.

Australian Government Digital Services¶

The Digital Transformation Agency's Digital Experience Policy, in effect from 1 January 2025, applies to new and replacement public-facing and staff-facing digital services of Australian Government agencies, through four standards: the Digital Service Standard, the Digital Inclusion Standard, the Digital Access Standard, and the Digital Performance Standard. Criterion 3 of the Digital Service Standard, "Leave no one behind", requires agencies to consider the Disability Discrimination Act 1992 and the Disability Services and Inclusion Act 2023, and to conform to the latest version of WCAG, currently 2.2, at Level AA.

ICT Procurement: AS EN 301 549¶

Standards Australia adopted the European accessibility standard for ICT products and services as AS EN 301 549 in 2016, and updated it to AS EN 301 549:2020. It is part of the Australian Government's ICT procurement policy, and state and territory governments use it as well. Its web requirements map to WCAG 2.1 Level AA, and it extends accessibility requirements to software, documents, and hardware, so a vendor supplying a Salesforce solution to an Australian Government agency can expect to demonstrate conformance with it.

International Obligations¶

Australia ratified the United Nations Convention on the Rights of Persons with Disabilities in 2008. Article 9 of the Convention requires States Parties to ensure access for people with disabilities to information and communications technologies and systems, and it informs how the Disability Discrimination Act is applied.

State and Territory Law¶

This page covers federal law only. US states and Australian states and territories have their own anti-discrimination and accessibility laws, some of which go further than federal law. This page is a summary for engineering teams, not legal advice; confirm the obligations that apply to a particular company with its legal advisers.