Strumenti web adattivi e accessibilità

Gli strumenti dell’interazione

Per le persone che dipendono dagli strumenti web adattivi per navigare in internet, il modo in cui i contenuti vengono costruiti e presentati è tutto. La tecnologia assistiva più sofisticata al mondo non può leggere, annunciare o azionare contenuti che non esistono in una forma accessibile. Un pulsante che in realtà è un <div> stilizzato, un’immagine senza alternativa testuale o un menu a tendina personalizzato senza supporto da tastiera è semplicemente invisibile — o peggio, un vicolo cieco — per chi dipende da questi strumenti ogni giorno.

QualiBooth ti aiuta a comprendere due cose contemporaneamente: come gli strumenti di un utente interpretano davvero i tuoi contenuti e quali contenuti o strutture mancano, sono difettosi o ambigui. È questa combinazione che distingue un sito web che tecnicamente si carica da uno che funziona davvero per tutti.

Questa guida illustra le principali categorie di tecnologia assistiva e adattiva, come ciascuna si aspetta che un sito web si comporti e i passi pratici che puoi compiere per costruire con questi strumenti anziché contro di essi. Traccia inoltre una linea chiara tra la tecnologia assistiva autentica e gli overlay di accessibilità, perché le due cose vengono spesso confuse e quella confusione ha conseguenze reali per utenti reali.

Cosa significano davvero gli «strumenti web adattivi»

Gli strumenti web adattivi — più comunemente chiamati tecnologia assistiva (AT) — sono software e hardware che cambiano il modo in cui una persona percepisce o aziona un’interfaccia digitale. Non sono aggiunte al tuo sito web; sono l’ambiente proprio dell’utente, configurato in base alle sue esigenze e spesso usato per ore al giorno su migliaia di siti.

Le principali categorie includono:

Screen reader che convertono il contenuto sullo schermo in voce sintetizzata o braille aggiornabile.
Ingrandimento dello schermo che ingrandisce e ridispone parte o l’intero schermo.
Dispositivi ad accesso tramite sensore (switch) per persone che non possono usare una tastiera o un mouse standard.
Controllo vocale che gestisce l’interfaccia interamente tramite comandi vocali.
Funzioni integrate del browser e del sistema operativo come modalità a contrasto elevato, movimento ridotto e strumenti di lettura.
Ausili alla lettura e alla comprensione che semplificano, narrano o ristrutturano il testo.

Ciascuno di questi si basa sulla stessa fondazione: una pagina ben strutturata, semantica e azionabile da tastiera che segue standard consolidati. Quando costruisci secondo le WCAG 2.2, stai creando il contratto da cui dipende ciascuno di questi strumenti.

Gli screen reader sono la tecnologia assistiva più conosciuta e, per molti team, la più difficile da progettare — proprio perché la disposizione visiva che vedi non dice quasi nulla su ciò che uno screen reader annuncia.

Gli screen reader più diffusi sono NVDA e JAWS su Windows, VoiceOver su macOS e iOS e TalkBack su Android. Non «vedono» la tua pagina; costruiscono un modello a partire dall’albero di accessibilità, che deriva dalla semantica del tuo HTML e da qualsiasi ARIA che aggiungi sopra.

Elementi semantici reali. Usa <button>, <a>, <nav>, <main>, <h1>–<h6> e <table> per ciò che sono. Un’intestazione deve essere un’intestazione affinché gli utenti possano saltare tra le sezioni; un link deve essere un link affinché compaia nell’elenco dei link.
Alternative testuali significative. Ogni immagine informativa ha bisogno di un attributo alt che ne descriva lo scopo. Le immagini decorative dovrebbero avere un alt="" vuoto in modo da essere saltate anziché annunciate come rumore.
Etichette programmatiche per i controlli. I campi dei moduli hanno bisogno di elementi <label> associati; i pulsanti con sola icona hanno bisogno di un nome accessibile tramite aria-label o testo nascosto visivamente.
Una gerarchia logica delle intestazioni. Le intestazioni sono il modo principale con cui gli utenti di screen reader scorrono una pagina. Saltare livelli o usare le intestazioni solo per la dimensione visiva interrompe quella navigazione.
ARIA corretto — e solo quando serve. ARIA può comunicare stati (espanso, selezionato, disabilitato) e ruoli per widget personalizzati, ma un ARIA scorretto è peggio di nessun ARIA. La prima regola di ARIA è usare HTML nativo ovunque possibile.

