Criteri di successo WCAG · Level A

WCAG 2.4.4: Scopo del collegamento (nel contesto)

WCAG 2.4.4 richiede che lo scopo di ogni link possa essere determinato dal solo testo del link oppure dal testo del link insieme al suo contesto circostante. Questo garantisce che le persone che usano screen reader, le persone che usano solo la tastiera e le persone con disabilità cognitive possano capire dove porta un link senza doverlo seguire.

Cosa Significa Questa Regola

WCAG 2.4.4 — Scopo del collegamento (nel contesto) — è un criterio di successo di Livello A sotto il principio Operabile. Stabilisce che lo scopo di ogni collegamento deve poter essere determinato dal solo testo del collegamento, oppure dal testo del collegamento combinato con il suo contesto del collegamento determinato in modo programmato. Se nessuno dei due è sufficiente, il collegamento non soddisfa questo criterio.

L’espressione "contesto del collegamento determinato in modo programmato" è definita con precisione da WCAG. Si riferisce alle informazioni che possono essere ricavate dalla stessa frase, dallo stesso paragrafo, elemento di elenco o cella di tabella del collegamento, oppure dall’intestazione che precede una sezione contenente il collegamento. Include anche il contesto esposto tramite relazioni ARIA come aria-labelledby o aria-describedby. Fondamentalmente, questo contesto deve essere disponibile in modo programmato — il che significa che le tecnologie assistive possono leggerlo automaticamente — e non semplicemente implicito visivamente per gli utenti vedenti.

In termini pratici, i seguenti elementi e attributi HTML sono direttamente interessati da questo criterio: elementi ancora <a href>, elementi <area> nelle mappe immagine, elementi <button> che attivano la navigazione, elementi stilizzati o scriptati per comportarsi come collegamenti usando ruoli ARIA come role='link', ed elementi SVG <a>. Il nome accessibile del collegamento — calcolato dal testo interno, da aria-label, aria-labelledby o da un attributo alt su un’immagine figlia — è il veicolo principale per comunicare lo scopo.

Cosa è considerato conforme: Un collegamento è conforme se un utente può determinarne la destinazione o la funzione senza contesto aggiuntivo (ad esempio, "Scarica il Rapporto Annuale 2024 in PDF"), oppure se il contesto programmato circostante rende chiaro lo scopo (ad esempio, un collegamento "Leggi di più" all’interno di un <li> che inizia con il titolo dell’articolo). Il testo del collegamento non deve essere univoco a livello globale in tutta la pagina; deve solo essere non ambiguo nel suo contesto.

Cosa è considerato non conforme: Testi di collegamento generici come "clicca qui", "leggi di più", "qui", "altro" o "link" non sono conformi quando il contesto programmato circostante non disambigua la destinazione. Anche un collegamento immagine con un attributo alt mancante o vuoto non è conforme perché il nome accessibile è completamente assente.

Eccezione ufficiale: WCAG riconosce un’eccezione. Quando lo scopo del collegamento è intenzionalmente ambiguo — nel senso che rendere noto lo scopo in anticipo ne distruggerebbe l’utilità o quella del contenuto circostante — il criterio non si applica. Questa eccezione è estremamente ristretta e raramente applicabile in scenari reali.

Perché È Importante

Circa 2,2 miliardi di persone nel mondo hanno qualche forma di disabilità visiva, secondo l’Organizzazione Mondiale della Sanità. Tra queste, gli utenti ciechi che si affidano ai lettori di schermo sono quelli più colpiti da testi di collegamento ambigui. I software di lettura dello schermo come NVDA, JAWS e VoiceOver consentono agli utenti di navigare una pagina generando un elenco di tutti i collegamenti estratti dal loro contesto. Quando quell’elenco contiene decine di voci che dicono tutte "leggi di più" o "clicca qui", gli utenti ciechi non possono determinare quale collegamento porta dove senza tornare su ciascuno e leggere il contenuto circostante — un processo che richiede tempo e che disorienta.

Anche gli utenti con disabilità motorie che navigano usando solo la tastiera, controlli a interruttore o dispositivi di tracciamento oculare ne traggono un beneficio sostanziale. Questi utenti spesso scorrono in sequenza gli elementi interattivi con il tasto Tab e si affidano all’etichetta dell’elemento con focus per decidere se attivarlo. Testi di collegamento ambigui impongono passaggi di navigazione aggiuntivi che aumentano affaticamento e tasso di errore.

