WCAG 2.4.4: Länksyfte (i kontext)

Vad denna regel innebär

WCAG 2.4.4 — Länksyfte (i kontext) — är ett framgångskriterium på nivå A under principen Hanterbar (Operable). Det anger att syftet med varje länk måste kunna fastställas utifrån enbart länktexten, eller utifrån länktexten i kombination med dess programmerbart bestämda länkkontext. Om inget av detta är tillräckligt misslyckas länken med detta kriterium.

Uttrycket "programmatically determined link context" är noggrant definierat av WCAG. Det avser information som kan härledas från samma mening, stycke, listelement eller tabellcell som länken, eller från rubriken som föregår en sektion som innehåller länken. Det inkluderar också kontext som exponeras genom ARIA-relationer såsom aria-labelledby eller aria-describedby. Avgörande är att denna kontext måste vara programmerbart tillgänglig — vilket innebär att hjälpmedelstekniker kan läsa den automatiskt — inte bara visuellt antydd för seende användare.

I praktiska termer påverkas följande HTML-element och attribut direkt av detta kriterium: <a href>-ankarelement, <area>-element i bildkartor, <button>-element som triggar navigation, element som har stylats eller skriptats att bete sig som länkar med ARIA-roller såsom role='link', samt SVG-<a>-element. Länkens tillgängliga namn — beräknat utifrån dess innertext, aria-label, aria-labelledby eller ett alt-attribut på en underordnad bild — är det primära medlet för att kommunicera syftet.

Vad som räknas som godkänt: En länk är godkänd om en användare kan avgöra dess destination eller funktion utan ytterligare kontext (t.ex. "Ladda ner årsrapporten 2024 som PDF"), eller om den omgivande programmerbara kontexten gör syftet tydligt (t.ex. en "Läs mer"-länk inuti ett <li> som börjar med artikelns titel). Länktexten behöver inte vara globalt unik på hela sidan; den behöver bara vara entydig inom sin kontext.

Vad som räknas som underkänt: Generisk länktext såsom "click here", "read more", "here", "more" eller "link" underkänns när den omgivande programmerbara kontexten inte gör destinationen tydlig. En bildlänk med ett saknat eller tomt alt-attribut underkänns också eftersom det tillgängliga namnet helt saknas.

Officiellt undantag: WCAG erkänner ett undantag. När länksyftet avsiktligt är tvetydigt — vilket innebär att om syftet gjordes känt i förväg skulle det förstöra dess användbarhet eller den omgivande innehållets — gäller inte kriteriet. Detta undantag är mycket snävt och sällan tillämpligt i verkliga scenarier.

Varför det är viktigt

Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor världen över någon form av synnedsättning. Bland dem drabbas blinda användare som förlitar sig på skärmläsare mest akut av tvetydig länktext. Skärmläsarprogramvara såsom NVDA, JAWS och VoiceOver låter användare navigera på en sida genom att generera en lista över alla länkar som extraherats från sin kontext. När den listan innehåller dussintals poster som alla läses upp som "read more" eller "click here" kan blinda användare inte avgöra vilken länk som leder vart utan att gå tillbaka till varje länk och läsa det omgivande innehållet — en tidskrävande och desorienterande process.

Användare med motoriska funktionsnedsättningar som navigerar med enbart tangentbord, switchkontroller eller ögonstyrningsenheter har också stor nytta. Dessa användare tabbar ofta sekventiellt genom interaktiva element och förlitar sig på den fokuserade komponentens etikett för att avgöra om de ska aktivera den. Tvetydig länktext tvingar fram extra navigationssteg som ökar trötthet och felgrad.

Användare med kognitiva funktionsnedsättningar — inklusive personer med uppmärksamhetsstörningar, minnesnedsättningar eller låg läskunnighet — gynnas av tydlig, beskrivande länktext eftersom den minskar den kognitiva belastning som krävs för att förstå sidans struktur. De behöver inte hålla kontextuell information i arbetsminnet medan de skannar länkar.

