Skip to main content

Explore Digital Accessibility: Business Value and Technical Basics

Learning Objectives

After completing this unit, you’ll be able to:

  • Define digital accessibility and its impact on user experience.
  • Explain the business value of building accessible digital products.
  • Identify the technical basics of accessible design.
Note

This module was produced in collaboration with the Blind Institute of Technology. Learn more about partner content on Trailhead.

Removing Barriers with Accessible Design

Have you ever used a poorly designed web page? Maybe the text was too small, the page was cluttered with irrelevant information, or it was difficult to figure out what you needed to do or select next. These are a few examples of how poor design can block users from doing their jobs. Digital accessibility is about removing those barriers and ensuring that everyone, including people with disabilities, can perceive, understand, navigate, and interact with the digital world. The goal is to create an equivalent experience for all users.

In this unit, you explore what digital accessibility really means and why it’s a critical component of your Salesforce strategy. You learn how accessible design drives business value, improves the user experience for everyone, and fuels innovation. You also explore some technical basics to help you get started on the path to building more inclusive solutions on the Salesforce Platform.

Before diving in, let’s take a moment to set the accessible stage. Equality is a core value at Salesforce. Disability inclusion and accessibility are fundamental to our belief that businesses can be powerful platforms for social change. Salesforce engineers and designers strive to create products and features that truly work for everyone.

This module was written in partnership with our friends from the Blind Institute of Technology (BIT), a global nonprofit staffing and recruiting firm dedicated exclusively to professionals with disabilities. As BIT founder and golden hoodie winner, Mike Hess, explains:

“Accessibility isn’t difficult, it's intentional. Salesforce is the most accessible business enterprise application on the planet because they've made accessible design a core priority, not an afterthought. That intentional commitment to inclusion is a huge part of why BIT decided to focus our apprenticeship program specifically on Salesforce skills.” —Mike Hess

While Salesforce provides the foundation of accessibility, the power of the platform lies in its flexibility. If you don’t consider accessibility when you customize your org, you can create accessibility barriers. In this badge, you learn how to identify common pitfalls so you can customize with confidence, ensuring that your digital environment remains welcoming to all users.

But first, join Rebecca from BIT as she demonstrates an accessible account page in Salesforce.

The Business Case for Accessibility

Building accessible products isn't just the right thing to do, it’s a smart business decision. In the United States alone, it’s estimated that over 70 million adults have a disability. That’s more than a quarter of the total population. In other words, you could be excluding a substantial group of potential customers and employees if your digital accessibility is poor.

More importantly, accessible design often improves the experience for all users, not just those with disabilities. This is known as the curb-cut effect, where features originally designed for people with disabilities (like sidewalk ramps) end up benefitting a much wider audience (like parents with strollers and travelers with luggage). In the digital world, features like voice control, dark mode, and captions have similar universal appeal.

If you want to learn more about digital accessibility, check out the Get Started with Web Accessibility trail.

The Technical Basics of Accessible Design

To build accessible solutions, it helps to understand how the technology works. Digital accessibility refers to how code is translated into something assistive technology can read and navigate. Assistive technology refers to products, equipment, and systems that enhance learning, working, and daily living for people with disabilities. This includes but is not limited to screen readers, magnifiers, text-to-speech or speech-to-text technologies, alternative keyboards, and closed captioning.

The DOM and the Accessibility Tree

At the core of every web page is the Document Object Model (DOM), which represents the page’s structure and content. Working alongside it is the accessibility tree, a specialized version of the DOM that filters out visual noise and presents the content’s roles, states, and properties to assistive technology like screen readers. If your design doesn’t translate well to the accessibility tree, it can be invisible or confusing to many users.

Here are some of the key technical concepts you need to support that translation, according to the latest Web Content Accessibility Guidelines (WCAG 2.2).

Concept

Description

Related WCAG 2.2 Guideline(s)

Keyboard Compatibility

All functionality must be achievable using only a keyboard. This means a user can reach every interactive element using the Tab and Arrow keys and activate it with the Enter or Spacebar key. Crucially, the keyboard focus should never get trapped in an element, forcing a user to refresh the page to escape.

WCAG 2.2: Keyboard Accessible

Visual Focus Indicators

When a user tabs to a link, button, or form field, there must be a clear visual indicator (like a border or outline) that shows them where they are. This indicator should have sufficient color contrast and never disappear while the element is in focus.

WCAG 2.2: Focus Visible

WCAG 2.2: Focus Appearance

Meaningful Semantics and Structure

Screen readers rely on code semantics or tags, so it’s important to use the right tag for each job.

  • Headings: Use heading levels 1 through 6 to create a logical, nested outline. Never skip levels (like jumping from 2 to 4) just for visual styling.
  • Element roles: Roles, such as button and link, communicate identity, behavior, state, and relationship information to screen readers. This helps users quickly understand what the element is and what happens when they interact with it.

WCAG 2.2: Headings and Labels

Color Contrast

Color is a great design tool, but it shouldn’t be a barrier. Text needs to stand out against its background to be readable.

  • Small text (below 18pt) requires a contrast ratio of 4.5:1.
  • Large text (18pt+ or 14pt bold) and graphical objects (like icons and input borders) require a ratio of 3:1.

Use a tool like the WebAIM Contrast Checker to make sure your designs meet color contrast requirements.

WCAG 2.2: Contrast (Minimum)

Alternative Text

Images that contain information must have alternative text (alt text). This text is picked up by the accessibility tree and read aloud by screen readers. Alt text should be considered a replacement for the image, rather than a description of the image. It should convey equivalent meaning and focus on the purpose of the image.

If an image is purely decorative, it’s often better to exclude it from the accessibility tree altogether to reduce auditory clutter for screen reader users. This can be accomplished with an empty alt tag.

WCAG 2.2: Text Alternatives

Inspect the Accessibility Tree for a Salesforce Page

You don’t need specialized software to understand how a page communicates with a screen reader or keyboard. Modern browsers include developer tools that let you inspect page elements. In this example you use Google Chrome, but other browsers, such as Firefox, Safari, and Edge, have similar features.

  1. Use this page on Trailhead or open a Salesforce org in your Chrome browser.
  2. Right-click any element on the page (a button, link, or image) and select Inspect.
  3. In the developer panel that opens, find the Elements tab and select the “”Switch to Accessibility Tree view button.
  4. Alternatively, enter Ctrl+Shift+C on Windows or Cmd+Shift+C on Mac to toggle Inspect Element Mode, which highlights elements as you navigate around the page or the accessibility tree. Check out more Chrome DevTools Keyboard shortcuts.

The Name field shows you the text that a screen reader announces, such as the title or label of a button. The Role indicates how the element functions, identifying it as a button, tab, or heading, for example. Check out the video demo to learn how to inspect the Mark Stage as Complete button on an opportunity record using Chrome DevTools.

Now that you have a good idea of the business value of accessibility as well as the technical foundation, let’s get into a Salesforce org and fix some common accessibility mistakes.

Resources

Partagez vos commentaires sur Trailhead dans l'aide Salesforce.

Nous aimerions connaître votre expérience avec Trailhead. Vous pouvez désormais accéder au nouveau formulaire de commentaires à tout moment depuis le site d'aide Salesforce.

En savoir plus Continuer à partager vos commentaires