Cosa viene contestato: una guida pratica ai modelli di interfaccia utente alla base di 6.666 reclami in materia di accessibilità

L'intestazione è la prima area interattiva di ogni pagina e il pulsante "hamburger" è spesso la prima cosa a cui accede un utente che utilizza la tastiera. Quando quel pulsante viene visualizzato come un <div> se presenta un'immagine di sfondo CSS, non dispone di un nome accessibile o espande un menu che blocca il focus o non comunica il proprio stato di apertura/chiusura, l'intero sito diventa strutturalmente inutilizzabile dalla tastiera prima ancora che l'utente abbia avuto modo di interagire con i contenuti effettivi.

Il link di salto è il problema principale. Un link funzionante "Skip to main content" Il link di salto è una modifica di cinque righe, ma è anche l'indicatore più efficace per capire se un team di sviluppo abbia o meno inserito l'accessibilità nella propria lista di controllo. Le segnalazioni spesso citano entrambi questi aspetti nello stesso paragrafo, perché un link di salto mancante o non funzionante è il segnale d'allarme: se il team non ha implementato un link di salto, quasi certamente non ha implementato nemmeno gli stati "aria-expanded".

Trasforma il trigger del menu in un vero e proprio <button> con un'etichetta di testo visibile o accessibile solo tramite screen reader e un elemento gestito aria-expanded attributo. Specificare un "Skip to main content" link che diventa visibile quando si passa il mouse sopra e porta all'interno del <main> punto di riferimento. Assicurati che il focus passi al menu quando questo si apre, torni al pulsante di attivazione quando si chiude e che Esc chiude il menu.

La funzione di ricerca viene implementata come componente personalizzata nella maggior parte dei siti di grandi dimensioni: un campo di immissione testo con debounce che invia una richiesta ad ogni battuta e visualizza un elenco fluttuante di suggerimenti all'interno di un elemento posizionato in modo assoluto <div>. Il campo di immissione del testo in sé di solito funziona bene. L'elenco dei suggerimenti, invece, quasi mai. Viene visualizzato al di fuori del contesto DOM del campo di immissione, non ha role="listbox", no aria-activedescendant, e non viene emesso alcun avviso di "live region" quando compaiono i risultati. Un utente che utilizza uno screen reader digita, non sente nulla, preme Invio e si ritrova davanti una pagina di risultati di cui non sapeva l'esistenza.

Lo stesso modello architettonico si ripete nei pannelli dei filtri della ricerca per faccette e nell'elenco dei risultati stesso: elementi su cui è possibile spostare il focus della tastiera, che sono visibili ma non vengono mai annunciati. Le lamentele relative alla ricerca raramente riguardano la casella di ricerca; riguardano piuttosto tutto ciò che appare dopo che l'utente ha digitato.

Utilizza il modello standard WAI-ARIA per i menu a tendina: role="combobox" sull'ingresso con aria-expanded, aria-controls, e aria-activedescendant collegato a un role="listbox" di suggerimenti. Aggiungi un'area interattiva che visualizzi il numero di risultati. Assicurati che l'elenco dei suggerimenti sia accessibile con il tasto freccia giù, non solo con il mouse.

La griglia PLP concentra diversi anti-pattern in un'unica schermata. Ogni riquadro è in genere una scheda cliccabile con tre o quattro elementi secondari interattivi — link all'immagine, link al titolo, campioni di colore, pulsante di aggiunta rapida — racchiusi in un altro link alla pagina del prodotto. Il risultato sono elementi interattivi annidati (un errore HTML), testo dei link ridondante («Hero Dash Three Graphic Image Link» ripetuto quattro volte) e campioni di colore creati da <div> elementi con gestori di clic ma privi di ruolo e di nome.

La barra laterale dei filtri introduce una seconda categoria di errori. I filtri a faccette sono solitamente elenchi di caselle di selezione, ma sono realizzati con elementi div e span personalizzati, stilizzati in modo da sembrare caselle di selezione, mentre il vero <input> nascosto fuori dallo schermo. Quando quell'input nascosto perde il suo collegamento — a causa di una regola CSS, di un gestore di eventi JavaScript che intercetta la pressione del tasto spazio o di un elemento mancante for attributo sull'etichetta visibile — il filtro diventa utilizzabile solo con il mouse.

