Widget accessibilità sito: bastano per essere conformi? No, e il motivo sta nell'HTML

Ogni tanto la richiesta arriva così: «mettiamo il widget dell'accessibilità e siamo a posto». Di solito la porta un cliente che ha ricevuto un'email con la scadenza dell'European Accessibility Act e un link a un servizio che promette la conformità con una riga di script da incollare nel sito.

La risposta breve è no: un widget non rende conforme un sito. La conformità è una proprietà del codice HTML che sta sotto, e il widget quel codice non lo tocca. Aggiunge un pannello sopra la pagina. Se la pagina è fatta male, resta fatta male, con un pannello in più.

Cosa fa davvero un widget di accessibilità

Il widget è un tag script che carichi da un server di terzi. Quando la pagina si apre disegna un'icona in un angolo e, da lì, un pannello: ingrandisci il testo, aumenta il contrasto, evidenzia i link, ferma le animazioni, cambia il font. Alcuni provano anche a riparare la pagina al volo con l'AI: indovinano il testo alternativo delle immagini e aggiungono attributi ARIA dove secondo loro mancano.

Tutto questo succede nel browser di chi visita, dopo il caricamento. Il sorgente del sito non cambia. Il giorno dopo, il codice è identico a prima.

E la parte più vistosa del pannello, zoom e contrasto, è quella che serve meno. Chi ne ha bisogno ha già il browser e il sistema operativo configurati per conto suo, e quelle impostazioni funzionano su ogni sito, senza che nessuno paghi un canone.

Cosa sente uno screen reader

Questa è la prova che a me ha convinto, e la consiglio a chiunque debba decidere. Apri VoiceOver su Mac o NVDA su Windows, spegni lo schermo e naviga il tuo sito. Quello che senti non è quello che vedi: senti un elenco di titoli, un elenco di link, dei campi di form. Lo screen reader legge l'albero di accessibilità, che il browser costruisce partendo dall'HTML.

Tre casi che trovo di continuo nei siti che eredito:

• Un bottone fatto con un div e un onclick. A occhio è un bottone. Per lo screen reader è testo qualunque: non si raggiunge con Tab, non si attiva con Invio, e non annuncia «pulsante».
• Titoli scelti in base alla dimensione che piaceva al grafico, un h3 qui e un h5 là, senza gerarchia. Chi naviga per titoli, che è il modo più comune di orientarsi in una pagina con uno screen reader, sente un elenco senza logica.
• Un'icona a forma di carrello dentro un link, senza testo. Lo screen reader dice «link» e basta, oppure legge il nome del file.

Il widget vede questi problemi? In parte. Può indovinare che quel div è un bottone perché ha un onclick e appiccicargli un ruolo. Ma non gli dà il focus da tastiera se non lo aveva, non gli aggancia il tasto Invio, e se dentro c'è solo un'icona non sa che nome dargli. I testi alternativi generati al volo li ho visti sbagliare la cosa più semplice: una foto di prodotto descritta con una didascalia generica che non corrisponde a quello che c'è.

Perché non basta per essere conformi

Le WCAG, lo standard dietro alla norma europea EN 301 549 e quindi all'EAA e al decreto italiano che lo recepisce, valutano il contenuto che il browser riceve, non gli strumenti che l'utente ha a disposizione per correggerlo. Criteri come «Nome, ruolo, valore», «Informazioni e correlazioni», «Tastiera» e «Ordine del focus» li soddisfa l'HTML, o non li soddisfa nessuno.

Poi c'è la pratica. Il widget parte solo dopo che JavaScript è caricato, dipende da un server che non è il tuo, e piazza il suo bottone in un angolo dello schermo: su mobile, spesso, sopra il menu o sopra la chat. Chi usa già uno screen reader si trova un altro strato da imparare, diverso su ogni sito, sopra gli strumenti che conosce.

Non è un'opinione mia soltanto. Centinaia di professionisti dell'accessibilità, molti dei quali con una disabilità, hanno firmato una dichiarazione pubblica contro gli overlay, l'Overlay Fact Sheet. E negli Stati Uniti l'autorità federale per la tutela dei consumatori ha sanzionato uno dei fornitori più noti per come pubblicizzava la conformità garantita dal suo prodotto. Cifre e nomi si trovano con una ricerca; il punto è che la promessa «una riga di script e sei a norma» è già stata smontata da chi doveva farlo.

Cosa faccio io invece

Il lavoro non è più difficile. È diverso, e sta prima. Su un progetto nuovo:

• HTML semantico: button per i bottoni, a per i link, nav, main, header e footer al posto giusto. Gran parte dell'accessibilità arriva da qui senza sforzo.
• Una gerarchia di titoli che racconta la pagina anche senza CSS. Un h1, gli h2 per le sezioni, gli h3 sotto. La dimensione la decide il foglio di stile, non il tag.
• Ogni elemento interattivo raggiungibile con Tab e con un focus visibile. Lo provo staccando il mouse.
• Testo alternativo scritto da una persona, oppure vuoto se l'immagine è decorativa. Vuoto è una scelta; mancante è un errore.
• Contrasto verificato in fase di design, non alla fine sul sito finito.
• Form con etichette associate ai campi ed errori annunciati, non solo un bordo rosso.

Poi il giro con lo screen reader, che non sostituisce un audit ma trova subito le cose grosse. Per imparare le basi basta un pomeriggio.

Sui siti che eredito la sequenza è: scansione automatica con axe o Lighthouse per la lista lunga, poi navigazione a mano da tastiera e con VoiceOver per quello che i tool non vedono, poi le correzioni nel codice. Il widget, se c'è, lo tolgo: costa un canone e nasconde il problema a chi dovrebbe vederlo.

Se te lo stanno proponendo

Se sei dalla parte di chi decide, il widget attira per due motivi: costa poco al mese e si installa in cinque minuti. Le domande da fare al fornitore sono queste: il vostro prodotto modifica il codice sorgente del mio sito? Se arriva una contestazione, chi risponde? Cosa vede un utente se il vostro server non risponde?

Le risposte oneste sono: no, tu, e il sito di prima. A quel punto il confronto è tra un canone che continua e un lavoro che si fa una volta: un audit, le correzioni nel codice e i dieci controlli che puoi fare da solo per tenerlo in ordine. È la parte del nostro lavoro di sviluppo che il cliente non vede mai, e secondo me è quella che distingue un sito conforme da un sito con un'icona in basso a destra.