Ett konkret scenario från verkligheten: Tänk dig en e-handelssida med produktlistning som visar tio produkter, var och en med en "Buy Now"-knapp och en "Learn More"-länk som ser identiska ut. En blind användare som navigerar i länkslistan hör tio på varandra följande "Learn More" utan någon indikation på vilken produkt varje länk avser. För att köpa rätt produkt måste användaren läsa hela den omgivande kontexten för varje länk — en process som kan ta minuter i stället för sekunder. Med beskrivande länktext såsom "Learn more about the Sony WH-1000XM5 Headphones" tar samma uppgift ett enda navigationssteg.

Utöver tillgänglighet ger beskrivande länktext mätbara SEO-fördelar. Sökmotorers crawlers använder länktext som en signal för att förstå innehållet på den länkade sidan. Beskrivande, nyckelordsrik länktext förbättrar crawlbarhet och indexerbarhet för länkade resurser och bidrar positivt till sökrankningar. Dessutom minskar tydlig länktext avvisningsfrekvens och supportärenden genom att ställa korrekta användarförväntningar innan navigation sker.

Relaterade Axe-core-regler

• link-name: Denna regel kontrollerar att varje <a>-element med ett href-attribut, varje element med role='link' och varje <area>-element har ett icke-tomt tillgängligt namn. Det tillgängliga namnet beräknas via den standardiserade ARIA-beräkningen av tillgängligt namn: innertextinnehåll, aria-label, aria-labelledby eller alt-attributet på ett underordnat <img>. Axe flaggar en överträdelse när det beräknade tillgängliga namnet är tomt, endast blanksteg eller helt saknas. Denna regel fångar den allvarligaste formen av 2.4.4-fel — länkar som är helt utan namn — men den kan inte upptäcka länkar vars namn tekniskt sett finns men är semantiskt meningslösa (t.ex. "click here" eller "read more"), eftersom automatiserade verktyg inte kan avgöra avsikt utifrån generiska strängar.
• duplicate-id-aria: Denna regel kontrollerar att inga två element på sidan delar samma id-attribut när detta id refereras av ett ARIA-attribut såsom aria-labelledby eller aria-describedby. Duplicerade ID:n som används i ARIA-relationer gör att webbläsaren löser referensen på ett oförutsägbart sätt — vanligtvis till det första matchande elementet i DOM-ordning — vilket kan göra att en länks tillgängliga namn beräknas från helt fel element. Om till exempel två länkar båda använder aria-labelledby='product-title' och två element delar det ID:t kan skärmläsare läsa upp fel produktnamn för en eller båda länkarna, vilket direkt bryter mot 2.4.4. Axe flaggar detta som ett kritiskt problem eftersom det resulterande tillgängliga namnet är opålitligt.

Det är viktigt att förstå begränsningarna med automatiserad testning för detta kriterium. Verktyg som axe-core kan verifiera att en länk har ett tillgängligt namn, men de kan inte verifiera att namnet är meningsfullt. En länk med namnet "here" klarar automatiskt regeln link-name eftersom strängen inte är tom. Mänsklig bedömning krävs för att avgöra om generisk länktext bryter mot 2.4.4. Detta gör manuell testning till ett nödvändigt komplement till automatiserad skanning för detta kriterium.

Hur man testar