Utilizza un solo link per ogni piastrella con un testo descrittivo, anziché tre link per ogni prodotto. Riproduci i campioni in modo realistico <button> elementi all'interno di un role="radiogroup". Creare filtri per criteri specifici <input type="checkbox"> elementi associati <label> tag; personalizza l'aspetto dei campi di immissione invece di nasconderli. Segnala le modifiche al filtro con un'area di aggiornamento in tempo reale.

Nella pagina dei dettagli del prodotto, chi utilizza uno screen reader deve effettuare diverse scelte specifiche nell'ordine corretto: scegliere un colore, scegliere una taglia, impostare la quantità e infine aggiungere al carrello. Ognuna di queste opzioni è implementata nei moderni siti di e-commerce sotto forma di widget personalizzato — solitamente una riga orizzontale di <button>a forma di <div>Per quanto riguarda le dimensioni, si tratta di riquadri colorati creati con elementi `div` stilizzati tramite CSS e di un selettore numerico composto da due pulsanti con icona che affiancano un campo di immissione. I pulsanti di aumento e diminuzione vengono solitamente forniti senza un nome accessibile; le segnalazioni li descrivono come annunciato come «button, button» senza alcuna indicazione di cosa facciano.

Le guide alle taglie e le tabelle delle taglie rappresentano un altro punto debole: quasi sempre si trovano dietro un link denominato «Tabella delle taglie» che apre una finestra modale, e spesso il link stesso non ha un'etichetta, la finestra modale non ha un titolo visibile e la tabella al suo interno non presenta intestazioni di righe o colonne.

Utilizza controlli di modulo reali. I campioni di colore e i selettori di dimensione dovrebbero essere un role="radiogroup" di role="radio" pulsanti (o campi di selezione a radio stilizzati in modo da risultare invisibili), ciascuno con un nome accessibile come «Taglia: Media». Il cursore della quantità dovrebbe essere un campo numerico etichettato, accompagnato da pulsanti di incremento e decremento i cui nomi accessibili includano l'azione e la quantità corrente. Racchiudere l'intero blocco di selezione in un fieldset con una legenda.

Il pulsante "Aggiungi al carrello" è il momento più testato in qualsiasi funnel di e-commerce e uno di quelli che più spesso presenta problemi per gli utenti di tecnologie assistive. Il meccanismo è semplice: un visitatore preme il pulsante, un piccolo messaggio di conferma o un mini-carrello a scomparsa appare per due o tre secondi e l'icona del carrello aggiorna il contatore nell'intestazione. Gli utenti vedenti vedono tutti e tre i segnali. Gli utenti di lettori di schermo in genere non ne ricevono nessuno. Il messaggio di conferma viene visualizzato al di fuori di qualsiasi area attiva, il cassetto appare senza gestione del focus e la modifica del conteggio nel carrello viene trasmessa come semplice mutazione del DOM che nessun lettore di schermo annuncerà.

Il risultato è un pulsante che, dal punto di vista dell'utente, non fa nulla. Lo premono, non sentono alcun suono, pensano che non abbia funzionato e lo premono di nuovo. Alcuni reclami raccontano di aver premuto il pulsante cinque o sei volte prima di rendersi conto che il carrello aveva silenziosamente accumulato cinque o sei articoli.

Racchiudi l'area relativa allo stato del carrello tra aria-live="polite" e aggiornare il testo ad ogni aggiunta riuscita. Se il design prevede un pannello di conferma, spostare il focus sul pannello quando si apre e riportarlo sul pulsante originale quando si chiude. Aggiornare l'indicatore del numero di articoli nel carrello con un annuncio destinato esclusivamente agli screen reader, ad esempio: «1 articolo aggiunto. Totale nel carrello: 3 articoli».

I controlli costituiti esclusivamente da icone presentano un comportamento prevedibile: il contenuto visibile è un SVG o un glifo di un font di icone, il contenuto accessibile è vuoto e l'output dello screen reader si riduce al ruolo strutturale dell'elemento senza nome. L'icona del carrello viene annunciata come "link" o "collassato"; il fumetto della chat come "pulsante"; la fila di icone social nel piè di pagina come "link, link, link, link, link". L'utente non ha modo di sapere a cosa servano.

