WCAG 3.1.3: Parole insolite

Cosa Significa Questa Regola

WCAG 3.1.3 — Parole insolite è un criterio di successo di livello AAA sotto il principio Comprensibile. Richiede che qualsiasi contenuto web che utilizzi parole o frasi in un senso insolito, specializzato o ristretto fornisca un meccanismo che permetta agli utenti di consultare o accedere alle definizioni di tali termini. Questo si applica a tre categorie di uso del linguaggio: gergo (vocabolario specializzato specifico di un mestiere, professione o settore), modi di dire (frasi il cui significato non può essere dedotto dal significato letterale delle parole, come “break a leg” o “hit the ground running”), e parole usate in modo ristretto o insolito (parole comuni alle quali viene attribuito un significato specializzato o non standard in un particolare contesto).

Il criterio non impone un unico approccio di implementazione. Meccanismi accettabili includono definizioni in linea, un glossario collegato dalla pagina, tooltip o definizioni espandibili attivate dall’interazione dell’utente, definizioni fornite nel testo circostante o l’uso dell’elemento HTML <dfn> abbinato a un contesto accessibile. Il requisito chiave è che il meccanismo di definizione deve essere disponibile — gli utenti devono poterlo raggiungere senza sforzi eccessivi.

Si ottiene un superamento quando ogni istanza di gergo, modo di dire o parola usata in modo insolito sulla pagina è accompagnata da un meccanismo di definizione raggiungibile. Si ha un fallimento quando compaiono termini specializzati o ambigui senza alcun meccanismo di questo tipo — ad esempio, un sito legale che utilizza termini come “tortfeasor” o “subrogation” senza un glossario o una spiegazione in linea.

WCAG definisce un’eccezione limitata: se una parola è usata in modo insolito solo all’interno di un passaggio specifico, è sufficiente fornire la definizione per quel passaggio invece che globalmente in tutto il sito. Inoltre, i nomi propri (nomi di persone, luoghi o organizzazioni) in genere non sono soggetti a questo criterio, a meno che nel contesto non fungano anche da termini tecnici.

Perché È Importante

Le barriere alla comprensione del linguaggio colpiscono una gamma sorprendentemente ampia di utenti. Le persone con disabilità cognitive — tra cui dislessia, disabilità intellettive e lesioni cerebrali acquisite — possono avere difficoltà a dedurre il significato dal contesto quando compaiono termini non familiari. Secondo l’Organizzazione Mondiale della Sanità, circa 1 persona su 6 nel mondo vive con qualche forma di disabilità, e i deficit cognitivi rappresentano una delle categorie più grandi. Per questi utenti, imbattersi in gergo non definito può rendere del tutto inutilizzabile una pagina altrimenti accessibile.

Le persone non madrelingua rappresentano un altro grande gruppo interessato da questo criterio. Solo in Turchia, la popolazione include milioni di persone la cui prima lingua è il curdo, l’arabo o un’altra lingua regionale, e che leggono il turco come seconda lingua. Quando un portale sanitario del governo turco utilizza terminologia medica come “anjiyoplasti” o “antikoagülan” senza spiegazione, questi utenti — e persino molti madrelingua turchi — possono non essere in grado di comprendere informazioni sanitarie critiche.

Anche gli utenti di screen reader sono interessati in modo sottile ma significativo. Quando un termine è definito tramite un tooltip visibile o un glossario, gli utenti vedenti possono individuarlo rapidamente. Tuttavia, se quel meccanismo non è accessibile da tastiera e determinabile a livello di codice, gli utenti ciechi che si affidano alle tecnologie assistive potrebbero non raggiungere mai la definizione. Fornire definizioni in linea ben strutturate o un glossario correttamente collegato garantisce parità di accesso.

Si consideri uno scenario concreto: una piattaforma di e-commerce turca vende prodotti finanziari e utilizza il termine “faiz oranı bileşimi” (interesse composto) senza spiegazione. Un utente con disabilità intellettiva, o un utente anziano non familiare con la finanza, che tenta di confrontare prodotti di prestito può prendere una decisione finanziariamente dannosa semplicemente perché la terminologia non è mai stata chiarita. Fornire un glossario collegato o un tooltip accessibile con una definizione in linguaggio semplice mitiga direttamente questo rischio.

Oltre all’accessibilità, questo criterio ha benefici misurabili in termini di usabilità e SEO. Le pagine di glossario indicizzate dai motori di ricerca aumentano l’autorevolezza tematica e possono intercettare traffico di ricerca long-tail. Definizioni chiare riducono anche il carico sull’assistenza clienti, migliorano i tassi di conversione e contribuiscono alla qualità complessiva dei contenuti — tutti risultati rilevanti per gli operatori commerciali.