1. Automatiserad skanning med axe DevTools eller Lighthouse: Installera webbläsartillägget axe DevTools (Chrome eller Firefox) eller kör en Lighthouse-tillgänglighetsgranskning i Chrome DevTools. Kör en fullständig sidskanning och filtrera resultaten för reglerna link-name och duplicate-id-aria. Granska varje flaggat element: bekräfta att det beräknade tillgängliga namnet saknas eller är tomt för link-name-överträdelser, och verifiera att duplicerade ID:n bryter ARIA-etikettreferenser för duplicate-id-aria-överträdelser. Observera att godkända automatiska kontroller inte garanterar fullständig efterlevnad av 2.4.4 — gå vidare till manuella steg.
2. Manuell granskning av länkslista: I NVDA med Firefox, tryck tangentkombinationen Insert+F7 för att öppna dialogrutan Elements List och välj "Links". Granska varje post i listan isolerat, utan visuell kontext. Fråga: kan du avgöra vart varje länk leder enbart utifrån dess text? Upprepa i JAWS med Chrome genom att använda Insert+F7 för att öppna Links List. I VoiceOver med Safari på macOS, tryck Control+Option+U för att öppna Web Item Rotor och välj "Links". Alla länkar vars syfte är tvetydigt i isolering bör granskas mot sin programmerbara kontext.
3. Tangentbordsnavigationstest: Använd endast Tabb-tangenten för att navigera genom alla interaktiva element på sidan. Varje gång fokus hamnar på en länk, läs endast upp den annonserade texten (inte det omgivande visuella innehållet). Om du inte kan avgöra länkens destination utifrån det som annonseras misslyckas länken sannolikt med 2.4.4. Var särskilt uppmärksam på länkar som endast består av ikoner (ikoner för sociala medier, pilar) och bildlänkar.
4. Kontextverifiering: För länkar som förlitar sig på omgivande kontext (t.ex. "Read more" inuti ett listelement), inspektera DOM:en för att bekräfta att den kontextuella texten finns i samma mening, stycke, listelement eller tabellcell som länken. Kontext som endast är visuellt intilliggande men inte programmerbart associerad uppfyller inte kriteriet. Använd webbläsarens DevTools för att inspektera det beräknade tillgänglighetsträdet och bekräfta relationen.
5. Granskning av ARIA-etiketter: Sök i sidans källkod efter alla användningar av aria-labelledby och aria-describedby på länk-element. Verifiera att varje refererat ID finns exakt en gång i dokumentet och att det refererade elementet innehåller den avsedda beskrivande texten. Använd webbläsarens panel för tillgänglighetsträdet (tillgänglig i Chrome DevTools under fliken Accessibility) för att bekräfta det beräknade namnet för varje länk.

Hur man åtgärdar

Endast ikon-länk utan tillgängligt namn — Felaktig

<!-- An icon link with no text and no aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Endast ikon-länk utan tillgängligt namn — Korrekt

<!-- aria-label provides a descriptive accessible name for screen readers -->
<a href='https://twitter.com/accsible' aria-label='Accsible on Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Generiska "Read more"-länkar i en kortlista — Felaktig

<!-- Multiple identical link texts with no distinguishing context -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

Generiska "Read more"-länkar i en kortlista — Korrekt

<!-- Option 1: Visually hidden text appended to the link -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Join us for the annual summit on digital inclusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C has published the updated guidelines.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2: Use aria-label to override the visible text entirely -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

Bildlänk med tomt alt-attribut — Felaktig

<!-- The image has an empty alt, making the link completely unnamed -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

Bildlänk med tomt alt-attribut — Korrekt

<!-- The alt attribute on the image provides the link's accessible name -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — product details' />
</a>

aria-labelledby som refererar till ett duplicerat ID — Felaktig

<!-- Two elements share the same ID; the second link resolves to the wrong label -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

aria-labelledby som refererar till ett duplicerat ID — Korrekt

<!-- Each ID is unique; each link resolves to the correct label -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

Vanliga misstag