Le icone del carrello presentano più spesso problemi rispetto alle altre icone per una ragione di progettazione: in molte implementazioni, il numero di articoli nel carrello viene visualizzato all'interno del nome accessibile dell'icona (ad esempio, l'icona mostra "0" all'interno del file SVG) e lo screen reader rileva solo la cifra. Alcuni utenti segnalano che l'icona del carrello viene annunciata come "3, link" o "0, link", senza alcuna indicazione che il "3" si riferisca alla quantità di articoli nel carrello.

Ogni controllo composto esclusivamente da icone deve avere un nome accessibile. Aggiungi un aria-label sul pulsante oppure inserire al suo interno un'etichetta di testo nascosta alla vista: "Shopping cart, 3 items". Evita di inserire cifre nel nome accessibile dell'icona senza un contesto. Per le icone decorative che accompagnano del testo visibile, usa aria-hidden="true" sull'icona e lasciare che sia il testo a fungere da etichetta.

La pagina di checkout presenta un rischio di non conformità per pixel quadrato maggiore rispetto a qualsiasi altra pagina di un sito di e-commerce, e gli errori sono molto frequenti. I menu a tendina degli indirizzi visualizzati come personalizzati <div> componenti che ignorano il tasto spazio. Gli indicatori dei campi obbligatori vengono visualizzati solo come un asterisco rosso, senza aria-required e nessuna associazione programmatica. Messaggi di errore in linea visualizzati in rosso sotto il campo, senza aria-describedby il collegamento del campo all'errore e l'assenza di un messaggio di avviso quando la convalida fallisce. L'utente compila il modulo, preme "Continua", viene reindirizzato indietro senza alcun avviso e non ha modo di sapere quali campi non siano stati convalidati né il motivo.

In centinaia di casi si riscontrano le stesse lamentele: i messaggi di errore non vengono annunciati, i messaggi di errore sono vaghi, non è possibile inserire i dati di fatturazione. Non si tratta di bug isolati, bensì del comportamento predefinito della maggior parte dei componenti di checkout e-commerce forniti senza un intervento specifico in materia di accessibilità.

Usa quello vero <label> elementi associati agli input tramite for/id. Contrassegnare i campi obbligatori con aria-required="true" e indicare i requisiti con del testo visibile, non solo con il colore. In caso di errore di convalida, visualizzare il messaggio di errore all'interno del campo di immissione aria-describedby destinazione, indicare il campo non conforme aria-invalid="true", spostando il focus della tastiera sul primo campo non valido. Inserire un'area di riepilogo degli errori nella parte superiore del modulo con collegamenti diretti a ciascun campo non valido.

Il blocco di pagamento è particolare perché spesso viene fornito tramite un iframe di terze parti incorporato — Stripe Elements, Braintree Hosted Fields, un drop-in di Adyen. All'interno dell'iframe, il modulo del fornitore di servizi di pagamento è solitamente ben etichettato. Ma nel momento in cui un sito crea il proprio modulo di acquisizione della carta, o racchiude i campi incorporati in un layout personalizzato che sovrascrive le etichette con segnaposto visivi, i quattro campi — numero, scadenza, CVV, codice postale — diventano una riga di campi vuoti per uno screen reader.

Il campo CVV è quello che più spesso viene etichettato in modo errato, poiché i progettisti tendono a sostituire la sua etichetta con un'icona a forma di punto interrogativo che apre un suggerimento in cui viene spiegato cos'è il CVV. Il suggerimento non sostituisce l'etichetta; il campo deve comunque avere un nome a livello di codice. Quando non ne ha uno, lo screen reader legge l'intero blocco di pagamento come «modifica, modifica, modifica, modifica» e la transazione si interrompe.

Se si utilizza un'integrazione con campi ospitati da terze parti, seguire le linee guida sull'accessibilità fornite dal fornitore: la maggior parte di essi offre una procedura documentata per etichettare i campi dall'esterno dell'iframe. Se si crea un modulo di acquisizione personalizzato, ogni campo di immissione deve avere un vero e proprio <label> elemento con un'etichetta di testo visibile, oltre a autocomplete="cc-number" / cc-exp" / cc-csc" attributi in modo che i gestori di password e le tecnologie assistive possano identificare i campi in base alla loro funzione.

