Accessibility Feedback - Midpoint Review - DGIB, 1990 Form Updates for MGIB

[joshkimux]

VFS acceptance criteria

• [ ] Let Platform know when the Must feedback has been incorporated
• [ ] Leave any comments for feedback you decide not to take
• [ ] VFS team closes the ticket

Feedback for https://github.com/department-of-veterans-affairs/va.gov-team/issues/34780

Note: @rlyons89 apologies for the late feedback on a holiday as I just returned from a 2 week break-- I'm posting all possible feedback below knowing that many of these points may be out of context or scope having missed prior conversations. Do let me know what does (or does not) apply and I'm happy to edit this accordingly ✌️

Feedback

• Must = the feedback must be applied
• Should = the feedback is best practice
• Consider = suggestions/enhancements

Must

• For effective date "Chapter 30", duplicate "learn more" buttons within the radios will likely cause accessibility defects and will require additional testing/engineering work. If possible, I would recommend to explore simpler patterns. More than happy to talk about what that might look like 🙇

Should

• For the bolded "you cannot change your decision...", given that it is critical information, it may be worth planning for / redesigning the experience to account for screen reader users specifically. For example, visually placing it as hint text below the label (and semantically within the <label>).
• For "Chapter 1606"... "Montgomery GI Bill..." is styled as a heading for visual rather than semantic effect (in this instance). It may be worth exploring alternative ways of designing this to visually and semantically communicate importance. For example, using a single card with an alert icon and alt text.
• For contact information page 1/3, "go to our profile" link should include purpose. For example, writing the link within the note as "Note: you can update your contact information [purpose] on your profile [target] for other VA benefits."
• "Download your certificate of eligibility..." should be styled as a download link, not a button. If the link below ( "Certificate of Eligibility") has the same behavior, it should have the same link text that includes purpose [download your] and target [certificate of eligibility].
• Review links on the conclusion page for purpose and target. For example, figure out your career path with CareerScope is more descriptive as a link compared to CareerScope. For screen reader users who navigate solely using links (through the link list), having purpose and target included is valuable.
• When using alerts, make sure the alerts are presented in a context that makes them actionable for screen reader users. Two examples discussed in the Midpoint Review meeting:
  1. On the application instructions page, the informational alert ("Note: Since you're signed into your account...") should be after the heading "Begin your application..."rather than before it. Screen reader users often skip to a particular heading and then read the content that follows the heading --- so relevant information should appear after the heading rather than before it.
  2. On "Step 3 of 5: Contact Information" the informational alert ("If you choose to get text message notifications...") should appear before the radio inputs rather than after, so screen reader users are prompted with this information before making their selection. Best placement would be after the "We recommend..." paragraph and before the "Would you like to receive..." question.

Consider

• Reviewing inclusive research strategies, specifically how might we include underserved communities into our qualitative measures (for example, people with disabilities / who use assistive technology)?
• The headings on the authenticated application instructions page may be redundant. Specifically the h3 "Start your application and the h2 begin your application for education benefits. I'll defer to the IA/content team here!
• Instead of asking users to confirm their email address in two separate text fields (which can cause barriers to folks with dyslexia or other cognitive disabilities), it may be easier to ask for it once with a email holding a confirmation link. Alternatively, if you can prefill their email address, it may be unnecessary to have two fields. @rtwell and I have provided feedback similar to this in the past.

Design to development recommendations

• For "step 2 of 5, choose the benefit..." page, use aria-describedby to link the chapter titles to their respective headings for screen reader users who may jump to different sections using a headings list.
• Ensure alt text is included for icons that convey meaning. For example, an sr-only text (e.g. <span class="sr-only">Alert</span> can be used to provide meaningful text to the warning (!) icon next to "You are not eligible for this benefit."
• For effective date "Chapter 30", the alert card with "if you give up..." appears to be dynamically populated post selection of a radio option. In this case, a polite aria-live will be necessary to announce that it has been populated to screen reader users. A less complicated alternative could be to populate an expandable learn more below since it would have a natural tab stop.

Questions

• Does this midpoint review include the how to apply page? If so:
  • Would it be possible to explore alternative patterns to the dynamic "find your education benefits form" wizard? For context-- this pattern is being deprecated by the design system team for accessibility and usability reasons.
  • If the "Go to GI Bill Website" is a link, it should be styled as a link.
  • The links under "Other VA benefits..." should be underlined so folks with colorblindness (specifically on mobile) can still understand they are links.
• For "step 2 of 5, choose the benefit..." page, will Veterans understand what the tags within the cards (e.g. tuition and fees, money for housing, etc) mean/refer to?
• For Contact information 3/3, what if a Veteran does not have a mobile number? Would the notification section not populate?
• For the truncated application, is "restart your VA benefits application..." a button (doing something) or a link (going somewhere)? If it's a button, it should be styled as a button.

[briandeconinck]

Updated the issue to include the feedback on alert placement shared by me and @noahgelman this morning.