Gli utenti con disabilità cognitive — inclusi quelli con disturbi dell’attenzione, deficit di memoria o bassa alfabetizzazione — beneficiano di testi di collegamento chiari e descrittivi perché riducono il carico cognitivo necessario per comprendere la struttura di una pagina. Non devono mantenere le informazioni contestuali nella memoria di lavoro mentre scorrono i collegamenti.

Uno scenario concreto reale: Si consideri una pagina di elenco prodotti di un sito e‑commerce che mostra dieci prodotti, ciascuno con un pulsante "Compra ora" e un collegamento "Scopri di più" resi in modo identico. Un utente cieco che naviga l’elenco dei collegamenti sente dieci istanze consecutive di "Scopri di più" senza alcuna indicazione del prodotto a cui ciascun collegamento si riferisce. Per acquistare il prodotto corretto, deve leggere l’intero contesto circostante per ogni collegamento — un processo che può richiedere minuti anziché secondi. Con un testo di collegamento descrittivo come "Scopri di più sulle cuffie Sony WH-1000XM5", lo stesso compito richiede un solo gesto di navigazione.

Oltre all’accessibilità, testi di collegamento descrittivi forniscono benefici SEO misurabili. I crawler dei motori di ricerca usano il testo di ancoraggio come segnale per comprendere il contenuto della pagina collegata. Testi di collegamento descrittivi e ricchi di parole chiave migliorano la scansionabilità e l’indicizzabilità delle risorse collegate, contribuendo positivamente al posizionamento nei motori di ricerca. Inoltre, testi di collegamento chiari riducono i tassi di rimbalzo e le richieste di supporto impostando aspettative accurate per l’utente prima che avvenga la navigazione.

Regole Axe-core Correlate

  • link-name: Questa regola verifica che ogni elemento <a> con un attributo href, ogni elemento con role='link' e ogni elemento <area> abbia un nome accessibile non vuoto. Il nome accessibile è calcolato tramite il calcolo standard del nome accessibile ARIA: contenuto di testo interno, aria-label, aria-labelledby o l’attributo alt di un <img> figlio. Axe segnala una violazione quando il nome accessibile calcolato è vuoto, composto solo da spazi o completamente assente. Questa regola intercetta la forma più grave di mancata conformità a 2.4.4 — collegamenti completamente senza nome — ma non può rilevare collegamenti i cui nomi sono tecnicamente presenti ma semanticamente privi di significato (ad esempio, "clicca qui" o "leggi di più"), perché gli strumenti automatici non possono determinare l’intento da stringhe generiche.
  • duplicate-id-aria: Questa regola verifica che nessun elemento sulla pagina condivida lo stesso attributo id quando tale id è referenziato da un attributo ARIA come aria-labelledby o aria-describedby. ID duplicati usati nelle relazioni ARIA fanno sì che il browser risolva il riferimento in modo imprevedibile — tipicamente al primo elemento corrispondente nell’ordine DOM — il che può portare a calcolare il nome accessibile di un collegamento a partire dall’elemento sbagliato. Ad esempio, se due collegamenti usano entrambi aria-labelledby='product-title' e due elementi condividono quell’ID, i lettori di schermo possono annunciare il nome del prodotto sbagliato per uno o entrambi i collegamenti, violando direttamente 2.4.4. Axe segnala questo come problema critico perché il nome accessibile risultante non è affidabile.

È importante comprendere i limiti dei test automatizzati per questo criterio. Strumenti come axe-core possono verificare che un collegamento abbia un nome accessibile, ma non possono verificare che il nome sia significativo. Un collegamento chiamato "qui" supera automaticamente la regola link-name perché la stringa non è vuota. È necessario il giudizio umano per valutare se un testo di collegamento generico non soddisfa 2.4.4. Questo rende i test manuali un complemento essenziale alla scansione automatizzata per questo criterio.