La pagina del carrello ripete il problema del selettore di quantità presente nella pagina del prodotto, ma con conseguenze più gravi: un utente che utilizza uno screen reader e non riesce a utilizzare il selettore non può completare l'ordine. Il pulsante "Rimuovi" è di per sé un anti-pattern: di solito si tratta di una piccola icona a forma di × accanto a ciascuna voce dell'ordine, spesso priva di testo visibile, senza aria-label, e non viene emesso alcun avviso quando la riga viene rimossa. L'utente preme quello che spera sia il pulsante di rimozione, la riga scompare e lo screen reader rimane in silenzio. Non c'è modo di confermare che l'operazione sia andata a buon fine.

Diverse segnalazioni descrivono un problema simile: il totale del carrello si aggiorna dinamicamente quando le quantità cambiano o vengono rimossi degli articoli, ma il nuovo totale viene visualizzato come semplice testo DOM al di fuori di qualsiasi area interattiva, quindi l'utente non ha idea di quanto gli verrà addebitato.

Ogni voce dovrebbe presentare un pulsante di rimozione contrassegnato (ad es., "Remove Blue T-Shirt, size M, from cart"). I controlli di selezione della quantità dovrebbero indicare il proprio valore corrente come parte del nome accessibile o tramite aggiornamenti abbinati delle aree dinamiche. Il subtotale del carrello dovrebbe trovarsi all'interno di un aria-live="polite" regione, in modo che le modifiche vengano segnalate. Confermare le eliminazioni tramite un comando di annullamento.

Si tratta della categoria più ampia del set di dati, poiché è il problema che costa meno individuare e più costoso ignorare. Uno screen reader percorre il DOM, incontra un <input>, e legge il suo nome descrittivo — che calcola, nell'ordine: aria-labelledby, aria-label, un'azienda collegata <label for>, il title attributo o il segnaposto. Se nessuno dei due è presente, lo screen reader annuncia solo il ruolo: «casella di modifica» o «modifica, vuota». Questa frase, quasi alla lettera, ricorre in centinaia di segnalazioni.

Il motivo per cui è così diffuso è di natura strutturale. I moderni sistemi di progettazione spesso visualizzano un testo segnaposto all'interno del campo di immissione come sostituto dell'etichetta visibile, e gli sviluppatori danno per scontato che sia proprio il segnaposto a svolgere la funzione di etichettatura. Ma non è così. Il segnaposto scompare quando l'utente digita, non lascia alcun nome a livello di codice e rende il campo inutilizzabile per chiunque vi giunga in una fase successiva del flusso o vi ritorni dopo un errore.

Ogni controllo interattivo riceve un'etichetta visibile, associata a livello di programmazione. <label for="email">Email</label><input id="email" type="email"> è lo schema canonico. I segnaposto fungono da indicazioni aggiuntive, non da sostituti. Per i controlli in cui una didascalia visibile è davvero sconsigliabile (campi di ricerca, pulsanti con icona), utilizzare aria-label con un testo descrittivo — mai con il segnaposto duplicato.

La frase «non segnalato né messo a fuoco» compare testualmente in oltre 400 segnalazioni ed è una delle frasi più ricorrenti nell'intero set di dati. Descrive una specifica modalità di malfunzionamento: sulla pagina compare una finestra modale o una finestra di dialogo (spesso in modo automatico — iscrizione alla newsletter, verifica dell'età, conferma della posizione), il contenuto visibile cambia, ma lo screen reader non riceve alcun segnale che indichi che qualcosa sia cambiato. Il focus rimane sulla pagina sottostante. L'utente continua a spostarsi con il tasto Tab attraverso ciò che si trovava sotto la finestra modale, completamente ignaro del fatto che sia apparsa una finestra di dialogo che blocca l'accesso.

Questo è il classico esempio di un modale che fallisce su tutti i fronti contemporaneamente: no role="dialog", no aria-modal="true", nessun cambio di focus programmatico durante l'apertura, nessuna "trappola del focus" durante l'apertura, nessun comportamento di chiusura con il tasto Esc, nessun titolo annunciato. Poiché tutti questi problemi si presentano insieme, risolvere uno solo di essi isolatamente non cambia la situazione.

