Design Intent - Accessibility Feedback - BAH-MBS-SelfServ, Medallions Self-Service, Medallions 1330m Digitization and Integration to CaMEO

[briandeconinck]

Next Steps for the VFS team

• [x] 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 the delayed feedback, and thank you for your patience!
• I am very excited to see this multiple signer pattern in action! Thank you for moving this forward!

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] Must: When using the minimal header, avoid duplication between the text in the header and the H1 on each page of the form flow. The minimal header was originally intended to streamline a form flow by putting the name of the form in the header banner and then use unique H1s to describe the purpose of each page in the flow. You don't necessarily have to follow that model, but you don't get a lot of benefit from having a duplicative H1.
• [x] Should: In the Review and Sign workflow, the name of the form should reflect what it is, not what the user is doing. When you land on the Review and Sign form, you don't have a lot of immediate context for what the purpose of the form is.
• [x] Should: When starting the Review and Sign workflow, the content as written now references the VA form number but never explains what that form is. Try to maintain plain language here.
• [x] Consider: When a user starts the Review and Sign workflow, they may not already have a VA.gov account. I think it would be worthwhile to specifically call that out --- eg. "If you don't already have an account, you'll need to create one" --- and give a rough estimate for how long it will take to create an account. Users in general, but especially users with disabilities, sometimes need to be mindful of how long a process might take and what kind of commitment they're making when they start a process. Giving some heads up about what's involved would be helpful.
• [x] Should: There are a few pages in the workflow where I think it would be appropriate to move some of it onto another page --- eg. recipient delivery address and contact details could be two pages, one for delivery address and one for contact details. I think a safe rule here is, if you've got two headings on a page to section out the content, you can probably break it into two pages. See the one thing per page guidance in the design system for a longer discussion.

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

[carly-yamrus]

@briandeconinck I have updated the mockups with these suggestions. I am still working with Jeana on the H1 headings/minimal header for the second form, but will bring that up for discussion at our next review.