In one paragraph
Non-descriptive link text means this check found labels such as click here or read more without additional text inside the link. Prefer concise wording that identifies the destination or purpose. Review the accessible name and programmatic context before calling it a WCAG failure: contextual clarity can satisfy the relevant criterion even when the visible words alone are generic.
Why it matters
Links guide navigation and communicate what to expect next. Descriptive text helps people scan a page, browse an assistive-technology link list, and decide whether the destination is relevant. Google also recommends natural, informative anchor text rather than generic or keyword-stuffed labels.
WCAG 2.4.4 permits link purpose to be understood from the text alone or from programmatically determined context, subject to its exception. A read more link in a properly associated article summary can therefore be different from an unexplained standalone here. The stricter link-only criterion also requires consideration of the actual accessible name, not just two visible words.
Do not dismiss generic labels as universally harmless either. Repeated ambiguous links can force unnecessary exploration and obscure distinctions between destinations. The goal is useful navigation, not merely avoiding an automated phrase match.
How WebAuditOS evaluates this finding
The supplied rule compares trimmed anchor text case-insensitively with a short exact list: click here, here, read more, more, link, and learn more. A match warns informationally; no match passes. Error or unparseable pages are not graded, and the documented fragment or javascript targets are excluded.
It does not evaluate surrounding context or aria-label. Punctuation variants, other generic phrases, non-English equivalents, and runtime-created links can be missed. Visually hidden text inside the anchor changes its text and can satisfy this rule. Empty or image-only link naming belongs to other accessibility checks.
How to fix it
- Review each flagged anchor in its real context. Check destination, visible wording, accessible name, and whether relevant contextual text is programmatically associated. Do not assume a nearby visual heading automatically creates every required relationship.
- Prefer visible descriptive wording when practical. Change Click here to compare plans into a natural linked phrase such as Compare plans. Use words that accurately reflect the destination rather than adding unrelated search keywords.
- For content cards, consider linking the descriptive title itself. Avoid unnecessary duplicate links to the same destination if they create repetitive navigation, while preserving an understandable interaction design.
- If a short repeated visible label must remain, add meaningful accessible context. For example:
<a href="/guides/payroll-exports">Read more<span class="visually-hidden"> about payroll exports</span></a>The class must actually hide content visually without removing it from assistive technology. Use wording appropriate to the real destination and ensure styling does not expose or omit it accidentally.
- If using aria-label, preserve the visible label within the accessible name where needed for voice interaction and label consistency. A useful aria-label can improve naming even though this scanner ignores it; do not remove a good accessible implementation solely to alter a report.
- Fix the shared card or CMS template where the pattern repeats. Ensure the generated title is accurate, correctly escaped, and not excessively long. Translation needs the same attention as the English template.
- Test keyboard navigation, assistive naming, narrow-width layout, and analytics selectors that depend on link text. Verify that the destination still works and that longer labels remain readable.
- Rescan, while separately reviewing generic phrases the limited list misses. Keep human evaluation in the accessibility process; an exact-string pass is not a WCAG conformance statement.
What the fix can break
Longer labels can wrap buttons or disrupt compact card layouts. Prefer clear concise wording, and use a robust accessible-context pattern where the design justifies it rather than squeezing text into an unusable control.
Overriding names with ARIA can remove useful native content from the accessible name. Inspect the actual result instead of assuming more attributes always help.
Link-text analytics and automated tests may need updates. Do not preserve a confusing label indefinitely because a tracking rule depends on it; migrate those dependencies deliberately.
Questions
Is every read more link a WCAG failure?
No. Evaluate its accessible name and programmatically determined context against the relevant criterion. The phrase match alone cannot decide conformance.
Why does the scanner ignore my aria-label?
The supplied rule uses anchor text, not the full accessible-name computation. A warning can reflect that scope limitation.
Should anchor text contain all target keywords?
No. Write natural descriptive wording. Keyword stuffing does not make a link more helpful.
Which related checks help?
Review discernible link names, broken links, and the automation limits guide.