Utilizza uno schema di finestra di dialogo consolidato (la specifica WAI-ARIA Authoring Practices costituisce il riferimento). All'apertura: sposta il focus sul primo elemento selezionabile all'interno della finestra di dialogo, imposta aria-modal="true" e role="dialog", assegnare un'etichetta alla finestra di dialogo con aria-labelledby indicandone l'intestazione. Quando è aperta: mantenere il focus all'interno della finestra di dialogo. Alla chiusura: riportare il focus sull'elemento che l'ha attivata. Rispettare il tasto Esc. Se la finestra modale interrompe un flusso (ad es. la riproduzione automatica al caricamento della pagina), fornire all'utente un unico meccanismo per chiuderla definitivamente.

Gli indicatori di focus vengono solitamente disattivati intenzionalmente da uno sviluppatore o da un designer che considerava il contorno predefinito del browser come un elemento di disturbo visivo e ha scritto *:focus { outline: none; } in un foglio di stile globale. La pagina ora appare più ordinata a un utente vedente che utilizza il mouse. Per un utente vedente che utilizza la tastiera — compresa la maggior parte degli utenti ipovedenti, degli utenti con disabilità motorie e degli utenti che navigano senza mouse — la pagina diventa inutilizzabile. L'utente può premere il tasto Tab, ma non è in grado di vedere dove si trova.

Si tratta di uno dei pochi casi di non conformità individuabili senza l'ausilio di tecnologie assistive. Un revisore del controllo qualità che scorra la home page una volta con il tasto Tab, senza ricorrere ad altri strumenti, lo individuerà in meno di un minuto. Il fatto che i team di accessibilità lo rilevino sistematicamente nei siti oggetto di contenzioso, mentre le revisioni interne lo hanno trascurato, è uno dei segnali più affidabili presenti nel set di dati che indicano che il sito non ha superato affatto i test di accessibilità da tastiera.

Non disattivare mai in modo generalizzato :focus contorni senza un elemento sostitutivo. Definire uno stile di evidenziazione visibile — in genere un contorno di 2-3 px con un contrasto sufficiente sia rispetto all'elemento che allo sfondo — utilizzando :focus-visible quindi l'indicatore appare durante la navigazione da tastiera, ma non quando si clicca con il mouse. Verificalo su ogni componente interattivo, inclusi i widget personalizzati, i link all'interno delle schede e gli elementi con tabindex.

Il logo è l'immagine più visitata di un sito web e una di quelle che più spesso non funzionano. Di solito è inserita in un link che rimanda alla home page, ma l'immagine viene caricata senza alt, no aria-label sul link, senza testo circostante. Lo screen reader legge solo “link”, senza alcuna indicazione sulla sua destinazione. Moltiplica questo per ogni pagina del sito.

La categoria più ampia — immagini prive di testo alternativo — comprende banner grafici, foto di prodotti, illustrazioni di copertina, icone dei social media e il vasto catalogo di immagini di marketing che un tipico sito di e-commerce mette a disposizione. I reclami relativi a questa categoria citano spesso nomi di file di immagini specifici, il che indica che il perito del ricorrente ha eseguito un controllo automatico che ha individuato tutte le immagini le cui alt l'attributo mancava o era vuoto, mentre avrebbe dovuto essere descrittivo.

I loghi dovrebbero includere un testo alternativo che descriva il nome dell'azienda e, se il logo rimanda a un link, la pagina di destinazione — alt="Acme Co. — homepage". Alle immagini decorative viene assegnato un attributo alt vuoto (alt=""), che li nasconde deliberatamente alle tecnologie assistive. Le immagini informative devono essere accompagnate da un testo alternativo descrittivo. Si dovrebbe evitare di generare automaticamente il testo alternativo dai nomi dei file o tramite didascalie generate dall'intelligenza artificiale senza una revisione umana; i registri dei reclami riportano ripetutamente casi in cui gli strumenti di sovrapposizione hanno descritto il logo di un'azienda come «un cartello blu e giallo».

Gli screen reader offrono una visualizzazione sotto forma di “elenco di link”, ampiamente utilizzata dagli utenti esperti per scorrere una pagina in pochi secondi. Tale visualizzazione mostra solo il testo del link, separato dal paragrafo circostante. Una pagina in cui ogni anteprima del blog termina con “Leggi tutto” viene visualizzata in quella vista come quindici voci identiche. Una pagina con cinque link vuoti — <a href="..."></a>, cosa che capita spesso quando le icone si trovano all'interno di tag di collegamento senza alcun testo di riserva — genera cinque spazi vuoti.

