Link accessibili: testo, aria-label, skip navigation

Molti screen reader offrono una scorciatoia: «elencami tutti i link della pagina», estratti fuori dal loro contesto, uno dopo l'altro. Se ogni link dice «clicca qui», quella lista diventa una sfilza di frasi identiche e inutili. Il testo del link è, letteralmente, l'unica informazione che a volte arriva a chi ascolta.

1. Testo descrittivo: il test «fuori contesto»

Il criterio WCAG 2.4.4 Link Purpose (In Context) chiede che lo scopo di un link sia comprensibile dal suo testo, da solo o insieme al contesto immediato. Il test pratico: leggi solo il testo del link, isolato. Se non capisci dove porta, va riscritto.

<!-- Poco chiaro fuori contesto --> 
   <a href="/report-2025.pdf">clicca qui</a> 

<!-- Comprensibile anche isolato --> 
   <a href="/report-2025.pdf">Scarica il report 2025 (PDF)</a>

Fonte: W3C WAI, WCAG 2.4.4 Link Purpose (In Context): definisce il criterio di successo e i casi in cui il contesto immediato può integrare il testo del link. 

2. aria-label: sostituisce, non aggiunge

Quando il testo visibile non può essere cambiato (per motivi di design, o perché è un'icona senza testo), aria-label può fornire un nome accessibile diverso. Ma attenzione a un punto tecnico spesso frainteso: aria-label sostituisce interamente il testo visibile per chi usa uno screen reader, non lo integra.

<a href="/carrello" aria-label="Vai al carrello, 3 articoli"> 
   <svg aria-hidden="true">...</svg> 
</a>

Il criterio WCAG 2.5.3 Label in Name impone una regola precisa quando il link ha già un testo visibile: il nome accessibile deve contenere quel testo. Se il link dice «Invia» ma aria-label="Conferma modulo", chi usa il comando vocale «clicca su Invia» non troverà corrispondenza: il nome accessibile e il testo visibile sono scollegati.

Fonte: W3C WAI, Technique ARIA6 (uso di aria-label) e WCAG 2.5.3 Label in Name: il nome accessibile deve contenere il testo visibile quando questo è presente. 

3. Skip navigation: saltare il menu ripetuto

Chi naviga solo con la tastiera preme Tab per spostarsi tra gli elementi interattivi. Senza un modo per saltarla, ogni singola pagina richiede di attraversare l'intero menu di navigazione prima di raggiungere il contenuto vero e proprio.

<header> 
   <h1>Il Titolo</h1> 
   <a href="#contenuto">Salta al contenuto</a> 
</header> 

<nav> ... link di navigazione ... </nav> 
<section id="contenuto"> ... contenuto della pagina ... </section>

Lo «skip link» è spesso nascosto visivamente e appare solo quando riceve il focus da tastiera: così non disturba chi naviga a mouse, ma resta disponibile a chi ne ha bisogno.

Fonte: MDN Web Docs, «What HTML features promote accessibility?»: uno skip link permette agli utenti da tastiera di saltare velocemente contenuti ripetuti come la navigazione.

4. Focus trap: la tastiera che non riesce più a uscire

Un focus trap è quando il focus della tastiera entra in un componente (spesso un modale) e non riesce più a uscirne. Il criterio WCAG 2.1.2 No Keyboard Trap lo definisce così: se il focus può entrare in un componente con la tastiera, deve poter anche uscirne con la sola tastiera, senza scorciatoie speciali non documentate.

Nota importante: un focus trap voluto (dentro un modale aperto, per esempio) è una pratica corretta, ma deve sempre offrire un'uscita chiara via tastiera, tipicamente con il tasto Esc, e riportare il focus dove si trovava prima dell'apertura.

In sintesi

Il filo conduttore è sempre lo stesso: un link visto nel suo contesto e un link ascoltato fuori contesto devono comunicare la stessa cosa. Scrivere link chiari non è un accorgimento extra: è la differenza tra una pagina navigabile e una che, per una parte dei tuoi utenti, semplicemente non funziona.