Turn Link Purpose Findings into Accessibility Tickets

Vague link text becomes fixable when the ticket names the repeated label, the destinations it points to, and the context a screen reader user loses in a links list.

Use this guide for audit notes about "Read more", "Click here", empty icon links, linked cards, file-download links, or links that only make sense visually.

Open this link purpose finding in the generator

What to capture from the finding

Visible link text: the exact repeated or vague words, such as Read more, Learn more, Click here, or Download.
Destination difference: the articles, products, documents, actions, or account areas those links open.
Lost context: what is only communicated by visual layout, card placement, icon shape, or nearby heading.
Assistive technology path: links list, rotor, quick navigation, Tab order, or screen reader browse mode.
Risk to the task: wrong document download, wrong article opened, repeated backtracking, or uncertainty before activation.

Ticket structure

Title:
[Severity] Page or component: repeated/vague link text does not identify destination

User impact:
Explain what becomes uncertain when users browse links outside the visual card or paragraph context.

Evidence:
- Page or component:
- Current link text:
- Number of repeated or ambiguous links:
- Different destinations:
- Screen reader or keyboard path:
- Actual announcement:
- Expected announcement:

Likely WCAG references to verify:
- 2.4.4 Link Purpose (In Context), when the purpose is not clear from link text plus programmatic context.
- 2.4.9 Link Purpose (Link Only), when the product target requires understandable links without surrounding context.
- 4.1.2 Name, Role, Value, when an icon, card, or custom link has no useful accessible name.

Acceptance criteria:
- Each affected link has a unique enough accessible name for its destination or action.
- Visible text and accessible name stay consistent; hidden text only adds necessary disambiguation.
- Repeated links are understandable from a screen reader links list or rotor.
- The fix does not create duplicate announcements or hide important visible text from assistive technology.

Paste your link purpose note into the generator when you want this structure drafted from raw audit text.

Example conversion: repeated Read more links

Raw note:
News teaser list has five "Read more" links. They open different articles. NVDA links list only says Read more five times.

Developer ticket:
[Medium] News teaser list: repeated Read more links do not identify article destinations

User impact:
Screen reader users who browse the page links list cannot tell which article each link opens, so they must leave the links list and inspect surrounding content repeatedly.

Evidence:
- Component: news teaser list
- Current link text: Read more
- Affected links: five article teaser links
- Assistive technology path: NVDA links list
- Actual result: each link is announced as "Read more"
- Expected result: each link identifies its article destination, such as "Read more about accessible checkout testing"

Likely WCAG references to verify:
- 2.4.4 Link Purpose (In Context)
- 2.4.9 Link Purpose (Link Only), if the team requires links to be understandable outside surrounding content

Acceptance criteria:
- Every teaser link has a unique accessible name that includes the article title or topic.
- The visible label is not contradicted by the accessible name.
- NVDA links list exposes distinguishable destinations for all article teaser links.
- Keyboard activation still opens the same destination as before.

Example conversion: icon-only account link

Raw note:
Header account icon is an empty link. VoiceOver announces "link" with no name.

Developer ticket:
[High] Header: account icon link has no accessible name

User impact:
Screen reader users cannot identify or confidently activate the account link from the header.

Evidence:
- Component: global header
- Current visual affordance: account/user icon
- Screen reader path: VoiceOver next link navigation
- Actual result: VoiceOver announces "link"
- Expected result: VoiceOver announces a meaningful name such as "Account" or "Sign in"

Likely WCAG references to verify:
- 4.1.2 Name, Role, Value
- 2.4.4 Link Purpose (In Context)

Acceptance criteria:
- The icon link has a stable accessible name that describes the destination or action.
- The name matches the visible state, such as Account, Sign in, or My account.
- Decorative SVG/icon content is hidden from assistive technology if it would duplicate the link name.
- VoiceOver and browser accessibility inspection expose the expected link name.

Better fix directions

Prefer visible specificity: "Read article: Accessible checkout testing" is usually clearer than hiding all context.
Use hidden text sparingly: visually hidden additions are useful for compact cards, but they must not make the accessible name misleading.
Avoid title-only fixes: title attributes are not a reliable primary accessible name or keyboard help mechanism.
Do not rename links only for screen readers: the accessible name should still match the visible purpose so speech-input users are not surprised.
Retest generated card markup: CMS teaser components often repeat the same link pattern across articles, products, downloads, and events.

Paste-ready input for the generator

Link purpose finding:
Page or component:
Current visible link text:
Number of affected links:
Different destinations or actions:
Screen reader or keyboard path:
Actual announcement:
Expected link purpose:
Relevant selector or CMS component:
Retest notes:

Open the accessibility ticket generator and paste this structure with the audit note.