Come Testare

  1. Scansione automatizzata con axe DevTools o Lighthouse: Installa l’estensione browser axe DevTools (Chrome o Firefox) oppure esegui un audit di accessibilità Lighthouse in Chrome DevTools. Avvia una scansione dell’intera pagina e filtra i risultati per le regole link-name e duplicate-id-aria. Esamina ogni elemento segnalato: conferma che il nome accessibile calcolato sia assente o vuoto per le violazioni di link-name e verifica che gli ID duplicati stiano interrompendo i riferimenti alle etichette ARIA per le violazioni di duplicate-id-aria. Nota che superare questi controlli automatici non garantisce la piena conformità a 2.4.4 — procedi con i passaggi manuali.
  2. Revisione manuale dell’elenco dei collegamenti: In NVDA con Firefox, premi la combinazione di tasti Insert+F7 per aprire la finestra di dialogo Elements List e seleziona "Links". Esamina ogni voce nell’elenco in isolamento, senza contesto visivo. Chiediti: puoi determinare dove porta ciascun collegamento dal solo testo? Ripeti in JAWS con Chrome usando Insert+F7 per aprire la Links List. In VoiceOver con Safari su macOS, premi Control+Option+U per aprire il Web Item Rotor e seleziona "Links". Qualsiasi collegamento il cui scopo è ambiguo in isolamento dovrebbe essere esaminato rispetto al suo contesto programmato.
  3. Test di navigazione da tastiera: Usando solo il tasto Tab, naviga attraverso tutti gli elementi interattivi sulla pagina. Ogni volta che il focus si posiziona su un collegamento, leggi solo il testo annunciato (non il contenuto visivo circostante). Se non puoi determinare la destinazione del collegamento da ciò che viene annunciato, è probabile che il collegamento non soddisfi 2.4.4. Presta particolare attenzione ai collegamenti composti solo da icone (icone social, pulsanti freccia) e ai collegamenti immagine.
  4. Verifica del contesto: Per i collegamenti che si basano sul contesto circostante (ad esempio, "Leggi di più" all’interno di un elemento di elenco), ispeziona il DOM per confermare che il testo contestuale si trovi nella stessa frase, nello stesso paragrafo, elemento di elenco o cella di tabella del collegamento. Un contesto che è solo visivamente adiacente ma non associato in modo programmato non soddisfa il criterio. Usa gli strumenti di sviluppo del browser per ispezionare l’albero di accessibilità calcolato e confermare la relazione.
  5. Audit delle etichette ARIA: Cerca nel codice sorgente della pagina tutti gli utilizzi di aria-labelledby e aria-describedby sugli elementi di collegamento. Verifica che ogni ID referenziato esista esattamente una volta nel documento e che l’elemento referenziato contenga il testo descrittivo previsto. Usa il pannello dell’albero di accessibilità del browser (disponibile in Chrome DevTools nella scheda Accessibility) per confermare il nome calcolato per ciascun collegamento.

Come Correggere

Collegamento solo icona senza nome accessibile — Non corretto

<!-- 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>

Collegamento solo icona senza nome accessibile — Corretto

<!-- 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>

Collegamenti generici "Read more" in un elenco di card — Non corretto

<!-- 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>

Collegamenti generici "Read more" in un elenco di card — Corretto

<!-- 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>

Collegamento immagine con attributo alt vuoto — Non corretto

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

Collegamento immagine con attributo alt vuoto — Corretto

<!-- 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 che fa riferimento a un ID duplicato — Non corretto

<!-- 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 che fa riferimento a un ID duplicato — Corretto

<!-- 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>

