Che cosa succede se ti dicessi i web designer che ci sono persone che potrebbero visitare il tuo sito web a cui non importa come sono?

Le persone ipovedenti navigano sul Web per le stesse ragioni che tutti noi facciamo, per trovare informazioni, acquistare e svolgere una miriade di compiti importanti utilizzando applicazioni basate sul web. Ma le persone ipovedenti vivono il Web in modo diverso e noi dobbiamo essere sensibili alle loro esigenze quando progettiamo e costruiamo siti web.

Secondo l'US Census Bureau e l'ONU e la Banca Mondiale oltre 47 milioni di americani e fino a 650 milioni di persone in tutto il mondo hanno una qualche forma di disabilità. Ogni visitatore dei siti designati deve essere in grado di trovare le informazioni che sta cercando ed eseguire le attività che intende svolgere indipendentemente da come appare la pagina web o l'app. Un sacco di fattori diversi che entrano nella creazione della pagina web o dell'applicazione possono avere un impatto sull'accessibilità.

Prendi la pillola blu - la storia finisce, ti svegli nel tuo letto e credi a qualunque cosa tu voglia credere. Prendi la pillola rossa - rimani nel paese delle meraviglie e ti mostro quanto è profonda la tana del coniglio. - La matrice

Sei pronto a scendere con me il coniglio da accessibilità? Avremo bisogno di approfondire gli aspetti tecnici delle pagine web. HTML è lo scheletro di una pagina Web mentre CSS, JavaScript e immagini migliorano l'HTML. Spesso le persone con disabilità visive perdono tutti questi miglioramenti. Sebbene l'accessibilità sia principalmente un'attività di sviluppo, a volte i requisiti tecnici necessari per preservare o migliorare l'accessibilità influiscono sull'aspetto del sito web. Ciò significa che design, copia, esperienza utente e sviluppo devono collaborare per assicurarsi che controlli di navigazione, moduli, pulsanti, intestazioni, pulsanti, collegamenti e altro siano accessibili.

design, copia, esperienza utente e sviluppo hanno bisogno di collaborare per garantire che controlli di navigazione, moduli, pulsanti, intestazioni, pulsanti, collegamenti e altro siano accessibili

Le persone non vedenti, ipovedenti, analfabete o disabili nell'apprendimento utilizzano tecnologie assistive per navigare in Internet. I lettori di schermo sono la tecnologia di assistenza più comune per il web, questi programmi software tentano di interpretare ciò che viene visualizzato sulla pagina Web e trasmetterlo all'utente, di solito attraverso la conversione del testo in parlato, ma a volte attraverso un dispositivo di output Braille. Gli ingranditori dello schermo sono spesso usati in combinazione con uno screen reader. In genere uno screen reader tenterà di analizzare l'HTML dalla parte superiore del file HTML in basso e di pronunciare gli elementi pertinenti all'utente. Idealmente, lo screen reader consentirà all'utente di spostare con successo un cursore virtuale lungo la pagina per riempire i campi modulo, fare clic sui pulsanti e effettuare selezioni dai menu a discesa e da altri controlli.

Per verificare accuratamente l'accessibilità, è necessario assicurarsi che il sito Web o l'app funzionino correttamente su ciascuno dei tanti screen reader disponibili. Ci sono diversi popolari lettori di schermo gratuiti e / o open source su ogni piattaforma JAWS , e NVDA . Gli utenti Microsoft possono utilizzare NVDA, mentre i computer Apple e i dispositivi iOS sono dotati Voce fuoricampo che può ingrandire i controlli della tastiera e leggere il contenuto dello schermo, e per i dispositivi Unix c'è Orca . Il browser Chrome ha due plugin per tecnologia assistiva, ChromeVox per la lettura dello schermo e ChromeVis per l'ingrandimento.

La maggior parte dei problemi di accessibilità al web si verificano quando il cursore virtuale dello screen reader viene intrappolato in una forma mal progettata o salta su un controllo importante o su una parte importante di informazioni testuali. Verificare che i siti Web siano effettivamente utilizzabili è simile al test del browser perché ogni screen reader ha requisiti e limiti diversi. Questo è il motivo per cui è importante capire il comportamento di ogni screen reader. Le esigenze di vari screen reader possono essere soddisfatte aggiungendo vari tag HTML speciali agli elementi importanti della pagina.

L'interfaccia utente Web dinamica moderna può essere particolarmente problematica per l'accessibilità poiché elementi importanti vengono aggiunti alla pagina in modo dinamico utilizzando JavaScript. Menu a discesa personalizzati, modali, suggerimenti, contenuti per fisarmonica ed errori e notifiche dinamici possono risultare difficili da comprendere per gli utenti di screen reader a causa di un'interruzione della comunicazione tra HTML, JavaScript e lo screen reader. HTML e JavaScript nativi non hanno modo di comunicare gli aggiornamenti della pagina (modello a oggetti del documento) agli screen reader. Gli sviluppatori devono spostare "focus" (il cursore virtuale del lettore dello schermo) sulla parte dell'interfaccia utente che è cambiata. Quando una modale si apre, gli sviluppatori devono mettere l'attenzione dell'utente su quella modale in modo che lo screen reader possa leggere quel contenuto e l'utente possa capire e interagire con esso.