La soluzione è ben nota, così come il problema, ed è per questo che questo schema continua a ricomparire nei reclami: la sua persistenza è indice di un processo di sviluppo privo di un linter automatizzato per il testo dei link e di un controllo manuale con lo screen reader.

Ogni link deve avere un nome accessibile che descriva la sua destinazione o l'azione associata. Sostituisci le espressioni generiche con espressioni descrittive — “Leggi tutto” diventa “Maggiori informazioni sui risultati del terzo trimestre”. Per i link che contengono solo un'icona, aggiungere del testo nascosto alla vista oppure un aria-label. Esegui un controllo automatico (Axe, Lighthouse, ecc.) per verificare la presenza di <a> elementi durante la CI.

I video sono oggetto di reclami in due casi distinti. Il primo è quello più evidente: un video di marketing, una demo di prodotto o un video esplicativo viene pubblicato senza sottotitoli, trascrizione o alcun testo alternativo, e un visitatore sordo o ipoudente non può accedere al contenuto. Il secondo è più sottile: un video hero che viene riprodotto automaticamente al caricamento della pagina, il che interferisce con l'output dello screen reader e viola i controlli di pausa/arresto previsti dal livello AA delle WCAG 2.2 (secondo SC 2.2.2 Pausa, Arresto, Nascondi per i contenuti in movimento e SC 1.4.2 per qualsiasi audio).

Alcuni reclami presenti in questo set di dati sostengono che «la mancanza di sottotitoli nei video del sito web costituisce una violazione dell’ADA», presentandola come una conclusione giuridica. La validità di tale interpretazione varia a seconda della giurisdizione e delle circostanze; ciò che risulta più certo è che questi video non soddisfano costantemente i requisiti delle WCAG 2.2 AA, lo standard che la maggior parte dei tribunali e degli accordi transattivi considera il parametro di riferimento operativo in materia di conformità.

Fornire sottotitoli sincronizzati per tutti i video preregistrati con audio. Fornire anche una trascrizione testuale; le trascrizioni sono utili per gli utenti che utilizzano dispositivi con l'audio disattivato, in ambienti con larghezza di banda ridotta e ai fini dell'indicizzazione. Evitare la riproduzione automatica; se la riproduzione automatica è necessaria per motivi di progettazione, fornire un comando di pausa/arresto immediatamente accessibile tramite tastiera. Per i contenuti solo video (senza audio), fornire una descrizione audio o un testo alternativo.

La procedura di accesso è il punto di controllo fondamentale dell'intera esperienza di autenticazione. Quando il modulo non funziona, tutte le pagine a esso collegate diventano inaccessibili e, spesso, gli utenti percepiscono questa reazione a catena come un unico ostacolo. Il modello è lo stesso errore di etichettatura del modulo dell'E·01, spesso combinato con tre sotto-errori specifici: un pulsante "Mostra password" implementato come pulsante solo con icona, senza nome e senza annuncio del cambio di stato, un CAPTCHA che impedisce completamente l'uso dello screen reader ed errori in linea ("credenziali non valide") che vengono visualizzati sullo schermo ma non annunciati.

La casella di controllo "Ricordami" rappresenta un ulteriore errore secondario ricorrente: viene visualizzata come un elemento <div>, con l'effettivo <input> Nascosta fuori dallo schermo, la casella di controllo è selezionabile con il mouse ma non tramite tastiera o lettore di schermo. L'utente non ha modo di attivare una sessione persistente.

