When we set out on making our app accessible, I had a hard time finding out how other companies tackled this. We started at the very beginning of this process and really had no idea where to go. I hope this guide helps you out - no matter what stage of the accessibility journey you are on.

1. Give a lunch and learn on accessibility and start generating empathy.

You can check out the slides from the lunch and learn I gave here:
https://github.com/erin-bush/a11y-cat
. Before I had given this lunch and learn, accessibility really wasn’t on anybody’s mind.

2. Don’t stop talking about accessibility

Make sure everyone at the company knows what accessibility is and why its important

3. Create a mega list of customers asking for compliance with standards.

We found that once we started tagging customer tickets, we had a surprising number of people having issues with our platform and struggling to make their content accessible.

4. If you have a huge app, drill down the most critical user paths that need help first.

For our application, we provide course creators with the tools to make their own online courses. We found that our customers’ students were the ones affected the most by our lack of web accessibility and the student signup to course completion ended up being our critical paths.

5. Put in time outside of work to compile a list of all the known issues.

I recommend using the chrome plugin aXe on every page on your site to generate a list of accessibility issues. Alternatively, you can use the built in chrome lighthouse audits

If you can get buy in from your company to do this, great! We found that as no one knew where to start, and we didn’t yet have buy in from management, we had to take it upon ourselves to make a list of ways we can improve

Note: There will still will be other things that need to be fixed that can’t be automatically tested - this is where manual QA testing process comes in later (see #9)

6. Continue to talk about it.

We found a good way was to keep bringing accessibility to the front of mind of the product team by giving devs a 5 minute fix that they can implement easily as they do their work and highlight a different fix every month.

7. Run an Accessibility Jam after work to fix all of the easy stuff as a group (offer lots of tequila)

We had a ton of things that needed to be solved after we had run the aXe plugin on our user’s critical paths. As we weren’t getting assigned dev time to work on this, we decided to organize our own Accessibility Jam were we wrangled a bunch of developers, designers, and qa people to come to work on the massive list together (with tacos provided 🙂). Both pull requests and alcohol were flowing.

Remember to publish the stats from the jam to keep people motivated!

8. Get the customer support team on board to gather more information from customers who write in about accessibility issues.

We found that videos were the most informative, but even just in depth descriptions of the problem and some information about the screen reader type and browser version they are using.

9. Get accessibility processes integrated into the company’s OKRs.

Our company operates around OKRs, and the next step after getting buy in from management was to find a way to integrate accessibility into our quarterly plans. We tried to attack it from both the process side (checklists for developers, QA and designers) and from the implementation side but found that it would have been better to start with process in one quarter and then work on implementing in the next quarter.

10. Create a list of things devs, designers, and QAs need to accomplish to meet standards (ie. fix the pipeline first, then go back and fix the other stuff)

Once the OKRs were fleshed out we had to actually come up with our processes that enable our upcoming features to be accessible. I recommend taking a look at the vox checklist as they break it down by role.

11. Create a company philosophy on accessibility

We have yet to do this but I believe it is integral to have accessibility written into the policy so that when we are questioning if we have time to work on something or not, we can refer back to the policy as law

12. Automate some accessibility checks.

We have yet to this step but there are a few tools that can help you automate your accessibility compliance checks:
1. Git plugin for your pull requests: lighthouse bot or accesslint
2. Precommit hook for sass: set up a precommit hook that runs stylelint-a11y or add as a plugin to your code editor
3. eslint jsx a11y plugin
4. Integrate dev checklist into github PR checklists: set up a PR template that includes the checklist items from the list you made in step 10

13. Add in an accessibility feedback link to get first hand information on issues.

At the bottom of the page, include an accessible link that allows people to give feedback directly, possibly in the form of a type form.

14. Fix fix fix!

Keep pushing to have old accessibility issues integrated into feature work that touches currently inaccessible parts of the code.

15. Get an audit (could also be done earlier) to get access to people who use screenreader and assistive technology all 👏 the 👏 time 👏 to find issues you can’t automate

There are a few companies that do this but one that we like is Fable

16. Run a show and tell to update the rest of the company of your phenomenal efforts 🙌

Tons more resources available here: https://a11yproject.com/resources