Un punto di confusione comune è la differenza tra uno screen reader e la normale sintesi vocale. Uno strumento di lettura narra il testo; uno screen reader espone e aziona l’intera interfaccia, inclusi controlli, stati e navigazione. Approfondiamo questa distinzione in sintesi vocale rispetto agli screen reader.

Poiché gli strumenti automatizzati possono cogliere solo una frazione dei problemi degli screen reader, l’unico modo affidabile per sapere come suona il tuo sito è testarlo nel modo in cui lo fanno gli utenti. La nostra guida ai test con screen reader illustra il flusso di lavoro pratico, e una valutazione dedicata con screen reader sottopone i tuoi percorsi più importanti a questo processo con tester esperti.

Ingrandimento dello schermo: progetta per la vista ingrandita

Le persone ipovedenti spesso ingrandiscono lo schermo da un 200% fino all’800% o più, visualizzando solo una piccola porzione della pagina alla volta. Alcune usano l’ingranditore del sistema operativo; altre si affidano allo zoom del browser o a software specializzati.

Con un forte ingrandimento, scelte di layout a cui non pensi mai diventano cruciali:

Ridisposizione (reflow). Il contenuto deve ridisporsi in una singola colonna al 400% di zoom (criterio di successo 1.4.10 delle WCAG 2.2) affinché gli utenti non debbano scorrere in due direzioni per leggere una frase.
Prossimità degli elementi correlati. Se un messaggio di errore compare lontano dal campo che descrive, un utente con ingrandimento potrebbe non vederli mai nello stesso viewport. Tieni vicini etichette, campi di input e feedback.
Focus visibile. Un indicatore di focus chiaro e ad alto contrasto consente a un utente con ingrandimento di ritrovare dove si trova dopo che la vista è saltata.
Nessuna perdita di contenuto o funzione. Nulla deve essere ritagliato, sovrapposto o reso inutilizzabile quando il testo viene ingrandito fino al 200% (criterio di successo 1.4.4).

L’ingrandimento premia i layout puliti e reattivi e penalizza i design a pixel fissi e i contenuti che dipendono dall’hover.

Accesso tramite sensore e operabilità da tastiera

I dispositivi a sensore (switch) consentono alle persone di azionare un computer con uno o due input semplici — un pulsante, un dispositivo sip-and-puff o un movimento della testa — di solito scorrendo gli elementi interattivi uno alla volta. L’accesso tramite sensore si basa sul supporto da tastiera: se il tuo sito funziona pienamente da tastiera, quasi certamente funziona anche con i sensori.

Questo rende la piena operabilità da tastiera una delle cose a maggior impatto che puoi fare bene:

Tutto raggiungibile. Ogni elemento interattivo deve essere focalizzabile e azionabile senza mouse — link, pulsanti, controlli dei moduli, menu, modali, caroselli e widget personalizzati allo stesso modo.
Un ordine di focus visibile e logico. Il focus dovrebbe muoversi nella pagina in un ordine che corrisponde al flusso visivo e di lettura, e l’elemento focalizzato deve essere sempre chiaramente indicato.
Nessuna trappola da tastiera. Gli utenti devono poter spostare il focus fuori da qualsiasi componente, inclusi media incorporati e finestre di dialogo.
Link di salto. Un link «salta al contenuto principale» consente alle persone di bypassare la navigazione ripetuta invece di scorrerla in ogni pagina.

