Accessibility Auditing Shortlist

This list was initially created in the #IT subgroup slack channel, and updated in May 2023. 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 (Galleries, Libraries, Archives & Museums) technologies that can be shared widely and freely through the DLF Digital Accessibility Working Group Wiki. It is meant to be a self-directed learning experience where anyone, anywhere, can help us to evaluate commonly used software and websites.

If you are participating in the initial review of a technology using the shortlist, you can mark what areas you are planning to test on the Accessibility Assessment Template for that technology. (Contact the Group Organizers for more information.)

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 responds only to vocal commands is not accessible to someone who doesn’t speak, to someone who doesn’t have a microphone on their computer, or to someone 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 this duty. As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the Digital Accessibility Working Group.

Considerations for non-English and Multilingual items

The language of a website or document should be properly declared, including in PDFs and epubs. This tells a screen reader what language the document is in, and that it should switch to a different voice engine. This works automatically with JAWS, but may not function correctly with NVDA or other screen readers or even certain browsers. You may need to manually switch your language engine when testing a website that is in a different language than your screen reader's default setting.

A website or document can also support multiple languages. Penn State's page on Language tags clearly outlines the use and function of using language tags to mark out different languages on a webpage. The links in the above paragraphs include sections of multiple language tags so you can test our your preferred screen reader and browser to determine if it will function correctly for testing.

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. The DLF DAWG team uses these steps and the accompanying template for our website reviews. Please consult the full Accessibility Auditing Resources list for courses, tools, specifications, and guidelines.

First Steps

These tasks can be completed by anyone regardless of past experience in web design or accessibility auditing. For someone new to testing, website accessibility is easier to test than software accessibility, but there are still basic software checks that anyone can perform.

1. Does the vendor or website have a page dedicated to accessibility or a central contact address for accessibility questions and assistance? Does the page acknowledge any inaccessible areas of the software or website? 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 about accessibility issues.
2. Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? A VPAT is a report that a vendor or third party creates to assess the accessibility of their product. Is there an evaluation available at the Library Accessibility Alliance? Use a search engine of choice to find out and record this information.
   1. Rationale: A VPAT document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility or that it was conducted by an expert. Anyone can create a VPAT, and it’s not a legal document or legally enforceable. The Big 10 Library Accessibility Alliance has done a great deal of testing on library vendors to share their professional evaluations with the world. These can tell users what accessibility issues exist with the software or website.
3. If the vendor or website has an internal search mechanism (i.e. search box to search the site), test to see if it actually works. You can compare it to a similar search in Google using site searching (add site:website.com to your search string in Google, replacing the address with the top level domain of the site you want to search).
   1. Rationale: A working internal search can save a user a lot of time and energy if it works. Optimally, you could use the internal search to find the keyboard shortcuts, vpat, or other accessibility information. If the internal search doesn't work, then it's useless to help anyone.
4. Run the WAVE Automatic Accessibility tool if it’s a webpage or browser-based program. WAVE 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. 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.
5. For webpages and electronic documents, check the heading structure of the page by installing and using the HeadingsMap extension (for Chrome and Firefox). It will display the headings in the order they appear 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 an outline structure for a webpage, and HeadingsMap will reveal what that outline looks like. Learn more about headings.
6. Test out basic keyboard-only access to the website.
   1. Use the Tab key to move the focus (an outline showing where a person is on the website or software) from one link, form element, or button to another. Press Enter or Spacebar to activate that link or button. Use shift-Tab to visit the previous link, form element, or button. Is there a visible focus element a user could track with their eyes?
      1. Rationale: This tests if users are able to access the major active elements on a page with just the keyboard. To learn more about keyboard-only access, visit Take the #NoMouse Challenge and Keyboard Accessibility Basics.
   2. Can the Tab key be used to navigate through a dropdown menu or checkboxes? What about the Arrow keys? Can a user move out of a menu and back into the main links? Does a user need to use the ESC key to get out of a dropdown menu?
      1. Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.
   3. Use Ctrl-A to “Select All” on the page. Is there anything that isn’t selected, like a menu or button, or even a whole region of the page? Is there any way to use the Tab key or Arrow keys to reach that unselected item or area?
      1. Rationale: This tests if there are hidden or inaccessible areas on the webpage. “Select All” helps to highlight whether something is actually included in the “All” in the sense of the website. For example, a feedback tab that appears on the right hand side of the screen over the scrollbar may not actually “exist” or be available for keyboard users. If it requires a mouse or a touch gesture to activate it, then report that information.
   4. Does the vendor include a list of keyboard shortcuts? Record that information.
   5. How easy is it to find the list of keyboard shortcuts? Are they listed in the menus, or appear when a screen reader is activated?
