Midpoint Review - Accessibility Feedback - Cartographers, MHV on VA.gov, MHV Secondary Navigation

[briandeconinck]

VFS actions

• [ ] 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.
• [ ] Close the ticket when all feedback has been addressed.

Thoughts/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).

• Coding: For both Design A and Design B, I'd recommend they're coded as something like:

  <nav aria-label="MyHealtheVet">
    <ul>
       <li>[link]</li>
       ...
    </ul>
  </nav>

  The key things here are the nav element (exposes it as a landmark for screen reader users) and the aria-label (tells screen reader users what this menu is, distinct from the primary nav). The text in the aria-label doesn't need to be anything fancy, and shouldn't include the word "navigation" since screen readers will announce that as the element type. Something short and sweet like "MyHealtheVet" is sufficient.

• Should: For Design B, the clickable target area for each icon-and-text link should be at least 44px by 44px (regardless of the actual size of the icon). I think it looks okay from the Sketch file but something to verify as it goes to code. 44x44 is the WCAG AAA requirement, which I'd love for us to meet and establish as our norm. If there's a design limitation that requires smaller icons, then there's a weaker AA standard as well.
• Should: For Design B, I don't think the underline on the MyHealtheVet link is necessary. In regular page content, underlining links helps to communicate what they are and distinguish them from other text. That's not an issue in a navigation menu, since there are other visual design choices that communicate what's going on. Since nothing else in either the primary menu or the secondary menu is underlined, underlining just this one link seems more likely to cause user confusion. I think there's space for some other visual treatment (bold text or something) if you want it to stand out, but underlining doesn't seem the way to go to me. (That said, if usability testing comes back with a lot of users confused about whether or not that's a link, then I'm completely wrong and it should be underlined!)
• Consider: No specific recommendation here, but something to be thinking about: With the MyHealtheVet link in the authenticated primary nav, the Home/MyHeatheVet link as the first link in the secondary nav, and (on some child pages) a MyHealtheVet breadcrumb link immediately after the secondary nav, that's a lot of links all going to the same place in close proximity. It probably doesn't matter too much, but for a screen reader user tabbing through links, it might feel a little repetitive to have what feels like wasted tab stops. Even for sighted mouse users, it's a decent amount of screen real estate used redundantly. I think that's something to listen for in usability testing. If no one mentions anything, probably not an issue. But if there are comments about it then my best guess is it's something screen reader users will especially notice and it might be worth some additional design exploration.

• Should: For Design B at a small width, when you abbreviate the link text be sure to keep an aria-label on the link that includes the full text -- eg. <a href="..." aria-label="Appointments">Appts</a>. This keeps the links intelligible for screen reader users, who won't benefit much from the visual abbreviations.

  Note that this does create a mismatch between the visual presentation of the links and the accessible names of the links. The biggest impact here could be on voice command or dictation software users, who may see "Meds" and say "Click Meds" but not get a successful match because the accessible name of the link is "Medications." On balance I think it's fine, if Design B ends up the preferred design. It's a narrow enough use case and the abbreviations are straightforward enough (for English speakers, anyway) that it's not a huge barrier. But it's a potential barrier to be aware of.

[wesrowe]

Closing post-staging review.