Web Accessibility Testing
Basic Accessibility Checklist
The following questions are basic tests that most users can run either with automated tests, or using techniques and tools already available on a user's device (computer, phone, tablet, etc.).
Most of these questions are based on Karl Groves' "The 6 Simplest Web Accessibility Tests Anyone Can Do."
Question 1: Can the user navigate by keyboard alone?
A user should be able to go to all relevant content using keys like Tab, Shift + Tab, arrow keys, Escape, and Enter/Return. There also shouldn’t be “keyboard traps,” when a user can’t exit certain features using only a keyboard.
If a user navigates by keyboard or keyboard-like technologies, focus indicators should tell the user where they are at on the screen. This could be a border around an element, a highlight, change in background, or some other visual that clearly shows location on screen.
WCAG Criteria: Operable 2.1.1-3, 2.4.3, 2.4.7
Question 2: Is color the only means of conveying important information?
Using only color to present key information will be difficult for users who can’t tell certain colors or shades apart. A textual equivalent should describe the information in addition to color. This is especially important if there are any kind of forms, questionnaires, or other components that require users to give information and/or check for errors.
Error message helps, but would help users troubleshoot quickly if it outlined or described which field was invalid.
WCAG Criteria: Perceivable 1.4.1
Question 3: If there are images or media, are text alternatives provided?
If there is non-text content included such as podcasts, videos, screencasts, or graphics included in the interface, then textual alternatives should be provided as an accessible means of conveying the same information.
For non-text like images, linked images, or tables, there should be alternative text describing the graphic, or a long description available on another page. For media like audio or podcasts, transcripts must be also provided. For video or other audiovisual content, transcripts and captions are both provided.
If CAPTCHA is required to verify someone is human, the interface should allow users to give input in a variety of ways. At a minimum, a user should be able to decide to type text or listen to audio CAPTCHA. If for any reason a user is unable to complete a CAPTCHA, the vendor must demonstrate how they will support users in removing that barrier.
Note: 2017's screen reader survey by WebAIM shows that CAPTCHAs were still difficult to use for people who use assistive technology or have disabilities, especially screen reader users. If there are products that use more accessible verification techniques, please consider those products before choosing one with CAPTCHA.
WCAG Criteria: Perceivable 1.1.1, 1.2.1-5, 1.4.5
Question 4: Is there proper heading structure on the page?
A web page with a reasonable heading structure makes it easier to understand content and how different sections relate to each other. Headings also aid in navigation for users that rely on assistive technology, and can still convey meaningful structure if the visual display of the page is altered.
WCAG Criteria: Perceivable 1.3.1, Operable 2.4.1 and 2.4.6
Question 5: If there's moving content, can it be stopped?
Content that autoplays or repeats on a loop, like a video in a site's banner or a repeating GIF, can be distracting for users that may have difficulty focusing on a certain task. Autoplaying content can also be troublesome if sound plays on page load, and a user requires audio to understand and navigate page content. Users should have the ability to stop any media content that plays automatically or repeats.
WCAG Criteria: Operable 2.2.2, 2.4.1
Question 6: Can you use the website or app on a mobile device?
Some users require assistive devices that provide accessibility assistance, but may be smaller than the average laptop or desktop. This means a site or application's ability to adapt to different device sizes without losing key functionality is important.
A quick test is to either shrink the browser window, or to use the website or web app on a mobile device (smartphone/tablet). Then, try to access the same features that normally would be accessible. Look for any key tasks that suddenly aren't easy to find, or vanish altogether when using a mobile device or shrinking the width of the browser.
The following list outlines how to make text larger on the most common platforms.
- Change the font size on your iPhone, iPad, and iPod touch
- Change the size of text in Windows 10
- Android Accessibility Help: Font size and display size
WCAG Criteria: Perceivable 1.4.10, Navigable 2.5
This list provides the most commonly used screen readers, and how to use them for accessibility testing.
- JAWS (Windows, trial version)
- NVDA (Windows)
- VoiceOver (MacOS/iOS)
Keyboard testing can tell you if the order of content matches the visual layout and if there are features that are difficult to access without a mouse.
- WebAIM: Keyboard Accessibility
- University of Washington: Designing for Keyboard Accessibility
- Bureau of Internet Accessibility: What is Keyboard Accessibility?
- Vox Media Accessibility Checklist — can be integrated into Slack or Trello project workflows
- ESPN Web Accessibility Guidelines
- University of Washington IT Accessibilty Checklist
- WebAIM Quick Reference
- Karl Groves: The 6 Simplest Web Accessibility Tests Anyone Can Do