Usa quello vero <input>, <label>, e <button> elementi. Trasforma l'interruttore "Mostra/Nascondi password" in un vero e proprio pulsante con un nome accessibile che si aggiorni in base allo stato ("Show password" / "Hide password") e annunciare la modifica con aria-pressed. Fornire un'alternativa accessibile ai CAPTCHA basati su immagini (CAPTCHA audio o, preferibilmente, sostituire il CAPTCHA con un'autenticazione basata sul rischio o con le varianti accessibili di hCaptcha).

I lettori di schermo consentono di esplorare la pagina attraverso tre modalità di navigazione: per intestazione, per punto di riferimento e per collegamento. Una pagina che viene pubblicata senza un <h1>, senza <main>, <nav>, e <footer> punti di riferimento, e senza un lang="en" attributo su <html> elemento, ha eliminato contemporaneamente tutte e tre queste modalità di navigazione. Gli utenti non hanno modo di scorrere le pagine, né di passare direttamente ai contenuti, e lo screen reader non è in grado di caricare il motore di pronuncia corretto.

Si tratta di un errore particolarmente grave: la mancanza di un singolo punto di riferimento provoca una serie a catena di segnalazioni, poiché tutte le strategie di navigazione degli screen reader che dipendono da esso risultano ora inefficaci. Le segnalazioni di questo tipo riportano solitamente quattro o cinque problemi strutturali specifici, presentati come prova del fatto che il sito non dispone di una base semantica.

Ogni pagina ne ha una e una sola <h1>, con sottotitoli (<h2>, <h3>) annidati in modo logico. Racchiudere le regioni in elementi di riferimento HTML5: <header>, <nav>, <main>, <aside>, <footer>. Imposta lang nella directory principale <html> elemento. Verificare con uno strumento di controllo della struttura o eseguire document.querySelectorAll('h1').length === 1 come test di funzionamento nella CI.

La maggior parte dei controlli di qualità relativi all'accessibilità viene effettuata sui browser desktop con NVDA o JAWS. Le tecnologie assistive mobili — VoiceOver su iOS, TalkBack su Android — presentano una resa diversa dello stesso DOM, spesso con bug diversi. I reclami utilizzano ripetutamente l'abbreviazione "mobile SRU" (utente di screen reader mobile) per segnalare errori specifici della visualizzazione mobile: un menu a hamburger che funziona con NVDA su desktop ma non viene rilevato da VoiceOver, un pulsante Apple Pay accessibile su un laptop ma non sull'equivalente della pagina per iPhone, messaggi di errore che vengono annunciati su desktop ma non su dispositivi mobili.

I dati suggeriscono che gli imputati, pur disponendo di un'accessibilità su desktop altrimenti solida, continuano a essere citati in giudizio per questioni specifiche relative ai dispositivi mobili. La parità su dispositivi mobili è di per sé un requisito fondamentale per superare la verifica.

Effettuare i test utilizzando almeno VoiceOver su Safari per iOS e TalkBack su Chrome per Android, seguendo gli stessi flussi previsti dal controllo qualità per desktop. Prestare particolare attenzione alle interazioni basate sui gesti, ai pulsanti di pagamento nativi e alla lettura dei campi dei moduli quando vengono selezionati. Se esiste un'app nativa, sottoporla allo stesso controllo: spesso i reclami riguardano sia il sito web che l'app nell'ambito dello stesso caso.

L'overlay di accessibilità è l'unico caso in questo catalogo in cui il problema non risiede affatto nel sito sottostante, bensì nel presunto livello di correzione aggiunto per risolverlo. Le segnalazioni di questa categoria descrivono due tipi distinti di problemi. Il primo è che gli overlay non risolvono effettivamente le barriere sottostanti, per cui l'utente si imbatte negli stessi modali non funzionanti, moduli etichettati in modo errato ed errori non segnalati, indipendentemente dalla presenza o meno del widget. Il secondo è più specifico: gli overlay a volte introducono nuovi errori inserendo etichette errate, applicando in modo errato i ruoli ARIA o interferendo con la configurazione delle tecnologie assistive dell'utente.

Un dettaglio degno di nota: nei reclami presentati nel 2024 e nel 2025 si cita sempre più spesso per nome il fornitore dell'overlay. Due passaggi specifici dei reclami identificano UserWay e AccessiBe in termini inequivocabili, e le recenti azioni intraprese dalla FTC hanno creato il rischio concreto che l'aggiunta di un overlay costituisca di per sé una prova della mancata attuazione di misure correttive concrete, anziché una difesa contro eventuali azioni legali.

Considerate gli overlay come un segnale di allarme, non come una soluzione definitiva. Se ne è attualmente in uso uno, pianificate un percorso di correzione concreto che affronti il codice sottostante anziché mascherarlo. Il percorso collaudato consiste in una combinazione di: uno scanner automatizzato integrato nella CI, una verifica manuale rispetto alle WCAG 2.2 AA, test manuali con almeno uno screen reader e navigazione esclusivamente tramite tastiera, nonché un controllo continuo della qualità dell'accessibilità durante il processo di progettazione e sviluppo.