At a startup, accessibility can feel daunting because resources are limited, but new technology and smaller scope can be a unique benefit. Making the investment earlier on will save a lot of time and money in the long run.
Although this article is based on my experience as the only UX person working on an earlier stage product with a small team, many of the steps and resources can be used by larger organizations with more mature products.
Accessibility is the practice of making your websites usable by as many people as possible.
Why does accessibility matter?
- It’s good for business. The more users that can use the software, the bigger the market. Additionally, if your company is going after any government contracts or putting a consumer facing app into an app store, accessibility will likely be a requirement.
- It’s good for users. Globally, 2.2 billion people are blind, have low vision, or colorblindness, and 466 million people are deaf or have hearing loss. 40% of websites are completely inaccessible to users who are blind. Accessible products avoid alienating these groups and provide a better user experience for everyone.
Stakeholders will probably ask why it’s important to make the investment. Making the case for accessibility to get team buy-in is critical to success.
Design with accessibility in mind
Starting with accessible designs sets the tone for the rest of the product.
- Pick colors with high contrast ratios. For users with low vision and colorblindness, high color contrast ratios can make content clearer. Read more about color contrast accessibility.
- Use readable, scalable fonts. Users should be able to increase the font size by zooming in and out to more easily read the text. Generally, the body text should be at least 16px.
- Don’t depend on visuals or audio alone to convey a message. Provide alternate messaging for blind, low vision, deaf, or hard of hearing users. For example, if a design uses color coding to categorize, consider pairing it with text, a pattern, an icon, etc.
Check your work with tools like Stark
Designers aren’t required to know if a font color has a high enough contrast ratio. Plugins like Stark can be used while designing to check contrast ratio and font size, as well as simulate colorblindness.
Use an existing design system
If you’re at a startup, it’s unlikely you’ll have the resources to build your own design system, let alone one that’s accessible. Leveraging an established design system, like Angular Material or React, helps ensure that every time a component is used, it passes accessibility compliance.
Auditing can be so overwhelming that there are companies that audit products for companies. At a startup, that luxury is unlikely, but luckily there are resources to streamline the process.
Start with an understandable checklist
Web Content Accessibility Guidelines (WCAG), created by World Wide Web Consortium (W3C), is a global standard for web accessibility.
“Web Content Accessibility Guidelines 2.0 explain how to make web content accessible to people with disabilities. Conformance to these guidelines will help make the Web more accessible to users with disabilities and will benefit all users.”
Reading through the WCAG requirements can be tedious. WebAIM, an accessibility non-profit, put together a checklist with recommendations on how to adhere to each guideline.
Use the WebAIM Checklist.
Go page by page with the WAVE Evaluation Tool
WebAIM also created a chrome extension that can be turned on for any page. It lists potential accessibility issues and gives suggestions on how to fix them.
Install the WAVE Evaluation Tool Chrome extension.
Fill out an audit
Use the WebAIM checklist and WAVE Evaluation tool to fill out an audit. The Voluntary Product Accessibility Template (VPAT) is the most common audit form in the US. The audit provides the status of compliance for the product and helps the team understand how much work is needed.
Here’s a blank VPAT template I started with.
The final step is the most collaborative. It requires clear communication to make sure everyone’s on the same page.
Review the audit with the team to size the work
Discuss the findings to begin sizing how much work will be necessary. Use the checklist’s recommendations to meet unmet guidelines. This will help the team agree on how and when the work should be done.
Write requirements to chip away at remaining work
Make an epic to “Create an accessible product” to have a bucket for all accessibility work. Take the page-by-page audit and write requirements for each issue. When the work is defined, the goal looks a lot more achievable.
Code with accessibility in mind
Make a plan to maintain an accessible product. Developers need to code with accessibility in mind, just like designers design with accessibility in mind. Use a checklist, just like any other QA checklist, to assure each new feature passes accessibility standards.
Here’s the developer accessibility checklist I put together for my team.
Finally, don’t be afraid to re-open stories
Like any other functional requirement, accessibility should be treated as an expectation for each new feature. Enforce that expectation.
Although accessibility is a subsection of inclusive design, I find it’s a great place to start a larger discussion. The standardization and examples around accessibility help teams understand why inclusive design matters.
Priorities change and accessibility is often pushed to the end of the backlog, but tirelessly advocating for accessibility and inclusive design creates the best user experiences for all users.
Don’t let the way your product is built be the reason someone isn’t using it.