Se un cliente sta compilando un modulo, può spostarsi con Tab su ogni campo, attivare un menu a tendina, scegliere un prodotto e inviare — tutto senza toccare il mouse? Il completamento automatico del browser collaborerà con il tuo markup? Sono le domande a cui gli utenti di sensori e tastiera rispondono sul tuo sito, che tu te le ponga o no.

Controllo vocale: i nomi e le etichette visibili contano

Gli strumenti di controllo vocale come Dragon, Voice Control e Voice Access consentono agli utenti di pronunciare comandi come «clicca Invia» o «scorri in basso». Affinché questi comandi funzionino, l’etichetta visibile di un controllo deve corrispondere al suo nome accessibile. Questa è la base del criterio di successo 2.5.3 delle WCAG 2.2, Etichetta nel nome.

Indicazioni pratiche:

Il nome accessibile dovrebbe contenere il testo visibile. Se un pulsante riporta «Invia messaggio», non dargli un aria-label di «Invia modulo»: l’utente che dice «clicca Invia messaggio» verrà ignorato.
Evita i controlli con sola icona senza testo, oppure dai loro un nome accessibile che corrisponda a un probabile comando vocale.
Mantieni i bersagli cliccabili abbastanza grandi da poterli selezionare in modo affidabile, cosa che soddisfa anche il criterio sulla dimensione del bersaglio nelle WCAG 2.2.

Funzioni di accessibilità del browser e del sistema operativo

Non tutti gli strumenti adattivi sono prodotti separati. I browser e i sistemi operativi moderni includono potenti funzioni integrate che gli utenti attivano a livello di sistema, e il tuo sito dovrebbe rispettarle automaticamente:

Movimento ridotto. Rispetta la media query prefers-reduced-motion per disabilitare o attenuare le animazioni per gli utenti che provano nausea o distrazione dal movimento.
Modalità scura e contrasto elevato. Supporta prefers-color-scheme e il Contrasto elevato / Colori forzati di Windows affinché la tua interfaccia rimanga leggibile senza che tu debba combattere contro le impostazioni dell’utente.
Ridimensionamento del testo e zoom. Usa unità relative affinché il ridimensionamento del testo del browser funzioni, anziché bloccare le dimensioni in pixel.
Modalità lettura e strumenti di lettura. Le viste di lettura del browser e strumenti come Immersive Reader riducono una pagina al suo contenuto essenziale — cosa che funziona molto meglio quando il tuo HTML è semantico e privo di disordine.

Queste funzioni non costano nulla in più all’utente e pochissimo a te, ma migliorano drasticamente il comfort di un pubblico ampio, incluse persone senza disabilità diagnosticate.

Strumenti di lettura e comprensione

Gli strumenti di lettura sono al servizio di persone con dislessia, ADHD, disabilità cognitive o competenze linguistiche limitate nella lingua della pagina. Includono narratori di sintesi vocale, righelli di lettura, evidenziazione delle parole, strumenti di riassunto e di traduzione.

Per funzionare bene con essi:

Scrivi in un linguaggio semplice e ben organizzato, con intestazioni descrittive e paragrafi brevi.
Marca la pagina in modo che il contenuto principale sia chiaramente identificabile e l’ordine di lettura sia corretto.
Evita di trasmettere significato solo tramite colore, layout o immagini: fornisci un equivalente testuale.
Assicurati che la lingua sia dichiarata (attributo lang) affinché narrazione e traduzione usino la pronuncia e le regole corrette.

Una buona struttura dei contenuti aiuta tutti gli strumenti di questo articolo contemporaneamente, perché attingono tutti dallo stesso markup sottostante.

Vera tecnologia assistiva vs overlay di accessibilità

Questa è la distinzione che conta di più, ed è qui che molte organizzazioni sbagliano.

La vera tecnologia assistiva — screen reader, ingranditori, accesso tramite sensore, controllo vocale — viene eseguita sul dispositivo dell’utente, sotto il suo controllo, e aziona il tuo sito web attraverso la sua semantica e il supporto da tastiera. L’utente ha passato anni a configurarla. Il tuo compito è semplicemente costruire una pagina che questi strumenti possano comprendere.

