Skip to main content

A Practical Guide for Developing Accessible Products

Sakhi Aggrawal
Oct 27 - 5 min read

Sakhi Aggrawal is a Software Engineer & Accessibility Advocate at Salesforce. She recently gave a talk titled “All Aboard: Practical Guide for Developing Accessible Products” at the Lesbians Who Tech Pride Summit. This useful playbook is a summary of the points from her talk.


First things first, let’s define what we mean by “accessible products.” Accessible products are ones that can be used successfully by people with a wide range of abilities and disabilities. This includes being able to perceive, understand, navigate, interact with, and contribute to the product in equitable ways. Accessible products uphold our core value of Equality, and we have dedicated teams that work on accessibility full-time, including the Product Accessibility team and the recently-formed Office of Accessibility. Our Office of Ethical & Humane Use, which works to “create technology that not only drives the success of our customers but also uphold the basic human rights of every individual,” is also part of these efforts.

Accessibility is important because it ensures equal access and opportunity to all. According to the World Health Organization (WHO), 15% of the world’s population experiences some type of disability, and many more of us will experience temporary disabilities (imagine having your dominant arm in a cast, for example), so designing without accessibility in mind leaves out at least a full 20% of people! By creating products and services that are inclusive of all of society, you widen access to the tools your business provides and provide equal access to job opportunities in industries that rely on your products. And, behind the scenes, following accessibility standards actually improves overall coding practices.

The Guide

So now that we’re all on the same page about what accessible products are and why they’re important, let’s talk about the elements of design that drive accessibility.

Color Contrast

Color contrast is how legible colors are when placed next to or on top of each other. Designers need to ensure proper contrast for all text, icons, buttons, checkboxes, radio buttons, and text that overlaps images.

Comparing screen output of text over colored background – before and after including accessibility considerations in the code.

Images, Logos, and Icons

Images are a very common part of most websites and applications. All <img> elements should have a corresponding ‘alt’ attribute coded into their HTML. This attribute can be read by screen readers and speech-enabled websites, allowing users with impaired vision to interact with your site or app. The alt text also appears on the screen if the image link is broken or if someone is accessing your product with insufficient bandwidth to load the image. For images containing text, the alt attribute should contain the image’s text.

Comparing screen output in case of broken image link – before and after including accessibility considerations in the code.


Forms allow people to enter information into a site for processing. All inputs in a form are associated with a corresponding <label> in the HTML. Inputs use an ‘autocomplete’ where appropriate. As the designer, you shouldn’t validate fields before the input is complete. Related fields should be grouped using the <fieldset> and <legend> attributes. Error, warning, and success states should not be visually communicated by color alone; add text, and icon, or, better yet, both to communicate state to the user.


Lists let people know that content is related, and, in the case of an ordered list, how many items are included in the grouping. To allow a screen reader to convey this information, make sure to use list elements (<ol>, <ul>, or <dl>) rather than paragraph tags to differentiate the contents.


Tables help people understand the relationships among different types of information. There’s a helpful <table> element in HTML, and you should use the <th> element to label table headers rather than simple header tags and paragraph breaks for the separate lines. Use <caption> to provide a title for the table itself.


Media includes content such as pre-recorded or live audio and video. Media should NOT autoplay on load, and it needs to be able to be paused. For audio and videos, confirm that transcripts or captioning are available. Another thing to check is that you have removed seizure triggers. (Seizure triggers can include certain kinds of strobing or flashing animations, especially flashing at high frequency or red flashing, as well as sudden, loud sounds.)


Animation is content that moves, either on its own or when triggered by a person activating a control. If you are using animation, ensure that it is subtle, not overly flashy, and can be paused. Given that, a good general rule is to avoid GIFs, since they usually play automatically and replay often cannot be paused.

Test Your Product!

If you consider accessibility in these seven areas, you’re well on your way to designing an accessible product! But how can you be sure? That’s where testing comes in.

The Google Chrome browser offers a few helpful extensions that you can try on your site or web app:

You can also do manual testing using screen readers:

Want to Know More?

This is a very basic starter kit, and there is plenty more to learn about web accessibility. It’s our responsibility to design and code with accessibility in mind! Here are some additional resources to take you to the next level:

At Salesforce, we have an employee resource group (ERG) called Abilityforce that unites people with visible and invisible disabilities, employees with loved ones who are disabled, and allies. We work to make sure our physical and technological environments are accessible and designed for all by developing and implementing innovative practices that solve customer and employee needs. Get hands-on with these product accessibility tips and more on our “Get Started with Web Accessibility” training module on Trailhead.

Related Accessibility Articles

View all