Regole Axe-core Correlate

WCAG 3.1.3 rientra nella categoria dei criteri che richiedono test manuali. Non esiste una regola automatizzata di axe-core che possa rilevare se le parole insolite sono definite, perché ciò richiederebbe che lo strumento comprenda il significato semantico e il contesto di dominio di ogni parola su una pagina — un compito che va oltre le attuali capacità di analisi automatizzata.

• Valutazione manuale richiesta — Parole insolite: Gli scanner di accessibilità automatizzati come axe-core, Lighthouse e IBM Equal Access Checker non possono identificare quali parole rientrano nel gergo, nei modi di dire o nei termini usati in modo insolito, perché questa determinazione dipende dalla conoscenza del dominio, dal contesto del pubblico e dall’interpretazione linguistica. Uno scanner non può sapere che “token” significa una credenziale di sicurezza in un contesto e un buono in un altro, o che “cloud” si riferisce a infrastruttura di calcolo distribuito piuttosto che al vapore acqueo atmosferico. I revisori umani — idealmente includendo membri del pubblico di destinazione — devono leggere il contenuto e valutare se qualche terminologia richiede una definizione. Il revisore dovrebbe quindi verificare che esista un meccanismo di definizione accessibile per ogni termine segnalato.
• Verifiche automatiche complementari: Sebbene axe-core non possa valutare direttamente questo criterio, i revisori possono utilizzare strumenti automatizzati per verificare che eventuali meccanismi di definizione utilizzati (come elementi <dfn>, tooltip o glossari collegati) siano essi stessi accessibili. Ad esempio, le regole di axe-core che coprono lo scopo dei link (link-name), l’accessibilità da tastiera (tabindex) e l’uso di ARIA (aria-allowed-attr) possono confermare che un link al glossario o un widget di tooltip è implementato correttamente — anche se lo strumento non può giudicare se il glossario è completo.

Come Eseguire i Test

1. Pre-scansione automatizzata: Esegui axe DevTools o Lighthouse sulla pagina per confermare che non vi siano errori di accessibilità di base che potrebbero interferire con i test (link interrotti, indicatori di focus mancanti, ecc.). Prendi nota di eventuali widget interattivi di definizione (tooltip, termini espandibili) segnalati per problemi ARIA o di tastiera. Questi errori secondari possono impedire agli utenti di raggiungere le definizioni anche quando esistono.
2. Audit dei contenuti — identificare i termini insoliti: Leggi attentamente il contenuto della pagina. Segnala ogni istanza di gergo, terminologia tecnica, modo di dire o parola usata in un senso non standard. Aiuta immaginare di spiegare la pagina a un utente senza alcuna esperienza nell’area tematica. Crea un elenco dei termini segnalati prima di verificare le definizioni.
3. Verificare i meccanismi di definizione: Per ogni termine segnalato, conferma che esista un meccanismo di definizione e che sia raggiungibile. Controlla: definizioni in linea nel testo circostante, un elemento <dfn> visibile con <abbr title> associato o descrizione collegata, una pagina di glossario collegata dal contenuto o tooltip/definizioni espandibili. Se il meccanismo è un tooltip o un widget espandibile, procedi al punto 4.
4. Test di navigazione da tastiera: Utilizzando solo la tastiera (Tab, Invio, Barra spaziatrice, tasti freccia), prova a raggiungere e attivare ogni meccanismo di definizione sulla pagina. Verifica che i tooltip o le definizioni espandibili possano essere attivati senza mouse. In Firefox con NVDA, naviga fino ai termini definiti e conferma che la definizione venga annunciata. In Safari con VoiceOver su macOS, usa VO+Freccia destra per scorrere il contenuto e verifica che il contesto della definizione sia disponibile. In Chrome con JAWS, testa che le voci del glossario collegate ricevano il focus e che lo scopo del link sia chiaro.
5. Test dell’ordine di lettura con screen reader: Con NVDA in Firefox, attiva la modalità Browse e leggi la pagina in modo lineare. Conferma che quando compare un termine di gergo, o la definizione viene letta in linea oppure il link/bottone alla definizione è immediatamente adiacente e chiaramente etichettato. Assicurati che all’utente non sia richiesto di abbandonare la pagina e perdere il contesto per accedere a una definizione.
6. Verifica della completezza del glossario: Se il sito utilizza un glossario centralizzato, confronta l’elenco dei termini insoliti segnalati con le voci del glossario. Conferma che ogni termine segnalato abbia una voce corrispondente. Verifica che la pagina del glossario sia essa stessa accessibile (struttura di intestazioni corretta, navigabile da tastiera, leggibile dagli screen reader).

