Software Design Accessibility Audits 101: What You Need to Know

October 19, 2022
consultation working meeting close up of laptops and hands drawing on paper

Accessibility in software design is an important topic that often gets overlooked or deprioritized. The good news is, addressing accessibility does not need to be a giant undertaking. In this post, I’ll give an overview of accessibility laws and how you can conduct your own software accessibility audit. This won’t make you an expert on software accessibility, but it should be enough to get you started. Check out this post by my fellow designer to learn more about why software accessibility is so important!

Even a small audit can greatly improve your product for all users, regardless of ability. Some business-related benefits of good accessibility include increased search engine rankings, branding, and return on investment [3]. If nothing else, improving your software’s accessibility helps avoid complaints, lawsuits, and potentially hefty fines.

Audits can be done in-house as a regular part of software design and development. It is easy to implement if you do it as you build your software instead of doing a big audit after everything is done.

Accessibility Laws and Standards to Know

These are the main laws and standards relating to accessibility:

  • The Americans with Disabilities Act (ADA)
  • Section 504 of the Rehabilitation Act, Section 508 of the Rehabilitation Act
  • The Web Content Accessibility Guidelines (WCAG)

Some of them do not address software directly, but they are good to know for context.

Americans with Disabilities Act (ADA)

The ADA is a civil rights law created in 1990 that prohibits discrimination against people with disabilities and ensures everyone receives equal rights and opportunities. This law was originally aimed at accommodations in physical, public spaces. However, more recently judges are ruling that websites and apps are “places of public accommodations,” and are including them in the law [4].

Violations are any one issue that breaks one of the rules. A common example in a physical space is the lack of a wheelchair ramp in a public place. For software, a violation is anything that prevents access to content. This could be poor contrast for users with low vision or lack of screen-reader support. Fines for non-compliance start at $55,000-$75,000 for the first violation and increase to $110,000 for each later violation [2]. Additionally, users can sue, request compensation, and file complaints.  If the organization is receiving federal funding, that funding can also be revoked.

Rehabilitation Act: Sections 504 and 508

Sections 504 and 508 are federal laws in the Rehabilitation Act of 1973. Section 504 ensures everyone has an equal opportunity to take part in federal services and programs, while Section 508 focuses on making federal information and communication technology accessible. Users can file formal complaints and civil lawsuits if an organization is non-compliant with these laws.

Web Content Accessibility Guidelines (WCAG)

The WCAG is a set of standards created by an independent group called the World Wide Web Consortium (W3C). These are guidelines, not laws, that help people make content accessible and compliant with the ADA, Section 504, and Section 508. This is what someone will use to judge your software during an accessibility audit.

Within the WCAG there are different levels of compliance.

  • Level A: some users can access the content
  • Level AA: most users can access the content
  • Level AAA: all users can access the content.

Most companies will aim to meet Level AA compliance. Level AAA is the gold standard and is not as common. The best accessibility strategy is to meet Level AA compliance to prevent conflicts with the ADA and Sections 504 and 508 but to also meet Level AAA compliance where it is possible and appropriate [3]. This will give your software good accessibility, but it won’t push you to design and develop things that are impractical for your product.

Additionally, the WCAG has four categories of standards.

  • Perceivable: is the content visible to the user’s senses?
  • Operable: can the user operate the content?
  • Understandable: can the user understand the information and controls?
  • Robust: as technology changes, is the content still accessible?

As a note, the WCAG was originally written with websites in mind. If the software you are making is not a website, there may be some standards that don’t apply. In that case, just do your best to meet the standards that do apply to what you are making. Currently, there are no defined standards for mobile platforms, but the WCAG has a working draft of suggestions for mobile.

Conducting a Software Accessibility Audit

An accessibility audit consists of reviewing your software and finding areas that do not meet the standards. Once you know which standards you did not meet, you know exactly what you need to fix. This can be a very tedious process, but it has very valuable outcomes.

Recently, I created a resource to make this process a little less painful. The Accessibility Audit Helper is an interactive spreadsheet to track data as you audit. This is a tool you use as you go and a way to share data with stakeholders. I also have a guide on how to use the helper and other tools I found helpful. I hope this helps and best of luck with your audit!

Get Started

Download these files to get started with your own accessibility audit.

More Software Accessibility Resources

Helpful Plugins and Tools

Further Reading

  1. ADA Compliance and how it affects your software
  2. ADA vs 508 Compliance vs WCAG
  3. Five Proven Benefits of Digital Accessibility
  4. Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile
  5. WCAG Conformance Levels: How High Should You Aim?
  6. The History of Digital Accessibility and Why It Matters
  7. WCAG 2 Overview
  8. What are the Four Major Categories of Accessibility?
  9. What is Section 504 and how does it relate to Section 508?
  10. What is the Americans with Disabilities Act (ADA)?