Manual Accessibility Testing: Developer’s Overview

This high-level technical guide for web developers outlines fundamental techniques for manual accessibility issue identification. The information below involves keyboard and screen reader testing and is in accordance with internationally-recognized World Wide Web Consortium (W3C) WCAG 2.2 A & AA standards. As a courtesy to devs still learning about accessibility, this guide links to other resources for more granular information about identification and remediation. To learn more about accessibility from a developer’s perspective, please refer to a11y4developers.uic.edu.

The objective of keyboard-only testing is to navigate through all interactive elements on the page with the 9 standard input keys and assess its performance when not using a mouse. Your web component's purpose determines what keyboard users expect, so consider what your users will experience when interacting with your creation. Generally speaking, good keyboard accessibility also helps avoid many related screen reader issues, so it's recommended to test keyboard performance first.

🔎Look for the following 🔍

• All conditional failures of expected behavior for keyboards. To summarize: key,action, focus. If you press the expected (1) key, then the expected (2) action must occur, and the (3) focus indicator must move to the expected location.
• Use cases where mouse interaction doesn't have a keyboard equivalent. If the thing is clickable, it must be accessible via keyboard. E.g., ⭐ users expect the Tab key will advance the focus indicator from one interactive element to the next logical interactive element. As a rule of thumb, avoid remapping the default navigation input keys. Custom key shortcuts may be implemented as a supplement, but be aware of WCAG restrictions (refer to  WCAG guideline 2.1.4 Character Key Shortcuts -- Level A for details).
• Illogical reading order when tabbing through interactive elements.
• Focus indicator issues. After manual interaction, your browser's built-in focus indicator should appear as a complete, consistent blue outline around all sides of the expected location. E.g., ⭐ if you press the tab key, the focus indicator should move to the next logical focusable element.
• Anything related to input or focus that is confusing or unexpected.

The objective of screen reader testing is to navigate forward & backwards through the page using the screen reader's key combination shortcuts. Test all page elements and their screen reader "announcements" for accuracy and clarity. Screen reader users expect certain behavior, which depends on your component's intended purpose. Here are some examples of free screen reader software available for public use: NVDA on Windows (free & open source), Apple VoiceOver on MacOS & iOS (free native app, see our Voiceover "how to" section on the a11y4developers site, or Orca on Linux (free & open source, built for GNOME desktop environment). .

🔎Look for the following 🔍

• All conditional failures of expected behavior for screen readers. To summarize: key combination, action, focus, announcement. If you press the expected (1) key combination, then the expected (2) action must occur, the (3) focus indicator must move to the expected location, and the screen reader must make the expected (4) announcement, which must communicate the element's role, state, label, and/or content.
• Elements not identified or "announced" properly. The screen reader should announce everything on the page except for decorative elements and anything unrelated to content.
• Interactive elements that can't be activated. If the thing is clickable, you must be able to activate it with screen reader software.
• Interactive elements that don't announce state change when their activation changes page content. E.g., ⭐ if activating a closed accordion panel button, the screen reader should announce something like "button, expanded" immediately upon activation.
• Redundancy in page content, especially labels and heading elements.
• Focus indicator issues. After manual interaction, the screen reader's focus indicator should appear at the expected location. E.g., ⭐ if you press CTRL OPTION RIGHT in Voiceover, the screen reader's focus should move to the next element in the reading order.

After keyboard and screen reader testing, inspect your code for a few more contextual issues that automated scans are unable to completely address.

🔎Look for the following 🔍

• Inappropriate use of semantic markup and ARIA roles. Ensure HTML elements are used properly to render the content's structure and purpose and do not contain redundant or conflicting aria roles. E.g., ⭐ these two examples intended for button usage are incorrect: <button role="button" class="heading-button"> and <button role="heading" class="heading-button">.
  In contrast, this element: <div role="button" class="heading-button"> uses ARIA appropriately and should only be used as a button. Please note that while this button example does use the correct ARIA role, it still requires scripting to make it as keyboard accessible as the native button element. In general, native semantic HTML elements are preferable and easier to maintain due to their inherent accessibility features. Block-level <div> and inline <span> elements are generic containers for organizing content and should only be used for interactivity if no other options exist. If you use ARIA attributes in your code, be sure to use them properly as recommended by W3C.
• Incorrect ARIA mechanism or container for announcing dynamic content changes. Please note, there are two different types of ARIA roles for this: (1) Live region roles (alert, log, marquee, status, timer) and (2) Window roles (dialog, alertdialog), which are all intended for use in specific contexts. E.g., ⭐ if a critical error or security timeout occurs, it should be announced immediately using the alert role.