Define accessibility testing plan for VADS components

[shiragoodman]

User Story

"As an accessibility specialist, I want an easy-to-follow testing plan for design system components, so that I know how to consistently test each component."

Assignee: @briandeconinck @rsmithadhoc Peer Reviewer: @shiragoodman

Description

Governance team member @briandeconinck put together an overview of accessibility testing coverage and tools doc to communicate the current accessibility testing that is completed for VFS teams at the Collaboration Cycle Staging Review. Using the recommendations and suggestions from the doc, the accessibility specialist from Governance team will work with the accessibility specialist from the Design System team to define a full accessibility test plan for VA Design System web components.

The testing plan should also note technical tool limitations. We should note what testing is possible today vs. what would be possible with the addition of certain tools/devices.

Impacted Artifacts

Tasks

• [ ] Brian and Ryan meet to assign tasks

Peer Review

To be completed by peer reviewer

• [ ] User story and acceptance criteria are met

Acceptance Criteria

• [ ] Governance team and Design System team have defined an accessibility testing plan for VADS components

Team Notification

• [ ] Slack post on #platform-governance-team
• [ ] Presentation at Weekly Initiative Meeting
• [ ] No notification needed

How to prepare this issue

Refinement

• [ ] Ticket has user story, description, tasks, and acceptance criteria
• [ ] Ticket has been sized
• [ ] Once all above items are checked, add the 'Ready' label.

  Planning

  If this ticket is picked up from the Backlog mid-sprint, connect with Shira to ensure the below items are completed correctly

• [ ] Ticket has been discussed as a team at Planning
• [ ] Ticket has been assigned to appropriate initiative or quarterly epic
• [ ] Ticket has been assigned to a Sprint
• [ ] Ticket has been moved to the Planned pipeline in the Governance team board
• [ ] Ticket as an assignee and peer reviewer

[caw310]

Please add your planning poker estimate with Zenhub @rsmithadhoc

[rsmithadhoc]

@briandeconinck Awesome work on the overview page. I reviewed Overview of accessibility testing coverage and tools and marked what I currently do for DST, what I believe should be added to DST, and then others that I'm not sure about. Just documenting that here.

• Checks that are done now by DST

  • Desktop screen readers
    • JAWS with Chrome
    • NVDA with Firefox
    • VoiceOver with Safari
  • Valid semantic HTML and ARIA
  • Cognitive load, particularly readability, predictability, and content structure
  • Color contrast
  • Use of color to communicate information
  • Mouse compatibility
  • Click target size
  • Keyboard compatibility

• Add to testing

  • Text resize compatibility - I have not been checking this every time. Previously, this didn't work on VA.gov because the root font size was an absolute pixel value. But now that DST has changed that to a relative size, this should be checked with each component.
  • TalkBack with Chrome (mobile) - I have an Android device and I can test this.
  • Voice Command - I have access to Mac, Windows, and Android's built-in options.

• Unsure - discuss

  • Windows Narrator - We may want to add this since it is the default option on Windows. My concern here is if we have done everything correctly, but only Narrator has issues with it, what do we do then? I haven't used it enough to know how well it performs.
  • VoiceOver with Safari (mobile) - I do not have an Apple iOS device to test with.
  • Screen magnifier - If we have done everything else well, will this yield any significant issues? I think the main thing to look for are any alerts that appear and make sure they are close to the area of focus.

Can you let me know your thoughts, specifically on the unsure section? Or if I missed anything from your document. If you prefer to hop on a call and discuss, I can do so as well. Thanks!

[rsmithadhoc]

@briandeconinck I also started a draft PR for the docs page itself. I can take the lead on filling everything out, but not opposed to any inline comments with your thoughts or pushes to that branch. It's still an incomplete rough draft, so I'll be pushing regular changes to that. Thanks!

We also created an issue https://github.com/department-of-veterans-affairs/va.gov-team/issues/87140 for this documentation, so this is just a head start on that.

[briandeconinck]

@rsmithadhoc It's bad form to comment 5 minutes before we meet to talk about stuff, but here I am anyway... Sorry for the delay in replying.

what I currently do for DST, what I believe should be added to DST, and then others that I'm not sure about. Just documenting that here.

This all looks good! On the "unsure" items, we could delineate some of this as:

• Things DST is responsible for
• Things Governance checks for component staging reviews

I'm thinking: You test with a core set of AT (maybe the most-used based on known market share), then I round it out with the others in my review.

Windows Narrator - We may want to add this since it is the default option on Windows. My concern here is if we have done everything correctly, but only Narrator has issues with it, what do we do then? I haven't used it enough to know how well it performs.

I've been thinking about this a lot. My gut reaction right now is that this is a "document and add to the backlog" situation. Identify known issues on specific AT, triage it, and make that known issue public the way USWDS does.

VoiceOver with Safari (mobile) - I do not have an Apple iOS device to test with.

Let's fix that! 😄 Once we have something clearly articulated in the design system, we can make a plan for aligning devices for Ad Hoc a11y folks. In the meantime, I have both iOS and Android devices that I can test with.

Screen magnifier - If we have done everything else well, will this yield any significant issues? I think the main thing to look for are any alerts that appear and make sure they are close to the area of focus.

Probably not going to be an issue for components, more likely to be an issue for VFS products doing weird layout stuff. But I think it might be a good thing to document for the design system anyway, just to demonstrate coverage / get ahead of "if the design system doesn't test for it then why should I?" complaints from VFS teams.

[rsmithadhoc]

@briandeconinck Thanks! Yeah, that all sounds good to me.

For documenting things and adding to the backlog, I like that idea. I think for the testing results, we could have "Pass", "Pass with exceptions", "Fail" to document those things on the component page to make people aware.