Gli overlay di accessibilità sono script di terze parti che aggiungi al tuo stesso sito e che promettono di «renderlo accessibile» automaticamente, di solito tramite un widget fluttuante. Non sono un sostituto della tecnologia assistiva, né una soluzione per un sito inaccessibile. Ecco perché:

Non possono riparare il codice sottostante. Gli overlay si posizionano sopra la pagina; non possono inventare in modo affidabile il testo alternativo mancante, correggere strutture di intestazione difettose o far comportare un <div> come un vero pulsante su ogni screen reader.
Spesso entrano in conflitto con la vera AT. Molti utenti di screen reader riferiscono che gli overlay interferiscono con gli strumenti su cui già fanno affidamento, rendendo a volte i siti più difficili da usare, non più facili.
Creano un falso senso di conformità. Installare un widget non soddisfa le WCAG 2.2, l’EAA o l’ADA. Sono state intentate cause contro siti che usano overlay proprio perché le barriere sottostanti rimanevano.
Non riflettono l’esperienza vissuta. L’accessibilità è in definitiva giudicata dalle persone che usano l’AT ogni giorno — motivo per cui conduciamo audit da parte di persone con disabilità anziché affidarci alle affermazioni di uno script.

La via affidabile è correggere l’accessibilità nel codice e convalidarla con test sia automatizzati sia umani. Spieghiamo questa filosofia più ampiamente in cosa significa la vera accessibilità digitale.

Un flusso di lavoro pratico per costruire con strumenti adattivi

Costruire per la tecnologia assistiva non è un progetto una tantum; è un processo che si inserisce nel modo in cui già rilasci software. Un approccio sostenibile combina di solito quattro cose:

Scansione automatizzata, presto e spesso. Strumenti come il software di scansione dell’accessibilità intercettano un grande volume di problemi a livello di codice — etichette mancanti, errori di contrasto, ARIA difettoso — prima che raggiungano la produzione. I controlli automatizzati sono rapidi e ripetibili, ma coprono solo una parte del quadro.
Test manuali e con tecnologia assistiva. I problemi che colpiscono di più gli utenti reali — ordine di focus confuso, annunci poco chiari, widget personalizzati inutilizzabili — richiedono una persona. La nostra guida agli audit manuali di accessibilità descrive come questo completi l’automazione.
Integrare l’accessibilità nel tuo team. Trattare l’accessibilità come una disciplina continua, supportata dal miglioramento del processo di accessibilità, previene la lenta regressione che si verifica quando le correzioni sono interventi isolati.
Gli strumenti giusti per il tuo stack. Il toolkit di accessibilità di QualiBooth riunisce scansione, monitoraggio e reportistica, mentre Agora e la nostra community edition offrono punti di ingresso per team a diversi livelli di maturità.

Se la terminologia di questo articolo ti è nuova, il glossario dell’accessibilità è un utile compagno mentre metti in pratica queste indicazioni.

Dove si inserisce QualiBooth

QualiBooth individua i problemi sul tuo sito web esistente e può anche scansionare le pagine prima che vadano online, così i clienti che usano qualsiasi strumento adattivo ottengono un’esperienza fluida che aumenta l’usabilità e la fedeltà al marchio. Combiniamo il rilevamento automatizzato con la valutazione di tester esperti e persone con disabilità, poi aiutiamo il tuo team a trasformare i risultati in correzioni durature — mai un overlay che maschera il problema.

L’obiettivo è semplice: un sito web che funziona con gli strumenti di cui i tuoi utenti già si fidano, alle loro condizioni, ogni volta che lo visitano.

Pronto a vedere come si comporta il tuo sito con la vera tecnologia assistiva? Esegui una scansione di accessibilità gratuita per individuare risultati rapidi, richiedi una demo per vedere QualiBooth in azione, oppure parla con il nostro team di un progetto di consulenza sull’accessibilità su misura.