As digital products and services become increasingly integral to our daily lives, ensuring accessibility for all users, including those with disabilities, is paramount. This article provides a comprehensive accessibility testing checklist, tailored for teams, product managers, and developers, to help create inclusive and user-friendly experiences. By following this checklist, you can proactively identify and address potential accessibility barriers, ultimately improving the usability and satisfaction of your product.

1. Introduction: Why Accessibility Testing Matters

In this section, we will discuss the importance of accessibility testing in the product development lifecycle. Accessibility testing is a crucial process that ensures digital products and services are usable by people with disabilities. By conducting thorough accessibility testing, development teams can proactively identify and address potential barriers, creating a more inclusive and user-friendly experience for all users. Accessibility is not just a technical requirement; it's a fundamental aspect of ethical and responsible product design. Prioritizing accessibility from the outset of a project can lead to significant benefits, including:

• Expanded Reach: By making your product accessible, you open it up to a wider audience, including the millions of people with disabilities.
• Improved Usability: Accessibility best practices often align with general usability principles, resulting in a better experience for all users.
• Legal Compliance: Many countries have accessibility laws and regulations, such as the Americans with Disabilities Act (ADA), which mandate accessibility for certain digital products and services.
• Enhanced Brand Reputation: Demonstrating a commitment to accessibility can enhance your brand reputation and foster goodwill among users.

This comprehensive accessibility checklist is designed to guide teams through the required and recommended testing procedures, ensuring compliance with Web Content Accessibility Guidelines (WCAG) 2.2 and other relevant standards. This checklist serves as a valuable artifact for documenting testing efforts and progress, particularly during staging reviews.

Why VFS Teams Should Prioritize Accessibility Testing

The more testing and issue resolution conducted before staging reviews, the less likely launch-blocking accessibility issues will arise. This proactive approach not only streamlines the development process but also ensures a smoother and more inclusive user experience. This artifact, generated from the checklist, serves as a documented record of accessibility testing efforts, highlighting identified issues and their resolutions. It also provides valuable insights into the product's accessibility landscape before formal reviews.

2. Before You Begin: Setting the Stage for Accessibility

Before diving into the checklist, it's essential to understand the foundation upon which it's built. The required and recommended checks are meticulously crafted based on WCAG 2.2 and the VA.gov Accessibility Standards, ensuring a robust approach to accessibility evaluation. Familiarize yourself with these standards to gain a deeper understanding of the principles guiding the checklist.

Key Pre-Testing Steps

To ensure a smooth and effective testing process, several preliminary steps are essential. These steps lay the groundwork for a comprehensive evaluation and help streamline the subsequent testing phases.

1. Product Information: Ensure all relevant product information is accurately documented. This includes the team name, product name, and feature name, which should be clearly added to the issue title. Additionally, incorporate the team label, product label, and feature label (if applicable) into the issue.
2. Understanding the Standards: Take the time to thoroughly understand WCAG 2.2 and the VA.gov Accessibility Standards. These guidelines provide the foundation for the checklist and a deeper understanding of accessibility principles will lead to more effective testing.
3. Addressing Incomplete Checks: If you encounter a required check that you cannot complete, it's crucial to document the reason. Add a comment to the ticket explaining the circumstances preventing completion. This transparency helps maintain a clear record of the testing process.

3. Accessibility Checklist: A Deep Dive into Required and Recommended Items

The heart of this guide lies in the accessibility checklist itself. This comprehensive list is divided into several key areas, each focusing on specific aspects of accessibility. Remember, thoroughness is key. Each check should be performed on every page of your product or service to ensure consistent accessibility across the entire user experience. As you work through the checklist, meticulously document your findings, marking items as "Pass" or "Fail" based on your observations.

Navigating the Checklist

The checklist is structured to provide clear guidance and facilitate a systematic approach to testing. Here's a breakdown of the key elements:

• Fail Indicators: If an issue is identified during a check, immediately mark the item as "Fail." This serves as a clear indicator that further action is required.
• Multiple Issues: It's possible to uncover multiple issues while performing a single check. Be diligent in documenting each issue to ensure comprehensive remediation.
• Issue Logging: For every "Fail" identified, detailed issue logging is essential. This involves documenting the specifics of the issue, its location, and any other relevant information to facilitate resolution.
• Non-Applicable Checks: If a particular check is not applicable to your product or feature, mark it as "Passed" to indicate that it has been considered and deemed irrelevant.
• Testing Guidance: Each checklist item includes a "How to test" link. This link provides detailed guidance and instructions on how to perform the check effectively. If you have further questions or require clarification, don't hesitate to post a comment on the ticket or reach out to accessibility specialists for assistance.

3.1 Automated Testing

Automated accessibility testing is a critical first step in identifying potential issues. Tools like Axe DevTools can quickly scan your product for common accessibility violations. However, it's important to remember that automated testing is not a substitute for manual testing, which is necessary to catch more nuanced issues.

Required Checks

• Axe DevTools has been run on every page (Automated-001): This check mandates the use of Axe DevTools, a powerful automated accessibility testing tool, on every page within your product's flow. This includes all page variations and interactive states of content. To learn more about testing with Axe DevTools, refer to the provided documentation. Ensure you include screenshots or the output of the Axe results in a comment on the ticket to provide a clear record of the findings.
  • [ ] Pass
  • [ ] Fail
  • [ ] Include screenshots or output of AXE results in a comment on this ticket
• Axe-core has been integrated into end-to-end testing (Automated-002): This requirement emphasizes the importance of integrating accessibility testing into your existing end-to-end testing processes. By incorporating Axe-core, the underlying engine of Axe DevTools, into your Cypress or other testing libraries, you can ensure that accessibility is continuously evaluated as part of your development workflow. For guidance on integrating Axe-core, consult the provided documentation. Provide a link to the evidence of Axe integration in a comment on the ticket to demonstrate compliance.
  • [ ] Pass
  • [ ] Fail
  • [ ] Provide a link to, or evidence of, AXE integration in a comment on this ticket

3.2 Images

Images play a crucial role in conveying information, but they can also be a significant barrier for users with visual impairments. Providing appropriate alternative text descriptions is essential for ensuring accessibility.

Required Checks

• Meaningful descriptions are provided for informative images (WEB-111-001): All informative images must have a text alternative (alt text) that accurately describes the image's content and purpose. The alt text should be meaningful and serve as an equivalent substitute for the image itself.
  • [ ] Pass
  • [ ] Fail
• No images of text (WEB-145): Avoid using images to display text whenever possible. Text within images is not scalable, selectable, or accessible to screen readers. Use native HTML and CSS to render text instead. Logos and branding elements are exceptions to this rule.
  • [ ] Pass
  • [ ] Fail

Recommended Checks

• Brief and detailed descriptions are provided for complex images (WEB-111-002): Complex images, such as graphs, charts, and maps, often require both alt text and longer descriptions to convey their full meaning. The alt text should provide a concise summary, while the longer description can provide more detailed information.
  • [ ] Pass
  • [ ] Fail
• Decorative images are hidden from screen readers (WEB-111-003): Images that are purely decorative and do not convey any meaningful information should be hidden from screen readers. This can be achieved by using an empty alt attribute (alt="") or ARIA attributes.
  • [ ] Pass
  • [ ] Fail
• Background images are not used for informative content (WEB-111-004): Background images should not be used to convey essential information. If content is displayed as a background image, ensure that the same information is available through other means, such as text.
  • [ ] Pass
  • [ ] Fail

3.3 Audio & Video

Audio and video content must be accessible to users with auditory and visual impairments. This includes providing captions, transcripts, and audio descriptions.

Required Checks

• Captions are provided for all prerecorded videos (WEB-122): All prerecorded videos must include synchronized captions that accurately transcribe dialogue, sound effects, and other relevant audio information.
  • [ ] Pass
  • [ ] Fail
• Transcripts or audio descriptions are included for videos (WEB-123): For non-live video content, provide either a full descriptive transcript or an audio description. A transcript is a text-based version of the video's audio content, while an audio description provides narration of visual elements.
  • [ ] Pass
  • [ ] Fail
