Midpoint Review - Accessibility Feedback - Benefits Dependent Experience, 21-686c/674, Critical Form Updates

[briandeconinck]

Next Steps for the VFS team

• [ ] Assign this ticket to the team member(s) responsible for addressing feedback provided by Platform.
• [ ] Comment on this ticket:
  • If the Platform reviewer has any Thoughts/Questions that require responses.
  • When Must feedback has been incorporated. As appropriate, link to any other GitHub issues or PRs related to this feedback.
  • When Should/Consider feedback has been incorporated, or if any feedback will not be addressed. As appropriate, link to any other GitHub issues or PRs related to this feedback.
• [ ] Questions? For the most timely response, comment on Slack in your team channel tagging @platform-governance-team-members.
• [ ] Close the ticket when all feedback has been addressed.

Thoughts/questions

• Sorry for getting this to you late! Please ping me in Slack if you have any questions.

Feedback

Practice areas will document their feedback on the VFS-provided artifacts following the Must, Should, and Consider Framework. Platform Governance reviewers may also provide additional notes that don’t comment on the artifacts themselves but are important for implementation (eg. engineering/coding notes).

• [x] Should: For the two options for adding a child, I prefer the option that breaks it into multiple questions over the option that has all of the helper text in the tiles. Both should be accessible (and neither would be flagged as an issue at staging review), but I think breaking things out will probably be better for cognitive load. But as always that should be validated via usability testing.
• [x] Must: There are a few spots where the heading structure is a little ambiguous to me:
  • Spouse's marital history 2 and pages that follow - The heading "Spouse's former marriage" should be describing the inputs on this page, but since the alert heading "We don't usually need to..." interrupts that flow. I think moving the alert above "Spouse's former marriage" solves this without changing the meaning of anything on the page.
  • Spouse's marital history 3 - When multiple spouses are present, the "Spouse's former marriages," former spouse's name, and "New former marriage of the spouse" headings all have the same visual weight. If possible, the former spouse's name and "New former..." headings should be visually identifiable as subsections beneath "Spouse's former marriages." But even if design constraints require they have the same visual weight, make sure they're appropriately nested --- "Spouse's former marriages" as an H3, the others as H4s.
  • Veteran's marital history 3 - Same as above
  • Child additional info - Each accordion's open/close trigger element is also a heading, which means placement of accordions impact the heading structure. I think the easiest option here is to add a couple of extra headings --- either visible on screen or visually hidden but exposed to screen reader users via the sr-only class. I would put a heading "[Child name]'s disability status" above the disability question and "[Child name]'s marriage and pension status" above the last two questions. (Or something like that, I'm definitely not a content expert!) They should be the same heading level as "[Child name]'s place of birth" and should be sufficient to make those sections of the page easy to navigate to for screen reader users.

• [x] Must: There are a couple of places where helper text is probably going to be missed by screen reader users. Options to solve this:

  • Move to the hint text of the relevant input.
  • Put it in an additional info component --- if it doesn't need to be visible on page and is okay collapsing into an additional info, the additional info will be a tab stop that screen reader users will definitely encounter.
  • Include the text in the message-aria-describedby prop (for components that support that prop).
  • Group related inputs in a fieldset and include the helper text in a legend alongside more typical legend text. The helper text can be re-styled to look like plain text, but will be announced to screen reader users when they tab into the first input in the fieldset.

  Potential problem spots I'm looking at:

  • Broken out 2 - The "Children automatically are..." alert
  • Child additional info - "If you select an option..." and "You can submit your supporting documents..."
  • Current marriage - Same as above
  • Child evidence - The "You can upload..." and "Choose the type..." blocks of text
  • Additional information - Same as above
  • School age child info - The block of text at the top of the page
  • School age child address - The "Note" at the top of the page
  • School age child income - The "IMPORTANT" line of text

Governance team actions

• [x] Format feedback as individual tasks (check boxes)
• [x] Assign this ticket to the VFS team member that opened the Slack request
• [x] Add the VFS team product label
• [x] Add the VFS team the feature label (if applicable)
• [x] Add the touchpoint labels
• [x] Add the practice area labels
• [x] Add the Collaboration Cycle initiative milestone
• [x] Add the Collaboration Cycle initiative epic

[ajialeilani]

All feedback implemented to Figma or added to Figma as comments

[ajialeilani]

Feedback has been incorporated info Figma.