[a11y Design Review] Apply for a medallion

[sara-amanda]

[!NOTE] QUICK SUMMARY:

• Review: Figma file
• CAIA Review Date:
• Review Purpose: Preparing for Midpoint
• Reviewed By: @coforma-jamie

Next Steps

[!TIP] DEFINITION OF DONE: Refer to the task list in this ticket, for actionable items.

Description

CAIA A11ys can review the Figma prototype files for desktop and mobile (if available), in order to provide feedback that may help your team successfully improve the accessibility of VA Form 40-1330M, Apply for a medallion in a private cemetery.

Details

CAIA Intake Ticket 85541

Toggle to view intake information about the initiative and desired outcomes

##### Initial Request > We hope to have accessibility and content specialist analyze the work we've conducted so far regarding VA Form 40-1330M, Apply for a medallion in a private cemetery form. In this form, we create a new digital form applying for a medallion to fix to a private headstone or marker. > > We hope to have the content team analyze the content decisions we've made so far, and provide recommendations for further improvements. This includes the entire medallions form, and the two potential solutions we have so far for multiple signatures. You can add comments in the Figma file as needed. > > We hope to have accessibility team members assess the entire medallions form, and provide accessibility recommendations for further improvements. We ask the accessibility team to look over this DocuSign link to test for accessibility for ongoing feedback, [DocuSign link](https://demo.services.docusign.net/webforms-ux/v1.0/forms/4e3fda343cdaa54263be7213ae0026ee). If the accessibility team could prioritize this DocuSign effort, it would be much appreciated.

CAIA CC Ticket 93101

Toggle to view initial accessibility feedback from Design Intent for quick reference

##### Accessibility Feedback > **Must**: When using the [minimal header](https://design.va.gov/components/header/header-minimal), 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. > > **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. > > **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. > > **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. > > **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](https://www.figma.com/design/QIMsAdHJjctTKDM1I34uXV/Medallions---Baseline-Prototype?node-id=1742-49978&t=aRp8Q6bh9PzXhSkr-4) 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](https://design.va.gov/patterns/ask-users-for/a-single-response) in the design system for a longer discussion. >

About the Team

Toggle to view team info

