Accessibility Auditing Shortlist

This list was initially created in the #IT subgroup slack channel. Find more auditing ideas from the big Accessibility Auditing Resources Page.

Introduction

The shortlist is designed to create a simplified guide for beginners to be able to contribute to assessing software and web technologies for accessibility. The goal is to crowdsource accessibility information about a variety of GLAM technologies that can be shared widely and freely through the DLF Wiki. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.

What do we mean by accessibility?

In general, when we say Accessible, we mean that something can be used by everyone, whether they use assistive technologies (such as screen readers or a stylus) or have any disabilities. A software program that only responds to vocal commands is not accessible to someone who doesn’t speak, or if they don’t have a microphone on their computer, or even if they’re in a very noisy place.

As information professionals, our duty is to ensure that people have access to information. If we hide that information behind inaccessible software or poorly-designed websites, we have failed in our mission.

Checklist

Accessibility auditing is both a science and an artform. While it is best to engage with an expert, not all information organizations have access to trained auditors. Please consult the full Accessibility Auditing Resources list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.

First Steps

These tasks can be completed by anyone, even if you have no experience in web design or accessibility auditing. Web Accessibility is easier to test for a layperson than software accessibility, but you can still do some tasks.

1. Does the vendor or website have a page dedicated to accessibility, or a central contact address for accessibility questions and assistance? If so, record the information.
   1. Rationale: It’s a positive sign when a website or vendor recognizes and addresses the accessibility of their product. If there is difficulty finding support for questions or concerns around accessibility, it can be a sign that the vendor hasn’t incorporated accessibility into the design, or that they don’t value input around accessibility issues.
2. Run the WAVE Automatic Accessibility tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)
   1. Report these errors (found in the Details tab):
      1. Color Contrast (low or very low contrast?)
      2. Missing Alternative Text
      3. Missing Link Text
      4. Broken ARIA
      5. Heading Structure
      6. Anything else listed under the Error tab.
   2. Rationale: To learn more about what the errors mean and why they are an issue, click on the “i” symbol/”More Information” link. This is a great way to learn some basics about web accessibility.
3. Install and use the HeadingsMap extension (for Chrome and Firefox) to check the headings on the page.
   1. Rationale: Using properly ordered HTML (h1, h2, etc.) code to mark up the page allows a screen reader user to quickly navigate between headings. Headings serve as a sort of outline structure for a webpage, and HeadingsMap will reveal what that outline looks like.

• Back to main Digital Accessibility Group page.