WCAG 1.3.6: Identificare lo scopo

Cosa Significa Questa Regola

\n

WCAG 1.3.6 — Identify Purpose è un criterio di livello AAA sotto il Principio 1 (Percepibile) che estende i requisiti esistenti di struttura e semantica a un livello di granularità più fine. In particolare, richiede che lo scopo di ciascun componente dell’interfaccia utente, icona, regione e di alcuni campi di input possa essere determinato in modo programmato — il che significa che le informazioni semantiche sono esposte in modo che browser, estensioni del browser e tecnologie assistive possano leggerle e agire di conseguenza.

\n

Il criterio si basa direttamente su 1.3.1 (Info and Relationships) e 1.3.5 (Identify Input Purpose). Mentre 1.3.5 si concentra sui comuni campi di input relativi ai dati personali (nome, email, telefono, ecc.), 1.3.6 amplia il requisito a tutte le regioni e i componenti dell’interfaccia utente, inclusi i landmark di navigazione, le icone, i pulsanti e i widget interattivi. L’idea centrale è che un user agent o uno strumento di personalizzazione debba essere in grado di sostituire la presentazione predefinita — rimpiazzando le etichette testuali con simboli, semplificando una navigazione affollata o evidenziando i controlli più rilevanti — sulla base di dati sullo scopo, leggibili dalla macchina, incorporati nel markup.

\n

In termini pratici, una pagina soddisfa 1.3.6 quando utilizza elementi landmark HTML5 (come <header>, <nav>, <main>, <aside>, <footer> e <section>), applica i ruoli landmark ARIA appropriati laddove non vengono usati elementi landmark, espone lo scopo delle icone e di altri componenti dell’interfaccia non testuali tramite nomi o ruoli accessibili e — ove applicabile — utilizza token di scopo standardizzati come quelli definiti nella specifica W3C Personalization Semantics (precedentemente nota come proposta COGA Semantics), ad esempio tramite il vocabolario di attributi aui-.

\n

Una pagina non soddisfa il criterio quando le sue regioni sono implementate come contenitori generici <div> o <span> senza alcun ruolo semantico, quando le icone hanno un significato ma non hanno un nome accessibile o una semantica di supporto, o quando i componenti interattivi non forniscono alcun indizio programmabile sulla loro funzione oltre al loro aspetto visivo. Si applica un’eccezione ufficiale: il requisito si applica solo ai contenuti implementati utilizzando tecnologie che supportano l’identificazione del significato previsto. Se non esiste alcuna tecnologia o specifica di supporto per un particolare tipo di componente in un determinato stack tecnologico, il criterio non può essere ragionevolmente applicato a quel componente.

\n\n

Perché È Importante

\n

I principali beneficiari di WCAG 1.3.6 sono le persone con disabilità cognitive e dell’apprendimento, tra cui dislessia, disturbi da deficit di attenzione, condizioni dello spettro autistico, compromissioni della memoria e disabilità intellettive. Secondo l’Organizzazione Mondiale della Sanità, circa 1 persona su 6 nel mondo — oltre un miliardo di individui — vive con una forma significativa di disabilità, e le disabilità cognitive rappresentano uno dei gruppi più numerosi e meno serviti. Molti di questi utenti hanno difficoltà con strutture di navigazione complesse, menu di testo densi e controlli costituiti solo da icone che non forniscono alcun ancoraggio semantico.

\n

Consideriamo uno scenario concreto: un utente con grave dislessia si affida a un’estensione del browser che sostituisce le etichette di navigazione standard con set di simboli personali — icone basate su immagini tratte da una tavola di comunicazione che usa nella vita quotidiana. Affinché questa sostituzione funzioni, l’estensione deve essere in grado di determinare che un particolare <div> è in realtà un landmark di navigazione, che un’icona a forma di stella rappresenta “aggiungi ai preferiti” e che una freccia circolare rappresenta “aggiorna”. Senza uno scopo determinabile in modo programmato, l’estensione non ha nulla a cui agganciarsi e la sostituzione fallisce silenziosamente, lasciando l’utente con un’interfaccia che non riesce a interpretare.

\n