• Auto-playing audio can be paused or has volume controls (WEB-142): If audio plays automatically for more than 3 seconds, users must be able to pause the audio or control its volume independently.
  • [ ] Pass
  • [ ] Fail

Recommended Checks

• Text transcripts are provided for audio and video-only content (WEB-121): For audio-only and video-only media, a transcript should be provided that conveys the same information as the original content.
  • [ ] Pass
  • [ ] Fail
• Real-time captions are provided for live videos (WEB-124): Live video content should include synchronized captions generated in real-time.
  • [ ] Pass
  • [ ] Fail

3.4 Structure & Semantics

Proper semantic structure is crucial for creating accessible content. Using appropriate HTML elements and heading levels helps users navigate and understand the content.

Required Checks

• Headings match the content hierarchy and use proper HTML tags (WEB-131-001): Headings should accurately reflect the content hierarchy and be marked up using semantic HTML heading tags (

  through

  ).

  • [ ] Pass
  • [ ] Fail

• Headings follow a logical order without skipping levels (WEB-131-002): Heading levels should follow a logical, sequential order without skipping levels. For example, an

  should not follow an

  without an

  in between.

  • [ ] Pass
  • [ ] Fail

• There is one H1 per page/screen (WEB-131-003): Each page or screen should have a single

  element that represents the main topic or purpose of the content.

  • [ ] Pass
  • [ ] Fail

• Each page has a unique, descriptive title (WEB-242): Each web page or screen should have a unique and descriptive title that reflects its purpose. The title is displayed in the browser tab and is used by screen readers to identify the page.
  • [ ] Pass
  • [ ] Fail
• Headings are descriptive (WEB-246-001): Heading text should accurately describe the topic or purpose of the content that follows.
  • [ ] Pass
  • [ ] Fail

Recommended Checks

• Lists use proper list formatting (WEB-131-004): All visually apparent lists should be marked up using semantic list elements (<ul>, <ol>, <dl>).
  • [ ] Pass
  • [ ] Fail
• Content is organized into sections (WEB-2410): Where content is organized into sections, section headings should be provided to help users understand the structure of the page.
  • [ ] Pass
  • [ ] Fail
• The page language is identified (WEB-311): The <html> element should include a valid lang attribute specifying the page's primary language.
  • [ ] Pass
  • [ ] Fail
• Content in another language is identified (WEB-312): Text in different languages from the page's primary language should be marked with lang attributes.
  • [ ] Pass
  • [ ] Fail

3.5 Color, Contrast, & Sensory

Color should not be the sole means of conveying information, and sufficient contrast between text and background is essential for readability.

Required Checks

• Instructions don't rely only on color, shape, size, or sound (WEB-133): Instructions and cues should not rely exclusively on sensory characteristics. For example, don't say "Click the blue button" without providing another way to identify the button.
  • [ ] Pass
  • [ ] Fail
• Information is not communicated by color alone (WEB-141): Color should never be the sole visual means of conveying information. Use text or other visual cues in addition to color.
  • [ ] Pass
  • [ ] Fail
• Text has sufficient contrast against its background (WEB-143): Text and images of text must have a contrast ratio of at least 4.5:1 against their background. Large-scale text (18pt or 14pt bold) requires a contrast ratio of at least 3:1. Use a contrast checker tool to verify compliance.
  • [ ] Pass
  • [ ] Fail
• Interactive elements are visually distinct from surroundings (WEB-1411-001): Active UI components should achieve a 3:1 contrast ratio against adjacent colors to ensure they are easily identifiable.
  • [ ] Pass
  • [ ] Fail
• Important graphics and icons have sufficient contrast (WEB-1411-002): Essential graphical objects should maintain a 3:1 contrast ratio to ensure they are visible and understandable.
  • [ ] Pass
  • [ ] Fail

3.6 Layout & Responsiveness

Content should be adaptable to different screen sizes and zoom levels without loss of functionality or information.