Come Correggere

Gergo tecnico senza definizione — Non corretto

<p>
  The system uses OAuth2 for authorization, issuing a JWT
  that expires after 3600 seconds. Refresh tokens are stored
  in an HttpOnly cookie to mitigate XSS vectors.
</p>

Gergo tecnico con definizioni in linea — Corretto

<!-- Using dfn elements with title attributes and a linked glossary -->
<p>
  The system uses
  <dfn><abbr title='OAuth 2.0: An open authorization protocol that allows
  third-party applications to access user data without exposing
  credentials.'>OAuth2</abbr></dfn>
  for authorization, issuing a
  <dfn><abbr title='JWT (JSON Web Token): A compact, URL-safe token
  format used to transmit claims between parties.'>JWT</abbr></dfn>
  that expires after 3600 seconds. See our
  <a href='/glossary#security-terms'>Security Glossary</a>
  for full definitions.
</p>

Linguaggio idiomatico senza spiegazione — Non corretto

<p>
  Our customer support team will go the extra mile to ensure
  your issue is resolved. We believe in burning the midnight
  oil so you never have to.
</p>

Linguaggio idiomatico riscritto in forma semplice — Corretto

<!-- Plain language replacement is the most robust fix for idioms.
     If idioms must be retained for brand voice, provide a
     parenthetical explanation or tooltip. -->
<p>
  Our customer support team will make every effort to ensure
  your issue is resolved. We work extended hours so you
  receive help whenever you need it.
</p>

Contenuti medici o legali con termini specializzati non definiti — Non corretto

<p>
  Patients diagnosed with dyslipidemia may be prescribed
  statins to manage LDL cholesterol levels and reduce the
  risk of atherosclerosis.
</p>

Contenuti medici con link a glossario accessibili — Corretto

<!-- Each technical term links to the relevant glossary anchor.
     The glossary page contains plain-language definitions. -->
<p>
  Patients diagnosed with
  <a href='/glossary#dyslipidemia'>dyslipidemia</a>
  (abnormal levels of lipids in the blood) may be prescribed
  <a href='/glossary#statins'>statins</a>
  to manage
  <a href='/glossary#ldl'>LDL cholesterol</a>
  levels and reduce the risk of
  <a href='/glossary#atherosclerosis'>atherosclerosis</a>
  (hardening and narrowing of the arteries).
</p>

Parola usata in un senso ristretto o specifico del dominio — Non corretto

<p>
  Submit your token at the kiosk to claim your reward.
  Tokens expire at the end of each session.
</p>

Parola in senso ristretto con definizione contestuale — Corretto

<!-- The first use of the term in the restricted sense is
     marked with dfn and explained. Subsequent uses are clear
     by context. -->
<p>
  Submit your
  <dfn id='def-token'>token</dfn>
  (a single-use digital voucher issued when you complete
  a qualifying purchase) at the kiosk to claim your reward.
  Tokens expire at the end of each session.
</p>

Errori Comuni

