Let users swap in self-explanatory link text
SCR30 is a sufficient technique for link purpose, qualified for one specific offer. You let the user choose between short link text and long link text, and script rewrites the links when they ask. Three details make the difference between a working implementation and a gesture. The control belongs near the start of the page, where somebody who needs it will meet it before they need it. The control's own text has to say what it does, because a button labeled Expand in a page full of links tells nobody anything. And the choice should survive, saved in a cookie or a profile, or the user re-presses it on every page of your site for the rest of their visit. That persistence is W3C's own advice on this technique and it is the part most often dropped. The simpler answer is to write links that describe themselves. Then you need no switch at all.
How we find it in an audit
Reviewers pull the links list, which is how a screen reader user meets links in the first place, and read it with nothing around it. Ten identical Read more entries is the finding. Then, if a control exists, we use it and read the list again to see whether the expanded text can stand on its own. Two checks people forget come next. Whether the control is discoverable early in the page, and whether the preference is still set after a navigation. Automated tools can find duplicate and generic link text, which gets you to the list of candidates and no further.
How affected users experience it
Screen readers offer a list of every link on the page, sorted and stripped of the sentences they sit in, because that is the fastest way to find where to go next. A news page with ten stories fills that list with ten entries. All ten read Read more. There is no way to tell them apart and no way to guess which story each belongs to. The only route left is to read the whole page in order, looking for the one you wanted. The feature that was meant to save time has become the reason it takes longer.
Passes vs. fails
Passes
<button onclick="expandLinkText()">Show full link descriptions</button>
<a href="/news/42" data-long="Read more about the rail strike">Read more</a>
<!-- Better still, write the long version and drop the switch. -->Fails
<a href="/news/42">Read more</a>
<a href="/news/43">Read more</a>
<!-- Ten of these. In a links list they are indistinguishable. -->How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Link has non-empty accessible nameA tool can check this
- Link in context is descriptiveA tool can check this
- Links with identical accessible names and same context serve equivalent purposeA tool finds candidates, you decide
- Link is descriptiveA tool can check this
- Links with identical accessible names have equivalent purposeA tool can check this
Other ways to satisfy this rule
22 guides on this site are filed under 2.4.4 Link Purpose (In Context). W3C lists this one as sufficient for that rule when used for allowing the user to choose short or long link text, so the condition is part of the test rather than a footnote to it.
- ARIA7sufficientBuild clear link names from nearby headings
- ARIA8sufficientFix vague link text with aria-label
- C7sufficientAdd hidden text to clarify short links
- G53sufficientLet the sentence around a link explain it
- G91sufficientWrite link text that states its purpose
- G189sufficientOffer a switch to self-describing link text
This guide is our interpretation of W3C technique SCR30: Using scripts to change the link text. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.