Errori Comuni

  • Usare "clicca qui", "qui", "altro" o "leggi di più" come testo del collegamento senza alcun nome accessibile supplementare tramite aria-label, aria-labelledby o elementi <span> visivamente nascosti — queste stringhe sono prive di significato quando vengono estratte dal contesto visivo da un lettore di schermo.
  • Aggiungere un aria-label a un collegamento che contiene un testo visibile diverso senza assicurarsi che l’etichetta inizi con la stringa di testo visibile — questo viola WCAG 2.5.3 (Label in Name) e causa confusione per gli utenti di comandi vocali che tentano di attivare il collegamento pronunciandone il nome visibile.
  • Impostare alt='' su un’immagine che è l’unico contenuto di un collegamento, rendendo vuoto il nome accessibile calcolato del collegamento e causando una violazione di link-name — un alt vuoto è corretto per le immagini decorative ma non quando l’immagine è l’unico contenuto di un elemento interattivo.
  • Applicare aria-hidden='true' all’unico nodo di testo all’interno di un collegamento, il che rimuove il nome accessibile dall’albero di accessibilità e lascia il collegamento senza nome per gli utenti di lettori di schermo.
  • Riutilizzare lo stesso valore di id su più elementi che sono referenziati da aria-labelledby su collegamenti diversi, causando il calcolo del nome accessibile errato per uno o più collegamenti a causa della risoluzione imprevedibile degli ID.
  • Racchiudere un intero componente card (intestazione, immagine, paragrafo e pulsante) in un singolo tag <a>, il che fa sì che i lettori di schermo leggano l’intero contenuto della card come nome accessibile del collegamento — un’esperienza prolissa e disorientante — invece di usare un’etichetta breve e descrittiva.
  • Fare affidamento esclusivamente su un tooltip dell’attributo CSS title o su una pseudo-classe :hover per fornire il contesto del collegamento — l’attributo title è esposto in modo incoerente dai lettori di schermo ed è completamente inaccessibile agli utenti che usano solo la tastiera e non possono attivare gli stati hover.
  • Usare l’URL stesso come testo del collegamento (ad esempio, <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), che è impronunciabile dai lettori di schermo e privo di significato per gli utenti con disabilità cognitive.
  • Generare ID di collegamento o valori di attributi ARIA in modo dinamico con framework JavaScript senza garantirne l’unicità — componenti React, Vue e Angular renderizzati in elenchi producono frequentemente ID duplicati a meno che non vengano implementate strategie esplicite di keying.
  • Dimenticare di aggiungere focusable='false' alle icone SVG inline all’interno dei collegamenti in Internet Explorer e nelle versioni precedenti di Edge, il che fa sì che l’SVG riceva un proprio stop di tabulazione e che i lettori di schermo annuncino l’SVG separatamente dal testo del collegamento, dividendo il calcolo del nome accessibile.

Relazione con le Normative di Accessibilità della Turchia

La Circolare Presidenziale 2025/10 della Turchia, pubblicata nella Gazzetta Ufficiale n. 32933 il 21 giugno 2025, stabilisce requisiti obbligatori di accessibilità digitale allineati a WCAG 2.2. WCAG 2.4.4 Scopo del collegamento (nel contesto) è un criterio di Livello A, il che significa che rientra nella base obbligatoria che tutte le entità interessate devono raggiungere.

La circolare si applica a un insieme definito di tipologie di entità sia nel settore pubblico che in quello privato. Le istituzioni pubbliche — incluse i ministeri, le agenzie statali, i comuni e le università pubbliche — sono tenute a raggiungere la piena conformità al Livello A entro un anno dalla pubblicazione della circolare. Le entità del settore privato coperte dalla circolare hanno una finestra di conformità di due anni. L’ambito del settore privato è ampio e include esplicitamente piattaforme di e‑commerce, banche e istituzioni finanziarie, ospedali privati e fornitori di servizi sanitari, operatori di telecomunicazioni con 200.000 o più abbonati, agenzie di viaggio, compagnie di trasporto private e scuole private autorizzate dal Ministero dell’Istruzione Nazionale.

Per tutte queste entità, testi di collegamento non conformi rappresentano una violazione normativa diretta. Si consideri una piattaforma di e‑commerce turca che mostra pagine di elenco prodotti con collegamenti ripetuti "Satın Al" (Compra ora) o "Devamını Oku" (Leggi di più) privi di contesto programmato. Un utente cieco che si affida a TalkBack, NVDA o VoiceOver non sarebbe in grado di determinare a quale prodotto si riferisce ciascun collegamento, costituendo una mancata conformità a 2.4.4 e una violazione dei requisiti della circolare. Allo stesso modo, il portale di prenotazione appuntamenti di un ospedale pubblico che utilizza collegamenti di navigazione composti solo da icone senza nomi accessibili non soddisferebbe né la regola link-name di axe né il mandato della circolare.

La conformità a 2.4.4 non è semplicemente una casella tecnica da spuntare. La circolare segnala un più ampio impegno governativo verso l’inclusione digitale per gli circa 8,5 milioni di cittadini turchi con disabilità. Per le entità nell’ambito di applicazione, affrontare in modo proattivo le mancate conformità relative allo scopo dei collegamenti — tramite standard dei design system, formazione degli sviluppatori e scansioni automatizzate nei flussi CI/CD — è sia un obbligo legale sia un investimento sensato in usabilità e prestazioni di ricerca. Il mancato rispetto entro i tempi previsti può comportare azioni regolatorie da parte delle autorità di vigilanza competenti designate dalla circolare.