Required Checks

• Text can be enlarged to 200% without breaking the page (WEB-144): Text should be resizable up to 200% without loss of content or functionality. This allows users with low vision to increase text size for better readability.
  • [ ] Pass
  • [ ] Fail
• Content fits on small screens without horizontal scrolling (WEB-1410): Content should reflow to a single-dimension scroll at 320x256 CSS pixels and larger, preventing horizontal scrolling on small screens.
  • [ ] Pass
  • [ ] Fail

Recommended Checks

• Content works in both portrait and landscape mode (WEB-134): Content should be viewable and functional in both portrait and landscape orientations, unless there is a specific reason to restrict orientation.
  • [ ] Pass
  • [ ] Fail
• Text remains readable when spacing is adjusted (WEB-1412): No content or functionality should be lost when text is styled with increased line spacing, letter spacing, word spacing, and paragraph spacing. Users should be able to override default styling without causing issues.
  • [ ] Pass
  • [ ] Fail

3.7 Keyboard & Focus

Keyboard accessibility is essential for users who cannot use a mouse. All interactive elements should be accessible and operable using only a keyboard.

Required Checks

• All functionality works with keyboard only (WEB-211): All interactive elements and features must be accessible and operable using only a keyboard.
  • [ ] Pass
  • [ ] Fail
• No keyboard trap (WEB-212): Users should never get trapped within an element when navigating with the keyboard. It should always be possible to move focus away from any element using standard keys.
  • [ ] Pass
  • [ ] Fail
• Every focusable element has a visible focus indicator (WEB-247): All interactive elements should display a visible outline or indicator when they receive keyboard focus. This helps users understand which element is currently selected.
  • [ ] Pass
  • [ ] Fail

Recommended Checks

• Tab order follows a logical sequence (WEB-243): Keyboard focus should move through interactive elements in a meaningful order, typically from left to right and top to bottom.
  • [ ] Pass
  • [ ] Fail
• The element with focus is always visible (WEB-2411): The visible focus indicator should not be obscured by other content, ensuring that users can always see which element has focus.
  • [ ] Pass
  • [ ] Fail
• Focusing on an element doesn't trigger unexpected changes (WEB-321): Focusing an element should not trigger a change of context, such as navigating to a new page or opening a dialog. Changes of context should only occur as a result of user action.
  • [ ] Pass
  • [ ] Fail
• Interacting with form fields doesn't trigger unexpected changes (WEB-322): Changing form values should not automatically cause navigation or context changes. Submitting a form should be a deliberate action by the user.
  • [ ] Pass
  • [ ] Fail

3.8 Timing & Interruptions

Users should have sufficient time to interact with content, and interruptions should be minimized or controllable.

Required Checks

• Automatically moving content can be paused or stopped (WEB-222): All moving, blinking, scrolling, or auto-updating content that starts automatically and lasts over 5 seconds must provide mechanisms to pause, stop, hide, or control its frequency.
  • [ ] Pass
  • [ ] Fail

3.9 Navigation & Consistency

Consistent navigation and clear mechanisms for bypassing repeated content are essential for usability.

Required Checks

• Users can skip repeated content like headers and navigation (WEB-241): A mechanism should be provided to bypass repeated blocks of content, such as navigation menus and headers. This can be achieved using a skip link, HTML5 landmarks, or other techniques.
  • [ ] Pass
  • [ ] Fail

Recommended Checks

• Pages can be found in multiple ways (WEB-245): Two or more mechanisms for finding a webpage should be available, such as a site map, search function, or table of contents. This is not required if the page is accessed as part of a step in a process.
  • [ ] Pass
  • [ ] Fail
• Navigation structure is the same across pages (WEB-323): Navigation menus should maintain consistent order and structure across multiple pages to help users orient themselves within the site.
  • [ ] Pass
  • [ ] Fail
• Help options appear in the same location on all pages (WEB-326): Help mechanisms, such as contact details, messaging, chat, or self-help options, should be in the same relative order on all pages where the information is present.
  • [ ] Pass
  • [ ] Fail