• Definire un termine nel glossario ma non collegarlo mai dal contenuto: Un glossario è utile solo se gli utenti sanno che esiste e possono raggiungerlo. Non collegare i termini insoliti alle loro definizioni — o omettere un link al glossario ben visibile nella navigazione — significa che molti utenti non scopriranno mai la risorsa.
• Usare <abbr title='...'> per parole per esteso anziché per abbreviazioni: L’attributo title su <abbr> è comunemente usato in modo improprio come tooltip generico per qualsiasi termine. Gli screen reader gestiscono title in modo incoerente, ed è invisibile agli utenti che usano la tastiera per impostazione predefinita nella maggior parte dei browser. Usa <dfn> con una descrizione collegata accessibile o testo adiacente per le parole per esteso.
• Fornire definizioni in tooltip che non sono accessibili da tastiera: Tooltip solo CSS o JavaScript che si attivano solo al passaggio del mouse escludono completamente gli utenti da tastiera e touch. Qualsiasi tooltip utilizzato per fornire una definizione deve poter essere attivato tramite focus da tastiera e non deve scomparire quando l’utente sposta il focus al suo interno per leggere.
• Dare per scontato che i termini standard del settore non necessitino di definizione per un pubblico generale: Termini come “bandwidth”, “uptime”, “SLA” o “API” possono essere ovvi per i team tecnici ma opachi per il pubblico generale che visita un sito di telecomunicazioni o servizi cloud. Valuta sempre la terminologia dalla prospettiva del membro meno esperto del pubblico di destinazione.
• Definire un termine solo alla sua prima occorrenza in un documento ma non nelle pagine in cui compare senza introduzione precedente: Se un utente entra nel sito da una pagina di articolo profonda collegata dall’esterno che fa riferimento a gergo definito solo in un’altra pagina, non ha accesso alla definizione. Ogni pagina deve essere autosufficiente o fornire una navigazione alla definizione indipendentemente dal punto di ingresso.
• Usare gergo nelle etichette dei moduli, nel testo dei pulsanti o nei messaggi di errore senza definizioni: Parole insolite in elementi UI interattivi — come “Authorize delegated access” su un pulsante, o “Your session token is invalid” in un messaggio di errore — sono particolarmente dannose perché gli utenti devono comprenderle per completare compiti critici. Questi elementi vengono spesso trascurati negli audit dei contenuti.
• Scrivere le definizioni del glossario usando ulteriore gergo: Una voce di glossario che definisce “amortization” come “the systematic allocation of an intangible asset's cost over its useful life” non aiuta un utente non esperto. Le definizioni devono essere esse stesse scritte in linguaggio semplice, accessibile al pubblico di destinazione.
• Ignorare i modi di dire specifici della lingua nei contenuti multilingue o tradotti: Quando i contenuti vengono tradotti dall’inglese al turco (o viceversa), le espressioni idiomatiche vengono spesso tradotte letteralmente, producendo frasi prive di senso o confuse nella lingua di destinazione. Ogni versione localizzata deve essere revisionata da un madrelingua per accuratezza idiomatica e comprensibilità.
• Trattare <dfn> come puramente semantico senza una definizione visibile all’utente: L’elemento HTML <dfn> contrassegna l’istanza in cui un termine viene definito, ma non fornisce di per sé la definizione agli utenti. Deve sempre essere abbinato a testo adiacente, a un’associazione aria-describedby o a una definizione visibile nel paragrafo circostante.
• Omettere parole insolite dalle checklist di audit automatizzate perché nessuna regola di axe le segnala: Poiché questo criterio richiede una valutazione manuale, è facile che venga de-prioritizzato durante gli audit tecnici. I team dovrebbero stabilire un processo di revisione manuale documentato per il linguaggio e la terminologia come fase formale del loro flusso di lavoro QA per l’accessibilità, non come ripensamento.

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à web e mobile allineati a WCAG 2.2 per un’ampia gamma di soggetti pubblici e privati che operano in Turchia. I soggetti coperti includono istituzioni e agenzie pubbliche, piattaforme di e-commerce, banche e istituzioni finanziarie, ospedali e fornitori privati di assistenza sanitaria, società di telecomunicazioni con 200,000 o più abbonati, agenzie di viaggio, società di trasporto privato e scuole private autorizzate dal Ministero dell’Istruzione Nazionale (MoNE).

La circolare impone la conformità a WCAG 2.2 Livello AA come requisito legale di base. WCAG 3.1.3 — Parole insolite è un criterio di Livello AAA e pertanto non è legalmente richiesto ai sensi di questa normativa. Tuttavia, ciò non ne diminuisce l’importanza pratica per le organizzazioni turche. I soggetti che servono popolazioni linguisticamente diverse — inclusi portali di sanità pubblica, piattaforme di istruzione nazionale e società di servizi finanziari — hanno forti incentivi etici e reputazionali a implementare criteri AAA come il 3.1.3.

Per alcuni servizi specializzati, la conformità al Livello AAA può di fatto diventare necessaria. Le istituzioni sanitarie che servono pazienti con livelli variabili di alfabetizzazione sanitaria, le piattaforme educative gestite sotto autorizzazione MoNE che servono studenti con disabilità cognitive e i portali governativi tenuti a comunicare chiaramente con tutti i cittadini trarrebbero un beneficio significativo dall’implementazione di questo criterio. Il quadro dei diritti delle persone con disabilità in Turchia, rafforzato dalla ratifica da parte del Paese della Convenzione ONU sui Diritti delle Persone con Disabilità, stabilisce un mandato più ampio per l’accesso equo all’informazione che i criteri AAA contribuiscono a soddisfare nello spirito anche quando non sono strettamente imposti dalla legge.

Le organizzazioni che cercano di dimostrare un’accessibilità di livello eccellente — sia per vantaggio competitivo, accesso al mercato internazionale, idoneità agli appalti del settore pubblico o autentico impegno per il design inclusivo — dovrebbero trattare WCAG 3.1.3 come parte di un programma di accessibilità completo che va oltre il minimo normativo. Implementare un sistema di glossario strutturato, formare gli autori di contenuti a riconoscere e definire la terminologia insolita e incorporare l’accessibilità linguistica nei flussi di lavoro editoriali sono passi pratici che servono gli utenti turchi e si allineano con gli obiettivi più ampi della Circolare Presidenziale 2025/10.