Incorporating Accessibility Into Web Applications

On May 20th, we're celebrating Global Accessibility Awareness Day (GAAD). This significant day is here to remind us all that even though the journey toward accessibility can take years, we’re still committed to making our websites and apps accessible to all people and to continue advocating for accessibility in every aspect of our lives. The Design Systems & Accessibility team at MURAL has been working on incorporating accessibility (also known as a11y) into our product. Along this journey to make MURAL’s product accessible, we’ve learned quite a few tips and tricks. Today, we're sharing what we've learned with you about incorporating accessibility into designs and products.

What is accessibility?

Accessibility is the practice of ensuring that any person, particularly people with disabilities, can use a website or web application. When someone considers accessibility, they might think only about a set of disabilities that they are familiar with, but the people who are impacted have a broad range of disabilities, which can be permanent, temporary, or even situational. For instance, if a person is holding a baby in one arm, how easily can they write an email? If a person is blind, how easily can they navigate your website?

Now that we’ve defined accessibility, you might be wondering, why is accessibility important? How do I convince others that it’s important? Who on my team should be working on accessibility? Some key points the Design Systems & Accessibility team kept top of mind while thinking about these questions include:

• “Opt-in” by default: Accessibility needs to be the default standard, not something that would be nice to have. Everyone uses the web differently. Making products accessible ensures that more users can access your product. In other words, enabling more people to use your product, grants you access to a bigger market place. Working on implementing accessibility from the start also costs exponentially less than retrofitting a production-facing application/site, or worse yet, a lawsuit.
• Teamwork, Dreamwork: Creating an accessible app is a huge project, and having only one person responsible for accessibility can create bottlenecks and burnout. By collectively assuming accessibility goals, everyone can focus on how their own roles contribute to accessibility. For instance, UX designers specifically are focused on developing the usability and interactions of an application/site. They also do things like user research, testing, feedback etc. These skill sets are not ones that developers typically have, so bringing designers into the discussion early on can make accessibility-focused development less overwhelming and difficult to achieve. Ultimately, to incorporate accessibility practices into the development lifecycle long term, the entire organization needs to actively prioritize accessibility, from development and design all the way to QA, management, and customer support. This is why the Design Systems & Accessibility team codified a universal pledge to encourage commitment to accessibility and inclusion. As of today, every MURAL employee has been asked to sign this pledge.
• Shift Left: Think about accessibility at the start of the product development process, not after. Implementing accessibility into an existing app can be especially challenging for organizations that have been around for a long time. It’s easier to incorporate accessible elements while developing a product than to create a potentially inaccessible product and try to fix it afterward. So whenever possible, start early.

How to get started

In case you’re wondering how to begin, here are some ways to start incorporating accessibility into your app:

• Use a plugin or a linter to scan your code for accessibility issues. For example, for React applications, you can use eslint-plugin-jsx-a11y to catch approximately 30% of issues that make an app inaccessible, like missing alt text on images. What a quick win! However, it’s important to also run a full accessibility audit including manual processes, to help identify usability issues. See the bottom of this section for details.
• Run an automated testing audit using an accessibility browser extension. Free extensions like aXe and Wave can scan your app for accessibility issues that the linter may have missed, like low contrast color schemes. While this can be a great way to check for automatically detectible issues, it’s no replacement for usability testing, so be sure to still do a full manual audit.
• Familiarize yourself with the Web Content Accessibility Guidelines (WCAG). WCAG is the go-to standard reference for implementing accessibility features and is maintained by the W3C, and is guided by four principles to ensure a broad range of accessibility: Perceivability, Operability, Understandability, and Robustness. Although they can also be overwhelming due to their thoroughness, they are the official resource on accessibility.

• Create a checklist based on your product’s existing or planned features and make strategies to adapt those features to be more accessible. Here’s a sample checklist from the Design Systems & Accessibility team that you can take inspiration from:

  • Ensure that users can fully navigate your app with a keyboard.
  • Test your software using common assistive technologies, such as a screen reader.
  • Ensure users can zoom in to 200% (the zoom percentage that the WCAG recommends) and that all content is still easily readable.
  • Check that images and text meet color contrast levels of 4.5:1 to help ensure they’re still readable. Here is a color contrast checker you can use to test your designs.
  • Make sure that language is clear and understandable. Check out the Plain Language Guidelines.
  • Ensure you have no images that flash more than three times per second, because quick-moving graphics could be an issue for users with epilepsy or attention deficit disorder.
  • Write alt text for functional images. These are descriptions of non-decorative graphics that a screen reader can read aloud to users with visual impairments.
  • Add captions for videos and audio.
  • Ensure that videos and sounds do not play automatically. Autoplay can cause a number of issues for users, and even prevent them from being able to navigate your site.

  If you want to learn more about accessibility and the above recommendations, check out the Web Content Accessibility Quick Reference Guide that summarizes the Web Content Accessibility Guidelines. The guidelines contain extensive lists of standards to enable a variety of users to access web products more easily. For more digestible checklists and write ups on the topic, check out IBM’s breakdown of the WCAG checklist by role and this article on making images and other media incorporated into a website or app accessible.

• Do a full manual audit of your product to ensure it is usable in real life situations. This is the biggest and most important step, because automated programs can’t test apps for the ways users will navigate them. Teach yourself how to navigate your website or application using only your keyboard, and then only a screen reader, and then show the rest of the team how it’s done. Bake in time for local testing using these approaches on even small product changes. If possible, include testing and feedback from users with disabilities, or hire an accessibility expert to augment your routine manual audits For more info, check out this Smashing Magazine article on the importance of manual testing.

Now that we’ve defined accessibility and reviewed key guidelines, we hope you’ve got a lot more ideas on how to make apps accessible to everyone and, as a result, how to create a more inclusive world.