Staging Review finding: Abbreviated link text difficult to understand for screen reader users

[shiragoodman]

Need help? Please review how to read a Staging Review ticket. Tag @platform-governance-team-members on Slack if you need further assistance.

Product Information

Team: Cartographers Product: MHV on VA.gov Feature: MHV Secondary Nav

Findings details

VA.gov Experience Standard - issue: User can't perceive an element. VA.gov Experience Standard - category: Comprehension Launch-blocking: No Design System review: No Collab Cycle Reviewer: @briandeconinck (Accessibility)

Description

On small screens and at high zoom, the Appointments and Medications links are shortened to "Appts" and "Meds." To provide intelligible link text to screen reader users, those shortened versions are presented using the abbr element, eg:

<span class="mhv-u-sec-nav-short-title ">
        <abbr title="Appointments">Appts</abbr>
</span>

However, the expanded "Appointments" does not read out consistently on all screen readers, and "Appts" isn't very easy to recognize for what it's supposed to mean. Adrian Roselli has a good exploration of the abbr element and its lack of support across screen readers. His conclusion is:

Don’t use with or without title. Exposure continues to be inconsistent across browsers and assistive technologies. Some set of users will always miss some piece of information.

Recommended action

One challenge here is that we have to support two different assistive technology interaction models. Screen reader users need to hear something that they can recognize and understand, and voice command software users need to see something that they can say out loud ("Click [link text]") that will be matched to the right element. Using an aria-label ensures something intelligible is announced to screen reader users, but when an aria-label doesn't match the visible text, that typically breaks the voice command matching.

Thinking about those different assistive tech interactions, here's what I'm going to recommend:

• For Appointments, remove the abbr use an aria-label on the containing a link:

  <a href="/my-health/appointments" data-dd-action-name="MHV Secondary Nav - Appointments" class="vads-u-text-decoration--none" aria-label="Appointments">
  <va-icon icon="calendar_today" size="3" class="hydrated"></va-icon>
  <span class="mhv-u-sec-nav-item-title ">Appointments</span>
  <span class="mhv-u-sec-nav-short-title ">Appts</span>
  </a>

• For all of the other links (including Medications), remove the abbr and don't provide any alternative for screen reader users, eg.

  <a href="/my-health/medications/about" data-dd-action-name="MHV Secondary Nav - Medications" class="vads-u-text-decoration--none">
  <va-icon icon="medication" size="3" class="hydrated"></va-icon>
  <span class="mhv-u-sec-nav-item-title ">Medications</span>
  <span class="mhv-u-sec-nav-short-title ">Meds</span>
  </a>

The thought process behind this recommendation:

• Messages and Records can both display the full link text up to 400% zoom, so nothing special has to happen here.
• Medications shortens to Meds, which is both pronounceable and a common spoken shorthand for the word. When a screen reader user hears "Meds," they're likely to know what that's supposed to mean. When a sighted voice command user sees "Meds," they can say "Click Meds" without any issue.
• Appointments shortens to Appts, which is both hard to pronounce and not something people commonly say. Screen reader users might recognize Appts as meaning Appointments, but it's more for them to try to parse out. When a sighted voice command user sees Appts, my guess is they're more likely to correctly parse the word and say "Appointments" than they are to successfully say "Appts" in a way that their software will recognize. Voice command software typically has other ways of selecting a link as a fallback if a user doesn't discover that Appointments works.

But note that the Section 508 Office might have a different take on this when you submit your audit.

References

• Accessibility Defect Severity: 2: High. Should be fixed in 1-2 sprints post-launch.
• WCAG Success Criteria: N/A
• Modality: Screen reader
• Design System Component: N/A
• Design System Pattern or Template: N/A
• Design System Foundation: N/A
• Content Style Guide: N/A
• Context: N/A

---

Next Steps for the VFS Team

• [ ] Questions? For the most timely response, comment on Slack in your team channel tagging @platform-governance-team-members with any questions or to get help validating the issue.
• [ ] Ticket ownership: If you believe that this issue is out of scope, not your team's responsibility, or a Design System issue, comment and tag @platform-governance-team-members on your team channel in Slack to provide an explanation and who you believe is responsible. The Governance team will follow up.
• [ ] Close this ticket when the issue has been resolved or validated by your Product Owner.

Cartographers ACs

• Implement recommendations above
• A11y review
• QA review

[brea11y]

I agree with the recommended updates and would move forward with these changes.

[allanto-ah]

Environment: Staging

Verified using VoiceOver on macOS and Narrator on Windows that "Appts" will be read as "Appointments" and "Meds" as "Meds"