• Att använda "click here", "here", "more" eller "read more" som länktext utan något kompletterande tillgängligt namn via aria-label, aria-labelledby eller visuellt dold <span> — dessa strängar är meningslösa när de extraheras från visuell kontext av en skärmläsare.
• Att lägga till ett aria-label på en länk som innehåller annan synlig text utan att säkerställa att etiketten börjar med den synliga textsträngen — detta bryter mot WCAG 2.5.3 (Label in Name) och orsakar förvirring för röststyrningsanvändare som försöker aktivera länken genom att säga dess synliga namn.
• Att sätta alt='' på en bild som är det enda innehållet i en länk, vilket gör länkens beräknade tillgängliga namn tomt och orsakar en link-name-överträdelse — tomt alt är korrekt för dekorativa bilder men inte när bilden är det enda innehållet i ett interaktivt element.
• Att tillämpa aria-hidden='true' på den enda textnoden inuti en länk, vilket tar bort det tillgängliga namnet från tillgänglighetsträdet och lämnar länken utan namn för skärmläsaranvändare.
• Att återanvända samma id-värde på flera element som refereras av aria-labelledby på olika länkar, vilket gör att skärmläsare beräknar fel tillgängligt namn för en eller flera länkar på grund av oförutsägbar ID-upplösning.
• Att kapsla in en hel kortkomponent (rubrik, bild, stycke och knapp) i en enda <a>-tagg, vilket gör att skärmläsare läser upp hela kortinnehållet som länkens tillgängliga namn — en omständlig och desorienterande upplevelse — i stället för att använda en kort, beskrivande etikett.
• Att enbart förlita sig på en CSS-title-attribut-tooltip eller en :hover-pseudoklass för att ge länkkontext — title-attributet exponeras inkonsekvent av skärmläsare och är helt otillgängligt för tangentbordsanvändare som inte kan trigga hover-tillstånd.
• Att använda själva URL:en som länktext (t.ex. <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), vilket är osägbart för skärmläsare och meningslöst för användare med kognitiva funktionsnedsättningar.
• Att generera länk-ID:n eller ARIA-attributvärden dynamiskt med JavaScript-ramverk utan att säkerställa unikhet — React-, Vue- och Angular-komponenter som renderas i listor producerar ofta duplicerade ID:n om inte explicita nyckelstrategier implementeras.
• Att glömma att lägga till focusable='false' på inline-SVG-ikoner inuti länkar i Internet Explorer och äldre Edge-versioner, vilket gör att SVG:n får ett eget tabb-stopp och gör att skärmläsare annonserar SVG:n separat från länktexten, vilket splittrar beräkningen av det tillgängliga namnet.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på digital tillgänglighet i linje med WCAG 2.2. WCAG 2.4.4 Link Purpose (In Context) är ett kriterium på nivå A, vilket innebär att det ingår i den obligatoriska basnivå som alla berörda aktörer måste uppnå.

Cirkuläret gäller en definierad uppsättning aktörstyper inom både offentlig och privat sektor. Offentliga institutioner — inklusive ministerier, statliga myndigheter, kommuner och offentliga universitet — måste uppnå full överensstämmelse med nivå A inom ett år från cirkulärets publicering. Privata aktörer som omfattas av cirkuläret har ett tvåårigt fönster för efterlevnad. Omfattningen i privat sektor är bred och inkluderar uttryckligen e-handelsplattformar, banker och finansiella institutioner, privata sjukhus och vårdgivare, teleoperatörer med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor auktoriserade av ministeriet för nationell utbildning.

För alla dessa aktörer utgör icke-kompatibel länktext en direkt regulatorisk överträdelse. Tänk på en turkisk e-handelsplattform som visar produktlistningssidor med upprepade "Satın Al" (Buy Now) eller "Devamını Oku" (Read More)-länkar utan programmerbar kontext. En blind användare som förlitar sig på TalkBack, NVDA eller VoiceOver skulle inte kunna avgöra vilken produkt varje länk avser, vilket utgör ett misslyckande med 2.4.4 och ett brott mot cirkulärets krav. På samma sätt skulle en offentlig sjukhusportal för tidsbokning som använder navigationslänkar med enbart ikoner utan tillgängliga namn misslyckas både med axe-regeln link-name och cirkulärets mandat.

Efterlevnad av 2.4.4 är inte bara en teknisk checkruta. Cirkuläret signalerar ett bredare statligt åtagande för digital inkludering för Turkiets cirka 8,5 miljoner medborgare med funktionsnedsättning. För aktörer inom tillämpningsområdet är det både en juridisk skyldighet och en sund investering i användbarhet och sökprestanda att proaktivt åtgärda brister i länksyfte — genom standarder i designsystem, utvecklarutbildning och automatiserad CI/CD-skanning. Underlåtenhet att uppfylla kraven inom de föreskrivna tidsramarna kan leda till tillsynsåtgärder från de relevanta tillsynsmyndigheter som utsetts enligt cirkuläret.