shiragoodman
commented
3 months ago Thanks for this @humancompanion-usds . I have a few questions:
- I noticed you created this initiative in the vets-design-system-documentation repo, not the va.gov-team repo that Governance uses for Sprint work. Is that normally where DST initiative work is written up?
- Seems like the joint part of this is just aligning on what accessibility testing should be done by whom (Governance vs. DST) using which tools. Once that's determined, is there a prioritized list of components DST will be prioritizing for retesting? Or will be rely on previous testing performed by Governance team at DST Staging Reviews?
- Ok so now we've defined DST accessibility role and Governance Accessibility role, and retested the top DST components on web. Am I correct in saying that the next steps for DST would be to get the VADS pages updated with the testing details? And the next step for Governance would be updating our DST SR guidance to ensure all future component testing is performed the same way?
Maybe @caw310, you and I can have a brief discussion to ensure we're on the same page.
caw310
humancompanion-usds
artsymartha68
Description
Original ticket title: Define & document how we test components for accessibility on the Design System team and on the Governance team
The VA Design system must ensure that the components it offers have been thoroughly tested for accessibility in a wide range of assistive technologies. The Design System must document that testing so that VFS team know what has already been covered by the Design System Team and Governance team. The Design System needs a page that describes the level of accessibility testing performed on components. This should detail the tech stack the components are tested with, how often they are tested (change boundary that would cause a new test to be performed), and a sampling of tests performed or a link to a specific testing plan.
@briandeconinck wrote up an excellent overview of our a11y testing and tools. Part of that was recommending the following:
I agree. Thus we're going to start with Design System components.
6/5 note: Don't necessarily want to limit this to screen readers only.
Details
This is a joint initiative between the Design System and Governance teams. What I'd like is for @briandeconinck and @rsmithadhoc to determine between the two of them what the gaps are between the goal above and what we do today. Once that is documented (can be an update to Brian's Confluence doc or a comment in this issue), please create a plan for closing that gap. That may include, but is not limited to, a plan to obtain devices or software and a clear delineation of tasks between Brian and Ryan (plus the engineers on the Design System team). To be clear, I believe covering 6 different tech stacks for all tests is likely too much for just Brian to do. Thus I'd like Ryan and the Design System Team to commit to taking on some of that work and for both teams to define and document who is doing what and when. This will mean an update to the current Staging review process for Design System components.
The majority of this initiative is focused on defining the testing we want to be doing for both VA.gov and the mobile application (the former can come first). As we define that if we also are able to note where we think our testing may have been deficient, a remediation plan would be an excellent addition as our next task will likely be re-testing some of our more troublesome components and/or re-testing our most common components on tech stacks that we have not previously been able to test on. This will be necessary to make our revised standard true across the components in the system.
Tasks
Acceptance Criteria