One of the most important steps a team can take to building more accessible products is to champion an internal company culture that makes accessibility a priority. This includes educating leadership on the value of building accessibility into the foundation of your products, and creating employee affinity groups to discuss issues on a regular basis. This is especially important to guard against misleading vendors that offer widget or overlay solutions as a magic bullet to fixing accessibility issues.
Run regular (at least monthly) meetings to talk about accessibility issues within your products and website. Push for a level of common knowledge within your teams that educates everyone on how assistive technologies help users. Host info sessions to demonstrate how a person would interact with any website, but especially your company's websites or products, using a screen reader like JAWS, NVDA, Mac VoiceOver, etc. Show common settings people would use within a screen reader like navigate by headings or navigate by links. Explain why it’s important to insert alternative text for images, differentiate between buttons and links, and set up proper information hierarchy with H1 to H6 elements.
Consistency in how engineers write code will also lead to more accessible products. The engineering team should establish coding standards and conventions to abide by. Create a wiki section of your code base to document these standards. If you’re creating these standards for the first time, start with a list of common practices — spaces vs tabs, single or double quotes, snake case vs camel case, etc. — and organize a meeting or async discussion to agree on how everyone on the team will code going forward. During code reviews, reference the team’s standards and conventions to enforce consistency.
Front-end developers contributing to the design system should be proficient in writing semantic HTML. Neglecting this practice has resulted in 97% of the web having accessibility issues. When building components for the first time, start by using W3Cs website to review accessibility standards or search for examples of the component you're trying to build. Developers should be aware that JavaScript libraries, like React for example, might not contain the most accessible construct for a component. Continuing education is also key so attending conferences like Deque’s axe-con is a great place to learn.
Product designers should utilize accessibility plugins within their design tools to check their files. At a minimum, UX teams should make sure there is sufficient contrast between text and backgrounds, provide alternative text for images, and maintain information hierarchy by using H1, H2, H3, etc. elements consistently. For interactive elements, designers should make sure they’re working in lockstep with developers to design and communicate sufficient information for all possible states.
Make sure your design system documentation tool can accommodate notes for all elements, components, etc. so that you can reiterate basic accessibility standards. An example note on your typography might say “Try not to use a font size smaller than 16 pixels as your body text.” You might also need to explain exceptions like within a footer. Also, write notes for developers to remind them when to use buttons versus links or to include alternative text for images.