3.10 Forms & Interactive Controls

Forms should be structured and labeled clearly to ensure users can easily understand and complete them.

Required Checks

• Form labels clearly describe what to enter (WEB-246-002): Labels should accurately describe the purpose or function of form fields and controls.
  • [ ] Pass
  • [ ] Fail
• Form fields have visible labels (WEB-332-001): Visible labels or instructions should be available for all inputs and input groupings.
  • [ ] Pass
  • [ ] Fail
• Fields with specific formats include instructions (WEB-332-002): Form fields that require specific formats (e.g., dates, phone numbers) should provide instructions or examples.
  • [ ] Pass
  • [ ] Fail
• Required or optional fields are clearly marked (WEB-332-003): All required fields should be identified with visible labels or instructions, OR all optional fields should be identified with visible labels or instructions.
  • [ ] Pass
  • [ ] Fail
• Error messages explain how to fix the problem (WEB-333): Users should be provided with clear suggestions for correcting input errors, unless doing so would compromise security or the content's purpose.
  • [ ] Pass
  • [ ] Fail
• Links navigate to pages; buttons perform actions (WEB-412-003): User interface elements defined as links should be used for navigation, while elements defined as buttons should perform in-page actions or submit forms.
  • [ ] Pass
  • [ ] Fail

Recommended Checks

• Related form elements are grouped together (WEB-131-005): Related form controls (e.g., radio buttons, checkboxes, multi-part text inputs) should be semantically grouped to convey their relationships.
  • [ ] Pass
  • [ ] Fail
• Required fields are clearly marked with text and in code (WEB-131-007): Required fields/controls should be identified in text and programmatically using ARIA attributes.
  • [ ] Pass
  • [ ] Fail
• Links are descriptive (WEB-244): Link text or its accessible name should describe the link's destination or purpose.
  • [ ] Pass
  • [ ] Fail
• Error messages are provided and are clear (WEB-331): Whenever an input error is detected, the user should be informed of the error and how to correct it.
  • [ ] Pass
  • [ ] Fail

4. Next Steps: Completing the Accessibility Journey

Once you've diligently worked through the accessibility checklist, the journey isn't quite over. The next steps involve ensuring that your findings are properly documented, communicated, and acted upon. This final phase is crucial for solidifying your accessibility efforts and ensuring that your product is truly inclusive.

Key Actions for Post-Testing

1. Update Collab Cycle Ticket: A crucial step is to add a link to your completed accessibility testing ticket within the staging review artifacts section of your Collaboration Cycle ticket. This provides a clear and accessible record of your testing efforts within the broader project context. Once the staging review is complete, you can confidently close the accessibility testing ticket.
2. Report Identified Issues: Transparency is key. Any issues identified during testing should be reported as part of your staging review. The accessibility testing artifact, meticulously completed during the process, should be readily available when the product is ready for staging review. If your team employs an alternative issue-tracking system, ensure that information is clearly communicated within the ticket.

Detailed Issue Reporting

For each identified issue, comprehensive reporting is essential. This ensures that developers have the information they need to effectively address the problem.

• Log the Issue: Utilize the provided Accessibility issue template to document the issue. Fill in as much detail as possible, providing a clear description of the problem, its location, and any steps to reproduce it.
• Assign and Label: Assign the issue to jasonday and add the a11y-testing label. This ensures that the issue is properly routed and categorized.
• Milestone Integration: Add the created issue to the Collaboration Cycle milestone found in your collab cycle ticket. This links the issue to the overall project timeline and helps track progress.
• Link in Comment: Finally, provide a link to each logged issue within a comment on the accessibility testing ticket. This creates a centralized repository of all identified issues and facilitates efficient tracking.

By diligently following these steps, you can ensure that your accessibility testing efforts translate into a truly inclusive and user-friendly product. Remember, accessibility is not just a one-time task; it's an ongoing commitment. Continuously testing and improving your product's accessibility will benefit all users and contribute to a more equitable digital landscape.

For further information on accessibility best practices, visit the Web Accessibility Initiative (WAI) website.