Anche gli utenti con disabilità motorie che si affidano a strumenti di accesso tramite sensori o controllo vocale traggono un beneficio significativo, perché gli strumenti consapevoli dello scopo possono generare overlay di scorciatoie o mappature di comandi vocali solo per i controlli la cui funzione è leggibile dalla macchina. Le persone cieche che interagiscono tramite screen reader traggono vantaggio da regioni landmark chiaramente etichettate, che consentono loro di saltare direttamente al contenuto <main> o di evitare la navigazione ripetitiva. Gli utenti ipovedenti che utilizzano lo zoom del browser o fogli di stile personalizzati beneficiano della struttura dei landmark perché consente al browser di rifluire il contenuto in modo prevedibile.

\n

Oltre all’accessibilità, l’implementazione delle semantiche richieste da 1.3.6 produce misurabili benefici SEO. I crawler dei motori di ricerca utilizzano i landmark e il markup schema per comprendere la struttura della pagina, indicizzare le gerarchie di contenuto e generare risultati avanzati. Una pagina ben strutturata con regioni landmark significative ha maggiori probabilità di ottenere featured snippet e punteggi di rilevanza più elevati. Esiste anche un diretto dividendo di usabilità: le pagine con una struttura semantica chiara sono più facili da mantenere, testare ed estendere da parte dei team di sviluppo, riducendo il debito tecnico a lungo termine.

\n\n

Regole Axe-core Correlate

\n

WCAG 1.3.6 richiede test manuali in aggiunta a qualsiasi verifica automatizzata. Gli strumenti automatici possono verificare la presenza di markup semantico ma non possono determinare se quel markup trasmette in modo accurato e completo lo scopo di ogni componente come farebbe un tester umano. Le seguenti regole di axe-core sono strettamente correlate e fungono da proxy automatizzati per alcuni aspetti di questo criterio:

\n

\n
• region — Verifica che tutti i contenuti della pagina siano contenuti all’interno di una regione landmark. Segnala i contenuti che si trovano al di fuori di qualsiasi elemento landmark riconosciuto o ruolo landmark ARIA. Sebbene questa regola non testi l’accuratezza dell’identificazione dello scopo, garantisce che sia presente la base strutturale richiesta da 1.3.6. Un errore significa che contenuti significativi sono invisibili alla navigazione basata sui landmark.
\n
• landmark-one-main — Verifica che la pagina contenga esattamente un elemento <main> o un elemento con role='main'. Questo è fondamentale per 1.3.6 perché l’area del contenuto principale è una delle regioni più critiche il cui scopo deve essere identificabile. Landmark <main> multipli o assenti rendono impossibile per gli strumenti di personalizzazione isolare il contenuto primario.
\n
• landmark-complementary-is-top-level — Verifica che gli elementi <aside> o le regioni con role='complementary' non siano annidati all’interno dell’area del contenuto principale in modo da rappresentarne erroneamente lo scopo. Un annidamento scorretto fuorvia le tecnologie assistive sulla relazione tra le regioni.
\n
• aria-allowed-role e aria-valid-attr-value — Segnalano assegnazioni di ruoli ARIA non valide o inappropriate. Poiché 1.3.6 dipende da semantiche di ruolo accurate, l’uso di un ruolo errato (ad esempio, role='navigation' su un gruppo di pulsanti) compromette attivamente l’identificazione dello scopo e queste regole metteranno in evidenza tali incongruenze.
\n
• button-name e link-name — Verificano che i controlli interattivi abbiano nomi accessibili. I pulsanti e i link costituiti solo da icone e privi di nomi accessibili sono una delle principali modalità di fallimento per 1.3.6, poiché non è possibile determinare alcuno scopo per un controllo senza nome. Queste regole segnalano l’assenza di aria-label, aria-labelledby o testo visibile.
\n

\n

È necessario il test manuale perché gli strumenti automatici non possono valutare se i token di scopo o i ruoli semantici scelti rappresentino accuratamente la reale funzione del componente nel contesto dell’applicazione. Un pulsante potrebbe avere un nome accessibile e un ruolo ARIA valido ma non soddisfare comunque 1.3.6 se il nome è fuorviante o il ruolo non riflette ciò che il controllo fa effettivamente.

\n\n

Come Eseguire i Test

\n

