VA.gov Experience Standard - issue:User can't identify an element or its state.VA.gov Experience Standard - category:UsabilityLaunch-blocking: No
Design System review: No
Collab Cycle Reviewer: @briandeconinck (Accessibility)
Description
On /medications/, each card has an H3 that's also a link, eg.
<h3 aria-describedby="status status-description fill-or-refill-button" class="vads-u-font-weight--bold" id="card-header-22362089">
<a data-dd-action-name="Medication Name Link In Card - List Page" data-testid="medications-history-details-link" class="vads-u-margin-y--0p5 vads-u-font-size--h4" href="/my-health/medications/prescription/22362089">ACEBUTOLOL CAPSULES 200MG</a>
</h3>
In general, accessibility challenges emerge when a single element is serving more than one semantic role, as the heading-links are here.
Screen reader users often navigate via heading, eg. having their screen reader announce all of the headings on the page, or jumping heading-to-heading as they explore the page. I think most screen readers should announce the heading as a link as well when navigating in this way, but it's a different mental model than what most screen reader users have. The heading navigates them to that chunk of content and that chunk of content may contain interactive elements --- but the heading itself isn't expected to be interactive.
The actual impact of this is relatively limited, since heading-links are common enough on the web that most screen reader users will probably figure out the card structure after the first or second try. But it would be great to avoid that friction in the first place.
Recommended action
I don't have a specific recommendation here, but I think it's worth looking at alternative ways of organizing the card content so that there's a separate link to the details page. Check to see what screen reader users said about the card structure during user research, as that may either validate the existing approach or point you in a better direction.
[ ] 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.
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: MHV-Medications Product: MHV Medications Feature: Medications
Findings details
VA.gov Experience Standard - issue: User can't identify an element or its state. VA.gov Experience Standard - category: Usability Launch-blocking: No Design System review: No Collab Cycle Reviewer: @briandeconinck (Accessibility)
Description
On /medications/, each card has an H3 that's also a link, eg.
In general, accessibility challenges emerge when a single element is serving more than one semantic role, as the heading-links are here.
Screen reader users often navigate via heading, eg. having their screen reader announce all of the headings on the page, or jumping heading-to-heading as they explore the page. I think most screen readers should announce the heading as a link as well when navigating in this way, but it's a different mental model than what most screen reader users have. The heading navigates them to that chunk of content and that chunk of content may contain interactive elements --- but the heading itself isn't expected to be interactive.
The actual impact of this is relatively limited, since heading-links are common enough on the web that most screen reader users will probably figure out the card structure after the first or second try. But it would be great to avoid that friction in the first place.
Recommended action
I don't have a specific recommendation here, but I think it's worth looking at alternative ways of organizing the card content so that there's a separate link to the details page. Check to see what screen reader users said about the card structure during user research, as that may either validate the existing approach or point you in a better direction.
References
Next Steps for the VFS Team
@platform-governance-team-members
with any questions or to get help validating the issue.@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.