Embedding Accessibility in Salesforce Development And Why It’s So Important

Accessibility, whether for building, services, apps, websites and digital products is paramount to a satisfying customer experience. In 2021, the US registered more than 3800 lawsuits relating to the accessibility of websites, apps etc. highlighting the importance of accessibility. But looking past a purely legal argument, accessibility matters for a bigger reason: we don’t want to leave users behind.

Today we’ll look at why accessibility matters and share some guidance on how to create accessible sites, experiences, and components on the Salesforce platform using custom Lightning Web Components (LWC).

Why accessibility in Salesforce Development matters

When one hears the word ‘accessibility,’ it is natural to connect it with another word: disability. This is a fairly understandable connection – take, for instance, the definition provided on the accessibility introductory page of the Worldwide Web Consortium (W3C):

“Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.”

This definition is understandable and accurate, but we prefer the Interaction Design Foundation’s definition of accessibility:

“The concept of whether a product or service can be used by everyone — however they encounter it.”

Accessible design, while targeted at users with disabilities, encompasses ease of use for all users, regardless of how they might interact with a website. The more broadly accessible we make our websites, the more people can use and benefit from them. That’s fundamentally a good thing, and something we should strive for with the experiences we create.

Accessibility in Salesforce Development

Accessibility is easy to imagine as a feature that we tack on later. But it is more helpful to envision accessibility as a sort of mindset that we can shift into from the earliest stages of development. As we discover, design, and architect, incorporating accessibility principles early will make the development process more seamless and manageable.

HTML: The foundation of accessibility

Creating accessible websites and components all starts with the markup on the page. And thankfully, modern HTML provides many built-in accessibility features. The key to utilizing them is to use semantic HTML. Essentially, this means using the right HTML element or tag for the job. For instance, if we have tabular data we want to display on the page, then we ought to use a <table> element in our HTML to represent it. Or, if you want the user to click a button, use a <button> and not a <div> or a <span>.

Additionally, Salesforce’s own component library of LWC does a great job of meeting accessibility requirements, especially if you follow any instructions in the documentation to provide correct labels and attributes.

Sometimes we can’t rely on standard HTML features or Salesforce components. When we need to build something more custom, we can take advantage of Accessible Rich Internet Applications (ARIA). ARIA is essentially a set of roles and attributes that we can apply to our generic HTML elements like divs and spans and provide them semantic meaning. 

Styling and CSS

Writing proper markup is important for accessibility, but so is the visual design of the experiences we create. A common accessibility issue across the web is contrast, or a lack of it. Thankfully, contrast problems are fairly easy to solve with the help of a tool like WebAIM’s contrast checker.

The harder problem is ensuring that the design and intent of the content on the webpage is logical and clear for all users. Default browser styles do a good job about making the intent of standard elements clear. For example, an anchor tag uses a blue color and an underline to make itself visually distinct from standard paragraph text, while headings are typically bolder and larger.

We don’t need to adhere to the standard browser styles as we make our own designs and components, but it is important to keep the intent of our custom components clear in the same fashion. Does this element look and behave as expected? Is information laid out in a logical manner? From a visual standpoint, it should be clear what all the front-end elements do without the user needing to interact with them.

You also want to ensure you communicate visual changes in the state of what you are building. This is especially important in forms and interactive elements.

Checking your accessibility work

Ensuring that we’ve built accessible sites can feel overwhelming, but here are some quick tips to help make it more manageable:

• Use your dev tools to perform an automatic accessibility check: both Chrome and Firefox have handy accessibility tools that can check for common problems (like contrast, missing ARIA attributes, and more) across your website
• Conduct an “accessibility audit” of your work: Try to navigate your site using a keyboard only. Or take it a step further and ensure that it is navigable via screen reader.
• Add accessibility testing with sa11y: sa11y is a set of JavaScript libraries that help developers write automated accessibility tests on the Salesforce platform. Sa11y can help check for common accessibility issues as well as any future changes that may impact accessibility.
• Reference the Web Content Accessibility Guidelines: These guidelines are the go-to textbook for making content more accessible. They describe interactions, scenarios, design principles, and more.

There are an overwhelming number of accessibility guidelines and requirements for developers to keep track of. Remember to give yourself a break and that it’s okay not to meet every single requirement all of the time. Just keep shifting into an accessibility mindset and doing what you can to build accessible experiences with best practices. This approach of embedding accessibility in Salesforce development will go a long way toward making your products and services more usable by everyone.