7. Does the website or software require the user to drag-and-drop to do something, without having an alternative?
   1. Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.
8. Does the website use color alone to denote meaning?
   1. Use the RGBlind color blindness simulator on the website.
   2. Does being color blind in some way affect a user’s ability to fully use the site? Is there a difference in color between a visited link and a non-visited link?
      1. Rationale: Using color alone can affect how users who are color blind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.
9. Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.
   1. Is any information cut off or made incomprehensible or inaccessible?
   2. Do the menus become inaccessible or unreadable? If they disappear into a hamburger menu (3 parallel lines), can you still access them with the keyboard? Or with Select All?
      1. Rationale: Some users with low vision may use several zoom settings on their browsers. An accessible website is usable whether someone is on a big screen or a little screen, or if they have it zoomed in up to 400%.
10. Are the links on the website accessible?
    1. Are the links a different color from the regular text? Are they underlined?
       1. Rationale: Both of these are visual cues that the text is meant to be a link and/or activated in some way. The different colors of the visited/unvisited link should be of enough contrast that it would pass the color blind test. Use the WebAIM Contrast Checker.
    2. Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?
       1. Rationale: Links can be activated by Tabbing and then pressing Enter or Spacebar. When navigating a page looking for the Registration link, for example, if all the links say “click here” or “here”, it makes it harder to find the link a user is looking for, especially when they are using alternate means to access the web.
11. Do all videos use subtitles or closed captioning? Are transcripts available for audio content (and do they have timecodes)? Are they automatically generated? Are they accurate?
    1. Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.
12. Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.
13. Note if there is information, such as support documentation, that is only conveyed through PDFs (especially non-digitally-native scanned PDFs or visually complex PDFs), or complex images (jpg or png) without robust associated text descriptions/captions.
    1. Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. Certain users will not have access to the information conveyed in complex images designed to convey information (e.g. screenshots of workflows) if they do not have associated descriptive captions or text.Complex images designed to convey information but without associated descriptive captions or text will mean certain users will not have access to the information conveyed in the images (for example, screenshots of workflows).

Next Steps

These tasks are more easily accomplished by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually. Please consult the full Accessibility Auditing Resources list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing. These steps have fewer explanatory text because they are geared towards more experienced testers.

1. Perform whatever tests you typically perform while doing an accessibility audit and share your results on the working document, such as using the steps above or an advanced accessibility checker like AXE (browser extension). Record the results.
2. If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.
3. Does navigation facilitate ease of use?
   1. Consistent layout and design
   2. No broken links, or there is a way to report broken links
   3. Page content hierarchy follows heading guidelines
   4. Underlined text is avoided unless used for URL navigation
   5. Is the reading/document order logical and/or natural?
   6. Is there a “skip to main content” link? Does it go to the most logical “main content?”
4. Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the W3 Image Tutorial Tips and Tricks for guidance on constructing alt text.
5. Does the site properly use ARIA landmarks?
6. Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)
   1. What barriers are encountered?
   2. Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?
   3. Can a user navigate and use the site without using sight?
7. Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading.
8. How does the website look or perform on a mobile device browser? Test both Android and iOS.
9. Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?

Assistive Technology User Testing

Above all, it’s necessary to engage with disabled users and their specific needs in testing and evaluating software and websites. Direct experience and feedback are the most important aspect of accessibility testing, as it is difficult to judge something without a real world test. Disabled users are the experts at using their own Assistive Technologies, and can give practical work-arounds that may be missed by other users (especially when they are new to the AT or software, or are stressed out because something isn’t working).

If you use a specific type of AT yourself, we ask you to join in and share your experience with the GLAM technologies we are examining. Some of our current DAWG IT/Developers members are screen reader users and keyboard-only users, but we welcome anyone’s feedback. If you are doing testing at your own organization, it is important to compensate disabled users for their time and expertise. Even if the person is an employee at your organization, if it is not part of their regular duties, they should receive extra compensation.

Websites you can practice on

• Prezi.com
  • This is a good site to test the WAVE tool with, as it has many errors.
• Pizzahut.com
  • Can you order a pizza using just the keyboard?
• DLF’s Wiki
  • This wiki uses a basic instance of MediaWiki.
• A11y Project
  • This website has several tutorials on accessibility, so you can use it to practice testing while also learning more about accessibility.
• W3 Example of an Inaccessible Webpage
  • This example website is purposely inaccessible, and includes annotations explaining things, as well as the accessible version

• Back to main Digital Accessibility Group page.