WAI-ARIA può colmare le lacune tra ciò che dice l'HTML grezzo della pagina e ciò che gli utenti vedenti vedono

Questo viene fatto attraverso l'uso di speciali tag HTML chiamati WAI-ARIA tag. WAI-ARIA (accessibile Rich Internet Applications) può colmare le lacune tra ciò che l'HTML grezzo della pagina dice e ciò che gli utenti vedenti vedono fornendo un modo standardizzato per gli sviluppatori di aggiungere ulteriore significato a stati, proprietà, relazioni, ruoli e regioni dal vivo che altrimenti uno screen reader non capirebbe.   Gli sviluppatori possono utilizzare il livello di aria per spiegare agli screen reader la gerarchia di ciascuna intestazione sulla pagina. Con gli sviluppatori di etichette aria puoi aggiungere un'intestazione per descrivere lo scopo di un elemento discreto sulla pagina. Ciò aiuta gli sviluppatori a creare chiare relazioni tra diversi elementi. Gli sviluppatori possono anche attirare l'attenzione su controlli importanti etichettandoli con i tag aria-role, ad esempio un pulsante del menu a discesa sarebbe etichettato con il seguente tag: Aria-ha popup: true.

Vedi la penna Schede semplici accessibili di Scott Vinkle ( @svinkle ) sopra CodePen .

Nel codice HTML dell'esempio sopra, le schede vengono create utilizzando un elenco non ordinato con classi su ciascun elemento dell'elenco. JQuery cattura gli eventi click quando si fa clic su una scheda e aggiunge 'aria-selected': 'true' e 'tab-widget__tab-content-active' alla scheda selezionata e nasconde le altre schede aggiungendo 'aria-selected': ' falso 'alle restanti schede. Sulla riga 127 sono impostati gli attributi iniziali per le schede, insieme a questi snippet aiutano gli screen reader a riconoscere quale scheda è visibile. JavaScript sulla riga 35 aggiunge anche il supporto della tastiera alle schede. Il resto del file gestisce gli eventi di clic e tastiera in modo che jQuery possa aggiungere attributi "ruolo" e "presentazione" alla scheda attualmente selezionata.

I tag Aria possono aiutare gli screen reader ad interpretare i controlli personalizzati come pulsanti radio quando il controllo personalizzato è etichettato con: Aria-role = radio button. Quando un'applicazione ha un'area sandbox che comunica feedback o aggiornamenti all'utente, può essere etichettata con un tag regione attiva: Aria-live. Questo assicura che quando il testo su questo elemento cambia, verrà automaticamente comunicato all'utente tramite lo screen reader.

Gli aggiornamenti delle pagine sono una parte fondamentale del Web per gli screen reader perché quando si verifica un aggiornamento della pagina, segnala allo screen reader che deve annunciare la nuova pagina all'utente e rileggere il contenuto della pagina all'utente. Ciò significa che le applicazioni web a pagina singola pongono sfide speciali all'accessibilità. In un'app a una sola pagina non viene aggiornata la pagina completa, pertanto lo screen reader e quindi l'utente non verranno avvisati del contenuto aggiornato. Il risultato sarà che l'utente non riceve feedback sulle sue azioni. La soluzione migliore è emulare il comportamento di aggiornamento della pagina nativa. Alla vista caricata, aggiorna il titolo della pagina e annunciala all'utente.

Le specifiche complete per WAI-ARIA sono gestite dal W3 come le specifiche per HTML stesso nell'ambito della Web Accessibility Initiative (WAI), ma a volte le linee guida possono essere più utili delle specifiche, quindi ecco alcune linee guida generali per i progettisti:

  • assicurati che ci sia un contrasto visivo tra il testo e il suo sfondo.
  • non usare il solo colore per trasmettere informazioni;
  • fornire al tuo sito web una navigazione chiara e coerente;
  • assicurarsi che gli elementi del modulo includano chiaramente le etichette associate;
  • assicurarsi che gli elementi di feedback come i messaggi di errore possano essere facilmente identificati;
  • utilizzare i titoli e la spaziatura per raggruppare i contenuti correlati;
  • fornire testo alternativo per le immagini;
  • considera la progettazione del tuo sito Web in modo che tutte le funzionalità siano accessibili tramite la tastiera.

Ci sono diverse semplici decisioni che puoi prendere quando sviluppi un sito web che renderà il sito più accessibile senza approfondire troppo il markup di accessibilità o il test dello screen reader. Assicurandoti che il tuo HTML trasmetta il significato attraverso la sua struttura, aiuterai i lettori dello schermo a processare le informazioni nello stesso modo in cui appaiono sulla pagina per gli utenti vedenti. Questo è importante per gli utenti che utilizzano una lente di ingrandimento in combinazione con uno screen reader.

L'utilizzo del markup HTML appropriato per intestazioni, elenchi, tabelle e altri elementi consente allo screen reader di categorizzare la struttura della pagina per l'utente in modo familiare. Per i layout più coinvolti, HTML5 fornisce elementi aggiuntivi, come ad esempio