Summary list row actions within summary cards must specify which summary card they're part of

[CharlotteDowns]

This issue is from May 2023 external accessibility audit report.

WCAG Reference:
2.4.4 Link Purpose (In Context) (Level A)
Understanding Link Purpose (In Context) | How to Meet Link Purpose (In Context)

2.4.9 Link Purpose (Link Only) (Level AAA)
Understanding Link Purpose (Link Only) | How to Meet Link Purpose (Link Only)

Issue ID:
DAC_Link_Purpose_02

URLs:
https://govuk-frontend-pr-3503.herokuapp.com/full-page-examples/work-history#/delete

Screen shots

The ‘change’ links have been provided with additional link text to inform users of screen reading assistive technologies that they relate to the different questions i.e., ‘job title’. However, additional context is required to understand their whole purpose as to which section and work they relate to. For example, a user would need to navigate backwards to locate the heading to which they are sectioned under, and as there are multiple ‘change job title’ links, this can be confusing for users.

Current code ref(s)

#main-content > div > div > div:nth-child(3) > div.govuk-summary-card__content > dl > div:nth-child(1) > dd.govuk-summary-list__actions > a

Screen-reader comments

“I located multiple links on the page which read to me as ‘Delete work history’. These links related to different sections of the page and would delete different areas although at the time of testing did not perform a function. I was not aware when browsing out of context that the links would perform a different action or what would be deleted as the links did not contain enough description within the link text to make this obvious. Giving each link text clear and unique information that can be understood either in or out of context will prevent any confusion and will ensure that I can select easily.”

Solution

Ensure that all links are descriptive of their purpose and functionality, allowing users of screen reading assistive technologies to confidently interact and understand the link.
The best way to make sure of this, is to locate links where some additional link context is needed to understand the purpose of the link. For each link:

1. Check whether the context is contained in the same sentence, paragraph, list item, table cell, or associated table headers.
2. Check whether the link context can be programmatically determined in some other way, for example, by using a WAI-ARIA property such as aria-label, aria-labelledby or aria-describedby on the link to provide sufficient context.
   Consider adding additional text including the heading or work section to give a clear purpose for the link.

[dav-idc]

This issue has been assessed to not be a high-severity accessibility concern. It only meets 1 of our 3 criteria for a high-severity accessibility concern.

• There is reasonable evidence that it makes it difficult or impossible for some people to complete certain tasks. ✅
  The evidence:
  • It is related to a WCAG level A failure.
  • It was assessed in an external accessibility audit as a 'high' priority accessibility concern.
• It does not appear to affect the accessibility of essential services or critical infrastructure. ❌
• There is no blocker to individual service teams efficiently resolving it on their own. ❌

As such, this will not be flagged as a high-priority issue.

In the coming weeks we will investigate whether it fails WCAG level A criterion: 2.4.4 Link Purpose (In Context).

[querkmachine]

What is the best fix here?

Is it a case of putting the name of the card before or after the link text or as an aria-label (e.g. "[Undergraduate teaching assistant:] Change [Job title]")?

There was some talk of making cards into <section> elements so that content of each card was more clearly scoped to a heading, but I'm not sure whether that still meets the criterion. It certainly doesn't seem to be a practical solution, as the link is still vague when removed from context (e.g. the VoiceOver rotor's 'links' section).

I'm not sure if there's a solution to hand that doesn't have the potential to be a bit information overload-y, but too much context is always better than too little, I imagine.

[CharlotteDowns]

This has also already been captured in Accessibility issue: duplicate links on example for summary cards