Non-descriptive links on the website

[selfthinker]

This issue is from the accessibility audit of the Design System website by DAC in July 2024.

DAC's description

• Page: Password input and Exit a page quickly
• WCAG reference: 2.4.9 Link Purpose (Link Only) (Level AAA)
• Issue ID: DAC_Non_Descriptive_Links_Link_Only_01 and DAC_Non_Descriptive_Links_Link_Only_02

Password input page

There are multiple links on this page that will direct users to the corresponding component/pattern. When viewing the page out of context screen reader users might not understand the full purpose of these links. For example on this page, the links: Text input, Confirm a phone number, Ask users for passwords & Validation; when isolated out of context could be interpreted as controls of the page, instead of the current purpose which is to take users to the relevant component/pattern.

'Exit a page quickly' page

There are two links on this page which are presented to users as ‘Exit this page’. When viewing the page in context these links will make sense to screen reader users as the term ‘component’ is associated with it. However, when viewing the page out of context screen reader users will only encounter the information of ‘Exit this page’ which can be misleading and some users might expect this link to ‘Exit’ the page, whereas it will take them to the ‘Exit this page’ component.

DAC's proposed solution

Password input page: To ensure the purpose of each of the links is clear, include more information within the programmatical link text so when screen reader users are viewing the page out of context they are aware that the links will direct them to components/patterns, instead of them appearing to look like controls on the page.

'Exit a page quickly' page: We suggest including the word ‘component’ within the programmatical link. As a result of this, the link will be conveyed to screen readers as ‘Exit this page component’ when viewing the page out of context.

Additional instances

As this is probably the case on most pages across the website, this work should include checking links on other pages. It might be worth making two different cards for this: One for checking and recording all instances, the other for fixing them.

To save time, it makes sense to audit all the body copy issues together:

• 4010

• 4013

• 4023

• 4024

• 4025

Needed roles

Content designer

### Tasks
- [x] Build process to scan for all instances of link text
- [x] Run scan
- [x] Capture report into single document
- [ ] Review all instances and identify non-descriptive links
- [ ] Decide on actions for each instance
- [ ] Implement actions in PR
- [ ] Review with team
- [ ] Publish
- [ ] Consider adding process to prevent in future

[calvin-lau-sig7]

To detect we can:

• scape all in-page links on a page
• show them, probably as a spreadsheet (link text will be without the context of the paragraph, but it's sort of the point for us)

To assess, we can:

• view them in the spreadsheet and label each link as compliant or not

To resolve, we can:

• include more of the adjacent sentence as the link text, so the link text provides context on why its there
• add some 'descriptive words' (such as "component") to the link to distinguish it from a possible page control
• last resort, separate out the link as a separate sentence or paragraph

[selfthinker]

We talked to DAC about this issue yesterday, asking if the links in the navigation are also affected. They said the context of the page and the section on the website makes it clearer that the navigation will be about components. (Which is technically still "out of context" for this success criterion.) But they also said that they were stricter than usual in our case as otherwise there wouldn't have been many issues.

[selfthinker]

Just for more context, this is what the GOV.UK content guidance says about link text.

[calvin-lau-sig7]

Update for potential squad wrap-up after this cycle:

As of current date, links have been gathered and Accessibility audit squad assessment all the links is expected to be complete by end-cycle in the Accessible content worksheet.

Further work will be needed for:

• content designer to look across all links marked for review
• content designer to write edits to make the links descriptive
• team review of changes
• put edits into a pull request and publish

Remaining work is pretty sizeable and probably be bigger than a small story, as it'd require medium-sized involvement from team members to help review the numerous edits. But this could possibly be done async outside of regular cycle work.