\n
1. Esegui una scansione automatizzata con axe DevTools o Lighthouse. Apri la pagina in Chrome, attiva l’estensione axe DevTools ed esegui una scansione dell’intera pagina. Filtra i risultati in base alle regole elencate sopra: region, landmark-one-main, button-name e link-name. Prendi nota di eventuali violazioni e dei relativi livelli di impatto. In Lighthouse, esegui un audit di Accessibilità e rivedi le sezioni relative ai landmark e ad ARIA. Documenta tutti i fallimenti come baseline, ma tieni presente che rappresentano solo un sottoinsieme della conformità a 1.3.6.
\n
2. Ispeziona manualmente la struttura dei landmark utilizzando gli strumenti di sviluppo del browser. Apri DevTools, vai al pannello Accessibility Tree (Chrome) o all’Accessibility Inspector (Firefox) e verifica che la pagina esponga una gerarchia di landmark coerente: un <header> al livello superiore, un <main>, almeno un <nav> (con un’etichetta distintiva se ne sono presenti più di uno) e un <footer>. Conferma che nessuna regione di contenuto significativa sia racchiusa solo in un generico <div> o <span>.
\n
3. Testa con NVDA e Firefox. Avvia NVDA, apri la pagina in Firefox e premi D per scorrere i landmark. Verifica che ogni landmark venga annunciato con un ruolo significativo e, laddove esistano più landmark dello stesso tipo, con un’etichetta univoca. Naviga fino a ciascun pulsante costituito solo da icone usando il tasto Tab e conferma che NVDA annunci un nome accessibile descrittivo — non una stringa vuota, un nome di file o un’etichetta generica come “button”.
\n
4. Testa con VoiceOver e Safari (macOS/iOS). Abilita VoiceOver (Cmd+F5 su macOS). Usa il Rotor (Vo+U) per aprire l’elenco dei Landmark e verifica che compaiano tutte le regioni previste. Passa tra i controlli interattivi con il tasto Tab e ascolta descrizioni significative. Su iOS, usa uno swipe con tre dita per navigare per intestazioni e landmark e conferma che lo scopo di ciascuna regione venga annunciato correttamente.
\n
5. Testa con JAWS e Chrome. Apri la pagina in Chrome con JAWS in esecuzione. Premi R per navigare tra le regioni e conferma che il ruolo e l’etichetta di ciascuna regione siano accurati. Usa il JAWS Virtual Cursor per leggere i pulsanti con icone e verificare che il loro scopo sia trasmesso. Usa il JAWS List of Links (Insert+F7) per esaminare tutti i nomi dei link e valutarne il significato.
\n
6. Testa le semantiche di personalizzazione (se implementate). Se la tua pagina utilizza il vocabolario W3C Personalization Semantics (ad esempio, attributi data-purpose o aui-), utilizza lo strumento di test Personalization Semantics o un’estensione del browser compatibile per verificare che i token di scopo siano applicati correttamente e leggibili dalla macchina da parte degli user agent che supportano la specifica.
\n
7. Conduci un audit dello scopo componente per componente. Per ogni componente interattivo e icona sulla pagina, chiediti: è possibile determinare lo scopo di questo componente senza il contesto visivo? Se rimuovere tutti i CSS e le immagini lascia comunque chiaro lo scopo del componente sulla base del solo DOM e degli attributi ARIA, il componente è conforme. Se lo scopo è trasmesso solo visivamente, non lo è.
\n

\n\n

Come Correggere

\n\n

Regioni div generiche senza landmark — Non corretto

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

Regioni div generiche senza landmark — Corretto

\n

<!-- Usa gli elementi landmark HTML5 nativi così che browser e AT\n     possano identificare in modo programmato lo scopo di ogni regione -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

Pulsante costituito solo da icona senza nome accessibile — Non corretto

\n

<!-- Un pulsante con icona il cui scopo non può essere determinato\n     in modo programmato — non ha alcun nome accessibile -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Pulsante costituito solo da icona senza nome accessibile — Corretto

\n

<!-- aria-label fornisce al pulsante uno scopo determinabile\n     in modo programmato; l'SVG è nascosto alle AT poiché l'etichetta lo copre -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

Landmark di navigazione multipli senza etichette distintive — Non corretto

\n

<!-- Due elementi nav con ruoli identici ma senza etichette:\n     gli screen reader non possono distinguerne lo scopo -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>

(Content truncated due to token limit — please retry this article.)