Staging Review finding: Unnecessary `aria-label` on Add to Calendar and Directions elements

[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: Appointments Product: Appointments Feature: Appointment Details Redesign

Findings details

VA.gov Experience Standard - issue: User encounters a component or pattern that isn't considered a best practice. VA.gov Experience Standard - category: Consistency Launch-blocking: No Design System review: No Collab Cycle Reviewer: @briandeconinck (Accessibility)

Description

There are two instances on an appointment details page where an aria-label is added to an element but isn't necessary:

• "Add to calendar" button has an aria-label of "Add [date] appointment to your calendar"
• "Directions" link has an aria-label of "Directions to [facility name] opens in a new tab"

We typically add an aria-label to links and buttons in cases where it would be difficult for screen reader users to distinguish between two similar elements. In this case, there's only one "Add to calendar" on the page and one "Directions" on the page, and the purpose of each is clear from context. The aria-label makes each more verbose without any clear benefit.

There's also a trade-off to using aria-label for sighted voice command users. For them, the anticipated interaction pattern goes:

1. Read the visible label "Add to calendar"
2. Say the command "Click Add to calendar"
3. Button is clicked.

But when an aria-label is present, voice command software attempts to match the spoken command ("Add to calendar") to what's in the accessibility tree ("Add [date] appointment to your calendar"). Some voice software is smart enough to recognize that as a close-enough match (eg. Dragon), other software will choke on it because it's not an exact match (eg. Apple Voice Control). There's an alternative path for voice users to interact with elements when an aria-label prevents a match, but if the aria-label isn't necessary then it's usually better to leave it off.

Link, screenshot or steps to recreate

Examples of how these elements are currently coded: ``` Add to calendar ``` and ``` Directions ```

Recommended action

I recommend removing the aria-label from each of these. In a separate ticket Erin discusses adding visible text to warn users that the directions link opens in a new tab and/or opening in the same tag (following design system guidance), which should remove any need for an aria-label there.

References

• Accessibility Defect Severity: 3: Medium. Should be fixed in 1-3 sprints post-launch.
• WCAG Success Criteria: N/A
• Modality: Voice
• 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.

[outerpress]

@ldelacosta I'm good with removing the aria labels as @briandeconinck described. We might want to do the directions link work together with the work described in #88450. I'd keep the "open in a new window" work in the other ticket separate.