- **Team name**: Memorials Self-Service - **OCTO product owner**: Matt Self - **Product name**: Apply for a medallion in a private cemetery - **Product manager**: Catherine Hughes - **Slack channel**: [#sitewide-content-accessibility-ia](https://join.slack.com/share/enQtNzI1MjcxNzM4MDIxMi0zOWVhNjIyMWVhNDZlMzkzNmMzY2E2MzM1ZDMzYjViYmQ3YzU4OTE3ZTZhMjkzNDI4OTc2MzM3NTJhMWE0NWY2) - Dedicated content writer on your team (if you have one): N/A, UX Team - Dedicated a11y specialist on your team (if you have one): N/A, UX Team

CAIA Assignee(s)

Toggle to view assignee info

@coforma-jamie

Supporting Artifacts

• Prototype: Figma File Ready 10/9/2024
  • Note: This content and design is close to final, but there are a number of outstanding questions for the client. Ref. Comment 10/9/2024

### a11y Tasks
- [x] **CAIA Intake Opened** `6/10/2024`
- [x] Receive Figma Prototype `10/9/2024`
- [x] Create a [Figma Prototype Review Google Doc from Template](https://docs.google.com/document/d/1iWT1OiGsE6GpevBIGDpTHTJCC8FJt5qPYze38scEeSo/edit#heading=h.k9qpiv683iya) `Make copy`
- [ ] **Review of the File** @coforma-jamie
- [ ] **Additional Support** [Review the menu of services with the team](https://github.com/department-of-veterans-affairs/va.gov-team/tree/master/teams/CAIA/accessibility#services-we-offer).
- [ ] **Inquire:** Will there be future research with assistive technology?

### Acceptance Criteria
- [ ] **Complete** Review of the Figma File
- [ ] **Share** the [Figma Prototype Review Google Doc](https://docs.google.com/document/d/1-OrfxmBO06rJtrd-R_K82-FDigOy2qAqqnR3bnu_yA4/edit?tab=t.0) with the team.
- [ ] **Provide feedback prior to Midpoint** (date not present in CC ticket as of 10/9/2024)

## Ticket Updates (CAIA Internal)
- [ ] _Connect to an `Epic` or `Intake` (what body of work is this a part of?)_
- [x] _Label with `Originator/Team` (product team or stakeholder requesting support)_
- [x] _Label date in the `Open Date` field_
- [x] _Label with `Estimate` (level of effort expected for this ticket)_
- [x] _Add `Assignee(s)` name(s) to ticket_ (include Naomi)
- [x] _Add `Assignee(s) name(s) to each task` they will complete via handle tag (if known)_
- [x] _Select a `Priority Level`_
- [x] _Update date in `Last Checked` field_
- [ ] _Label with `Actual` (level of effort it took to complete this ticket)_
- [ ] _Update date in_ `Closed Date`

### Related Tickets
- [ ] #85541
- [ ] https://github.com/department-of-veterans-affairs/vets-design-system-documentation/issues/3253
- [ ] #91309
- [ ] #93101

[sara-amanda]

OCTO Feedback

@artsymartha68 this is a new ticket for the anticipated design review work. Wanting to confirm with you that the priority level should match that of the intake ticket #85541 , which is Medium - please advise if we should adjust. Many thanks!

cc; @coforma-jamie

Note, I plan to remove assignee @artsymartha68 once prioritization is verified. This is since we are in-between meetings and will be working on it this week - for visibility. 😄

[coforma-jamie]

@barron-charles @carly-yamrus - here's the feedback I can provide so far. Ping me here once you've added annotations, and I'll review those and share more feedback! :)

Issue: Button pair should be left-aligned

• Screen: All screens with back / continue buttons, this one for example
• Version: All7
• Experience standard: User encounters consistent, clear design components and patterns
• Description: Back / continue button pairs are centered, but should be left-aligned per the VADS:
• VADS: “At and after the small-screen breakpoint the buttons left align and revert to a natural width”
• Recommendation: Left-align the button group.

Issue: Spell out acronym in link text

• Screen: Presidential Memorial Certificate
• Version: All
• Experience standard: User knows where a button or link leads
• Description:
  • “Presidential Memorial Certificate” is defined as “PMC” in paragraph text. The acronym is used in the link text.
• This could pose an issue for screen reader users, who often TAB through forms to get to the interactive elements quickly (form fields). On this page, the first thing they’ll TAB to is “Learn more about PMCs (opens in a new tab)”. Since “PMC” isn’t defined on any interactive element, they won’t know what “PMC” stands for when they get to this link.
• Recommendation: Don’t use the “PMC” acronym in the link text - “Learn more about Presidential Memorial Certificates (opens in new tab)”

Think about: Prefill message placement

• Screen: Memorial Items recipient contact information
• Version: All
• Experience standard: User experiences predictable interactions with components and patterns
• Description:
  • Generally, we manage focus to the H3 of each screen of a form when someone selects “Continue.” This is so that screen reader and keyboard users can quickly know where they are on pageload and continue filling out the form.
  • On this prefill, a message appears ABOVE the H3:
• The question here is - where should focus start? Should it be on the H3, or the “We’ve prefilled” message? Will screen reader users miss the prefill message if it’s above the H3? If so, will it be confusing for them to get to the First name field and have info pre-filled?
• Recommendation: You might not need to change anything here, but I have a couple of thoughts:
  • Perhaps you switch around the order of the prefill message and the H3 - that way, you keep the standard focus management, and its more likely that a SR user finds it?
  • Or perhaps you put focus on the prefill message instead of the H3? Does that lead to usability issues?

Issue: Fuzzy images on retina displays

• Screen: Any screen with an image, such as Size of medallion
• Version: All
• Experience standard: User encounters components and patterns that meet best practices
• Description: Note how the image looks on my monitor, it’s pretty fuzzy:
• It looks like the images in this form don’t account for retina displays or different browser widths.
• Recommendation: When implementing, you can create images at different sizes, and DPI, and then define them using \<picture> and srcset. Here’s a great guide for how to do this. This is a missing piece of the VADS - if you can implement this and make a pattern out of it, submit it to the design system council! It’d be a huge help to everyone.

[barron-charles]

@coforma-jamie Thank you very much. We'll take a deeper look at these, and make further revisions from your recommendations!