Identify descriptive tags (fka tertiary information) for each standard and applicable labels

[shiragoodman]

User Story

As a Governance team member, I want to identify all of the "tertiary" level information that could provide additional context to each standard so that OCTO can track more nuanced information related to the standards violations.

Assignee: @erinrwhite Peer Reviewer: @allison0034

Description

The new VA.gov Experience Standards are not as specific and/or as detailed as the older version. They are written to communicate to the VFS team what the problem is that the user/veteran is experiencing. However, there is still more specific and detailed information that Governance team wants to capture. We have been referring to this information as tertiary information as it comes after the primary information (category) and the secondary information (standard). The purpose of this ticket is to identify the different types of tertiary information that should be captured in a VFS team Staging Review when a standards violation is identified.

In addition, this ticket will identify the relationship the tertiary information has with the standards violation. For example, when a staging review findings ticket impacts a Design System component, it is for 1 and only 1 DS component. However, if another Staging Review findings ticket impacts WCAG success criteria, it is possible that the standards violation could map to 1 to many different WCAG success criteria.

Tertiary information captured so far:

• [x] Design System component and/or pattern (1:1)
  • Note: DST already has github labels for all components in the vets-design-system-documentation repo. All component labels begin with "va-". Governance should replicate these labels for the va.gov-team repo.
• [x] WCAG success criteria (1:n)
• [x] Context (footer, url, header, etc.) (1:n)
• [x] Content Style Guide (1:n)
• [x] Devices (1:n)

Impacted Artifacts

Tasks

• [x] Create a new tab in our VA.gov Experience Standard tracking spreadsheet
• [x] Document the tertiary info title/heading (for example: DST component or pattern)
• [x] Document the tertiary info data/labels (for example, one of the DST component or pattern labels is va-accordion)
• [ ] For tertiary info that do not already have easily mapped data (such as Context), we will need to define what the data/labels are
• [ ] Identify if there is any other tertiary info titles/headings that we have no yet captured

Peer Review

To be completed by peer reviewer

• [ ] User story and acceptance criteria are met

Acceptance Criteria

• [ ] We have identified and captured the tertiary information at the title/heading level
• [ ] We have identified and captured the tertiary information at the data/label level

Team Notification

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

How to prepare this issue

Refinement

• [x] Ticket has user story, description, tasks, and acceptance criteria
• [x] Ticket has been sized
• [x] 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

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

[briandeconinck]

@erinrwhite In case you don't get to this until I'm already out of office, here's a spreadsheet with some proposed labels for WCAG and for what I'm calling interaction modality, which is my arbitrary broadening of devices to include some stuff that's not strictly speaking a device.

[shiragoodman]

thank you for sharing this, @briandeconinck !

[erinrwhite]

@briandeconinck thank you so much for these! I'm generating reference link for the WCAG tags. Confirming, should I reference WCAG 2.2 documentation or an earlier version?

[briandeconinck]

For now you should use the 2.1 documentation. 2.2 is still not officially adopted by the W3C, and then once it's the standard we'll have to work through adopting it for Platform.

I'll note that everything should be the same between 2.1 and 2.2 except for the items I noted in the spreadsheet.

[erinrwhite]

@briandeconinck Thank you! Should we keep the items that are new in 2.2 or add those in down the line?

[shiragoodman]

I'd recommend waiting. There's a lot we'll need to do when 2.2 is enforced across the VA. No need to make the effort now.

[erinrwhite]

@it-harrison Can you take a look at the suggested descriptive tags I have so far?

[erinrwhite]

@briandeconinck @allison0034 Sharing suggested descriptive tags with you before Brian heads out on leave - thank you again Brian for the list of WCAG and modality tags.

Big questions:

• Are there any broad categories of information missing? Are we in the ballpark?
• Do you have suggested reference links for the modality and/or context tags?
• Anything glaringly unusual or confusing that should be addressed?

cc @shiragoodman @it-harrison

thanks team!

[shiragoodman]

@erinrwhite this looks AWESOME. Thank you so much for putting in the time and effort. I think this will be well received by OCTO practice area leads.

• Are there any broad categories of information missing? Are we in the ballpark?
  • I think this is a great first draft. If there are any "types" missing, we can always add on later.
• Do you have suggested reference links for the modality and/or context tags?
  • (thinking from the perspective of how these "reference links" will be communicated back to the VFS team in their Staging Review issue ticket) if we don't have suggested reference links, and if the design system doesn't already cover and/or define what the modality and/or context are, then maybe in place of links we could just use the "notes" as definitions. We're relying on the links to communicate the definition and/or more information, but if we don't have them, then maybe we just fill in the blanks ourselves?
• Anything glaringly unusual or confusing that should be addressed?
  • the only thing that comes to mind is that there may already be labels in github for some of the modality tags that are being used by other a11y specialists. If so, we may want to reach out to the a11y community of practice and let them know of our new tags so they're aware. They can choose to align to our tags if they'd like to. We can consult with Martha.

[allison0034]

@shiragoodman @erinrwhite these look good. I assume as we do reviews we will discover we need to add more tertiary labels. That wont be a problem correct? I specifically think there will be some around design principals.

[shiragoodman]

@allison0034 correct. We can always add more later, but I think this is good enough for now :)

[erinrwhite]

Based on team discussion yesterday it sounds like we are set to close this ticket and ship these labels as-is, understanding that there will be refinements down the road. 👍🏻