Accessibility Auditing Shortlist: Difference between revisions

From DLF Wiki
← Older edit
 
(11 intermediate revisions by the same user not shown)
Line 11: Line 11:
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 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 [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].
As with all work by the DLF DAWG IT/DEV, we are guided by the mission and values of our parent organization, the [https://wiki.diglib.org/Digital_Accessibility_Group Digital Accessibility Working Group].
==Considerations for non-English and Multilingual items==
The [https://www.w3.org/International/questions/qa-html-language-declarations 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 [https://www.freedomscientific.com/SurfsUp/Languages.htm automatically with JAWS], but [https://nvda.groups.io/g/nvda/topic/multi_language_support/25171008 may not function correctly with NVDA] or other screen readers or [https://uxdesign.cc/the-troubled-state-of-screen-readers-in-multilingual-situations-f6a9da4ecdf3 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. [https://accessibility.psu.edu/foreignlanguages/langtaghtml/ 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==
==Checklist==
Line 22: Line 27:
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ 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 [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.
# Does the vendor or website have a [https://www.section508.gov/sell/vpat/ 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 [https://libraryaccessibility.org/ Library Accessibility Alliance]? Use a search engine of choice to find out and record this information.
## 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 [https://libraryaccessibility.org/ 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.
## 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 [https://libraryaccessibility.org/ 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.
# 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).
## 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.
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].
# Run the [https://wave.webaim.org/ WAVE Automatic Accessibility tool] if it’s a webpage or browser-based program. WAVE is also available as a [https://wave.webaim.org/extension/ browser extension].
## Report these errors (found in the Details tab)
## Report these errors (found in the Details tab)
Line 42: Line 49:
## Does the vendor include a list of keyboard shortcuts? Record that information.  
## Does the vendor include a list of keyboard shortcuts? Record that information.  
## 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?
## 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?
 
# Does the website or software require the user to drag-and-drop to do something, without having an alternative?
 
## Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.
 
# Does the website use color alone to denote meaning?  
 
## Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.
 
## 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?
 
### 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.
#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.
# Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.
##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.
## Is any information cut off or made incomprehensible or inaccessible?
#Run the [https://wave.webaim.org/ WAVE Automatic Accessibility] tool if it’s a webpage or browser-based program. (This is also available as a browser extension.)
## 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?
##Report these errors (found in the Details tab), and make a note in the relevant step in the rest of the list:
### 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%.
###Color Contrast (low or very low contrast?)
# Are the links on the website accessible?
###Missing Alternative Text
## Are the links a different color from the regular text? Are they underlined?
###Missing Link Text
### 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. [https://webaim.org/resources/contrastchecker/ Use the WebAIM Contrast Checker].
###Broken ARIA
## Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?
###Heading Structure
### 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.
###Anything else listed under the Error tab.
# 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?
##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.
## Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.
#Install and use the [https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi?hl=en HeadingsMap extension] (for Chrome and Firefox) to check the headings on the page.
# Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.
##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.
# 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.
#Test out basic keyboard access to the website ([https://nomouse.org/ NoMouse.org] and [https://webaim.org/techniques/keyboard/ Keyboard Accessibility Basics]).
## 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).
##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?
###Rationale: This tests if users are able to access the major active elements on a page with just the keyboard.
##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?
###Rationale: This tests being able to navigate through a dropdown menu or activate checkboxes on the page without using a mouse.
##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?
###Rationale: This tests to see if there are some 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 you need to report that information.
##Does the vendor or website have a list of keyboard commands available to users? Record that information.
#Does the website use color alone to denote meaning? Use the [http://www.rgblind.se/url RGBlind color blindness simulator] on the website.
##Does being color blind in some way affect a user’s ability to fully use the site? Is there a significant difference between a visited link and a non-visited link?  
###Rationale: Using color alone can affect how users who are colorblind use the website, because the meaning denoted in the difference in color may not be noticed by folks who are color blind.
#Test the page with magnification. Zoom in 200%, then 300%, then 400% to confirm readability of content.
##Is any information cut off or made incomprehensible or inaccessible?  
##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?  
###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%.  
#Are the links on the website accessible?  
##Are the links a different color from the regular text? Are they underlined?  
###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.  
##Check the actual text of the link--does it say where it goes, or does it just say something generic like “click here”?  
###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.  
#Do all videos use subtitles or closed captioning? Are transcripts available for audio content?  
##Rationale: Providing alternate means of accessing audio content is important for individuals who prefer or have to access audio content, visually.
#Does the vendor or website have a Voluntary Product Accessibility Template (VPAT) available online? Is there an evaluation available at the [https://www.btaa.org/library/accessibility/library-e-resource-accessibility--testing Big 10 Academic Alliance] site? Record this information.
##Use a search engine of choice to find out!
###Rationale: This document is a vendor’s self-disclosure of their accessibility, although the existence of a VPAT alone doesn’t indicate accessibility. The Big 10 Academic Alliance Library/IT group 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.  
#Are there any complaints, posts about accessibility issues, or other general discussion around the accessibility of the software or website online? Record this information.  
#Does the website or software require the user to drag-and-drop to do something, without having an alternative?
##Rationale: Drag-and-drop is a very complicated move to make without a mouse, fine motor control, or physical control or steadiness.


===Next Steps===
===Next Steps===
These tasks should be completed by someone who has more experience or knowledge about accessibility auditing. These are often issues that can only be found by testing manually, by someone who has some experience. As you feel more comfortable with the techniques you are learning, you can continue to expand our collection of information about a service. Please consult the full [[Accessibility Auditing Resources]] list for courses, tools, specifications, and guidelines that go in depth in accessibility auditing.
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 [https://wiki.diglib.org/Accessibility_Auditing_Resources 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.


#Perform whatever tests you typically perform while doing an accessibility audit, and share your results on the working document. If you have knowledge about VPATs, please share your insights to the VPAT for the service if it exists.  
# 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 [https://www.deque.com/axe/ AXE] ([https://www.deque.com/axe/devtools/ browser extension]). Record the results.
#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.
# If you have knowledge about VPATs, please share your insights about the VPAT for the service if it exists.
##Rationale: PDFs may introduce inaccessibility for some users, so having vital guidance and support information in PDF form could indicate potential challenges. 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).
# Does navigation facilitate ease of use?
#Test out the keyboard accessibility of the software.
## Consistent layout and design
##Does the vendor include a list of keyboard shortcuts? Are the shortcuts significantly different from what’s typically used?
## No broken links, or there is a way to report broken links
##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?
## Page content hierarchy follows heading guidelines
##Can a user see the focus state of where the focus is on the webpage?
## Underlined text is avoided unless used for URL navigation
#Does navigation facilitate ease of use?
## Is the reading/document order logical and/or natural?
##Consistent layout and design; design elements increase predictability
## Is there a “skip to main content” link? Does it go to the most logical “main content?”
##No broken links, or there is a way to report broken links
# Do images have useful alt text, depending on the context? Do they use a null alt text (alt=””) for decorative images? Refer to the [https://www.w3.org/WAI/tutorials/images/tips/ W3 Image Tutorial Tips and Tricks] for guidance on constructing alt text.
##Page content hierarchy follows heading guidelines  
# Does the site properly use [https://accessibility.oit.ncsu.edu/using-aria-landmarks-a-demonstration/ ARIA landmarks]?
##Underlined text is avoided unless used for URL navigation
# Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)
#Do images have alt text? Is the alt text appropriate for the website or software? Do they use a null alt text for decorative images?  
## What barriers are encountered?
#Use [https://www.deque.com/axe/ AXE] ([https://chrome.google.com/webstore/detail/axe-devtools-web-accessib/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US axe chrome extension]) or another advanced accessibility checker to test the webpages for more specific errors. Record the results.  
## Are any pop-ups or form fields invisible to the screen reader? Do any pop-ups or menus not work with a keyboard?
#Is there a “skip to main content” link?
## Can a user navigate and use the site without using sight?
#Does the site properly use aria landmarks?  
# Does the page use proper HTML formatting? Ex. Uses H2 instead of bold or a different color of text to create a heading.
#Test the software/website with a screen reader (NVDA, JAWS, VoiceOver, ChromeVox)
# How does the website look or perform on a mobile device browser? Test both Android and iOS.
##What barriers are encountered?  
# Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?
##Are any pop-ups or form fields invisible to the screen reader?  
##Can a user navigate and use the site without using sight?
##Can a screen reader tell the difference between colored elements?
###Rationale: An example of using color alone to denote meaning is when headings or subheadings are not actually using proper HTML code to mark up the page, a screen reader for example would not be able to recognize that heading or subheading as such, and would read those headings as paragraph text.  
#Are there any complaints, evaluations, or discussions around the software on any AT, IT, or Information professional mailing lists or groups?  
#How does the website look or perform on a mobile device? Is there an app? Is it accessible? Test both Android and iOS.


==Assistive Technology User Testing==
==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.  
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 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==
==Websites you can practice on==
* [https://prezi.com Prezi.com]
* [https://prezi.com Prezi.com]
** This is a good site to test the WAVE tool with, as it has many errors.  
** This is a good site to test the WAVE tool with, as it has many errors.  
* [https://libguides.colgate.edu/remoteprimarysources Colgate University LibGuide with Appointlet]
**Navigate the site with only a keyboard.
**Is it possible to book an appointment with Sarah only using a keyboard? What about Xena?
**Can a user book an appointment using a screen reader? Can you cancel it?
***Rationale: This page has an inaccessible widget for booking an appointment with Xena. It can’t be activated without the mouse, and the form elements are unlabeled, so a screen reader user wouldn’t know what information to put into the form.
* [https://pizzahut.com Pizzahut.com]
* [https://pizzahut.com Pizzahut.com]
** Can you order a pizza using just the keyboard?  
** Can you order a pizza using just the keyboard?  
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]
* [https://wiki.diglib.org/Main_Page DLF’s Wiki]
** This wiki uses a basic instance of MediaWiki.
* [https://www.a11yproject.com/ A11y Project]
* [https://www.a11yproject.com/ A11y Project]
 
** This website has several tutorials on accessibility, so you can use it to practice testing while also learning more about accessibility.
* [https://www.w3.org/WAI/demos/bad/before/home.html 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 [[Digital Accessibility Group|main Digital Accessibility Group page]].
* Back to [[Digital Accessibility Group|main Digital Accessibility Group page]].

Latest revision as of 09:40, 22 November 2023

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


Retrieved from "https://wiki.diglib.org/index.php?title=Accessibility_Auditing_Shortlist&oldid=16625"