Un progetto fai da te di accessibilità web

L’estate del 2017 ha segnato una monumentale vittoria per i milioni di americani che vivono con una disabilità. Il 13 Giugno, un giudice del Southern District della Florida ha stabilito che il sito non accessibile di Winn-Dixie violava il Title III dell’Americans with Disabilities Act. Questo caso ha segnato il primo processo sotto l’ADA, che è diventato legge nel 1990.

Nonostante avesse speso più di 7 milioni di dollari per rinnovare il proprio sito web nel 2016, Winn-Dixie ha omesso di includere delle considerazioni di design per gli utenti con disabilità. Alcune delle feature che sono state aggiunte includevano: nuove prescrizioni online, coupon digitali, integrazione con la carta a premi e una funzione per individuare i negozi. Tuttavia, pare che l’inclusività non ce l’abbia fatta.

Dal momento che il nuovo sito di Winn-Dixie non era stato sviluppato tenendo presenti gli standard WCAG 2.0, le nuove feature di cui si vantava erano in effetti disponibili solo per gli utenti vedenti e non disabili. Quando Juan Carlos Gil, un residente della Florida legalmente cieco, ha visitato il sito web di Winn-Dixie per ordinare il refill delle sue medicine, ha scoperto che era quasi completamente inaccessibile usando lo stesso screen reader che usava per accedere a centinaia di altri siti.

Nel suo reclamo originale Juan ha affermato che “si sentiva come se gli fosse stata chiusa in faccia un’altra porta”. Ma Juan non era solo. Intenzionalmente o meno, Winn-Dixie stava negando l’accesso al proprio sito e, di conseguenza, a un intero gruppo di persone, a tutta una serie di feature che offre che permettono di risparmiare tempo.

Ciò che rende questo caso unico è che segna la prima volta nella storia in cui un caso di conciliazione pubblica è andato in giudizio, il che significa che il giudice ha stabilito che il sito web è un “luogo di pubblica conciliazione” sotto l’ADA e pertanto soggetto ai regolamenti ADA. Dal momento che non ci sono dei regolamenti ADA specifici riguardanti internet, il giudice Scola ha deciso che è appropriata l’adozione delle Web Content Accessibility Guidelines (WCAG) 2.0 Level AA. (Grazie al duro lavoro della Web Accessibility Initiative (WAI) al W3C, le WCAG 2.0 sono state ampiamente adottate in tutto il globo, sotto forma di legge o policy).

Imparare ad avere empatia#section1

Chiunque abbia un servizio in abbonamento per un prodotto (pensate ai pannolini, ai rasoi o al cibo per gli animali) conosce bene la sensazione di gratitudine che accompagna la consegna di un prodotto di cui si ha davvero bisogno che arriva giusto all’ultimo secondo. Immaginatevi quanto sareste più grati per questo servizio se, per qualsiasi ragione, foste impossibilitati a guidare e viveste a ore di distanza dal negozio più vicino. È un servizio che migliorerebbe moltissimo la vostra vita. Ma immaginate adesso che il servizio venga rimodernato e riprogettato in maniera tale che è utilizzabile solo dalle persone che possiedono una macchina. Probabilmente la cosa vi farebbe leggermente arrabbiare.

Questo esempio di servizio in abbonamento è ipotetico, tuttavia negli Stati Uniti, nonostante i requisiti di accessibilità web federali istituiti per proteggere i diritti degli Americani disabili, questo tipo di discriminazione accade frequentemente. In effetti, chiunque supponga che il caso Winn-Dixie fosse un incidente isolato sarebbe nel torto. Le cause in ambito accessibilità web stanno aumentando. L’aumento dal 2015 al 2016 è stato del 37%. Sebbene alcune di queste potrebbero essere quelle note come “cause brevi”, molte di esse rappresentano querelanti come Juan Gil che voleva semplicemente equi diritti. Scott Dinin, l’avvocato di Juan, ha spiegato: “Non stiamo facendo causa per danni. Gli stiamo solo facendo causa perché seguano le leggi che esistono in questo paese da ventiquattro anni”.

Per questo motivo e per molti altri, adesso è il momento migliore per avere un approccio proattivo all’accessibilità web. In questo articolo vi aiuterò a creare un modello per rendere accettabile il vostro sito web.

Il modello di accessibilità#section2

Se avete a che fare con un rimedio, non indorerò la pillola: soddisfare con successo gli standard di accessibilità è un duro lavoro, uno che si ottiene solo quanto ogni pagina di un sito aderisce a tutte le linee guida che state cercando di rispettare. Come ho citato prima, queste linee guida sono solitamente le WCAG 2.0 Level AA, il che significa soddisfare ogni requisito di Livello A e AA. Le deadline stringenti, il budget risicato e priorità in competizione potrebbero far aumentare lo stress che accompagna un progetto di rimedio dell’accessibilità web, ma con un po’ di pianificazione e ricerca, rendere un sito web accessibile è sia ragionevole sia realizzabile.

La mia intenzione è che possiate usare questo articolo come un modello che vi guidi mentre vi imbarcate in un progetto di rimedio fai da te dell’accessibilità. Prima di cominciare, avrete bisogno di accrescere il vostro know-how in materia di accessibilità, di familiarizzare con i principi di design universale e apprendere i vantaggi di un sito web accessibile. Poi, potrete cominciare a parlare con entusiasmo dei benefici dell’accessibilità alle persone che lavorano con voi.

Fare Il discorso alla leadership#section3

Assicurarsi il supporto della leadership aziendale è imperativo per il successo a lungo termine del vostro lavoro. Ci sono numerosi modi per sollevare la questione dell’accessibilità, ma, tristemente, nel mondo degli affari, le affermazioni comprovate superano l’etica e gli obblighi morali. Pertanto, ho scoperto che uno dei modi più efficaci per mettere insieme un business case per l’accessibilità web sia di sottolinearne i benefici.

Ecco alcune cose di cui parlare:

• I siti Web accessibili sono intrinsecamente più utilizzabili e di conseguenza ottengono più traffico. Inoltre, una miglior user experience ha come risultato un bounce rate più basso, conversioni più alte e meno feedback negativo, che a loro volta tipicamente fanno sì che i siti web accessibili si posizionino più in alto nei motori di ricerca.
• Come le tecnologie assistive, i web crawler (come Googlebot) sfruttano HTML per ottenere le loro informazioni dai siti web, quindi un sito web accessibile con un buon markup è più facile da indicizzare, il che lo rende più semplice da trovare nei risultati di ricerca.
• C’è un certo numero di rischi potenziali a non avere un sito web accessibile, uno dei quali è costituito dalle cause per accessibilità.
• Le piccole aziende negli Stati Uniti che migliorano l’accessibilità del proprio sito web possono aver diritto a una detrazione delle tasse da parte dell’IRS.

Date il via al movimento#section4

Se non potete assicurarvi fin da subito il supporto della leadership, potete ancora formare un movimento di base per l’accessibilità all’interno dell’azienda. Cominciate piano e create lo slancio man mano che lavorate al miglioramento dell’usabilità per tutti gli utenti. Anche se potreste non avere l’autorità per fare dei cambiamenti in tutta l’azienda, potrete strategicamente e sistematicamente indicare la strada per i miglioramenti di accessibilità web.

Vi consiglio di cominciare da poco. Per esempio, cominciate a spingere per dei miglioramenti nel rapporto del contrasto tra i colori in tutto il sito (che aiuterà i daltonici, le persone con problemi di vista e gli utenti più anziani) o lavorate per rendere il sito accessibile da tastiera (che aiuterà gli utenti con problemi di mobilità o con i touchpad rotti e le persone che come me preferiscono non usare il mouse ogni volta che si può). Incorporate la user research e l’A/B testing in questi aggiornamenti e documentate i risultati. Usate i risultati per caldeggiare altri miglioramenti di accessibilità.

Leggete e rileggete le linee guida#section5

Createvi una knowledge base mentre lavorate. Imparare quali leggi, regole o linee guida si applicano a voi e comprenderle è un prerequisito per scrivere un piano di accessibilità. Le linee guida di accessibilità web variano nel mondo. Ci potrebbero essere altre linee guida che si applicano a voi e, in alcuni casi, regole aggiuntive, regolamenti e ordini specifici per il vostro settore.

La mancata comprensione di quali regole si applicano al vostro caso, non leggerle completamente o non comprendere cosa significano può creare un grosso problema durante il percorso, incluso un’eccessiva revisione una volta che avrete saputo di dover fare dei cambiamenti.

Create un team#section6

Prima che possiate cominciare a porre rimedi al vostro sito web, dovrete assemblare un team. Il numero di persone varierà a seconda della dimensione della vostra azienda e del vostro sito web. In passato, ho lavorato per un’azienda molto grande con un sito web molto grande, tuttavia il team di accessibilità che hanno assemblato era piccolo rispetto alle migliaia di pagine a cui dovevamo rimediare. Tale team includeva un project manager, dei visual designer, degli user experience designer, dei front-end developer, dei content editor, un paio di persone per i requisiti e alcuni QA tester. La maggior parte di queste persone era stata presa dai loro ruoli full-time e istruita per familiarizzare rapidamente con le WCAG 2.0. Per aiutarvi a creare il vostro team di accessibilità, spiegherò in dettaglio le responsabilità principali dei ruoli chiave:

• Il project manager è responsabile della coordinazione dell’intero processo di bonifica. Aiuterà a gestire le sessioni di pianificazione, farà in modo che tutti rispettino il calendario e riferirà dei progressi che si stanno facendo. Lavorando a stretto contatto con le persone dei requisiti, il suo obiettivo è far sì che ogni parte di questa nuova macchina funzioni senza intoppi.
• I visual designer principalmente gestiranno le questioni di uso del colore e alternative di testo. Nella loro attuale forma, i contrasti minimi per le WCAG 2.0 si applicano solo al testo, tuttavia, l’aggiornamento WCAG 2.1 a lungo annunciato (dovrebbe essere rilasciato a metà 2018) contiene dei nuovi criteri di successo per il Non-text Contrast, che copre il contrasto minimo per tutti gli elementi interattivi e “per le grafiche necessarie alla comprensione del contenuto”. I visual designer dovrebbero anche tenersi alla larga dai trend di design che rovinano l’usabilità.
• Gli UX designer dovrebbero controllare che la navigazione e l’ordine di lettura siano consistenti e logici. Dovranno testare che le pagine stiano usando i tag di heading in maniera appropriata (gli heading sono per la struttura semantica, non per gli stili visuali). Controlleranno per vedere che i design delle pagine siano strutturati per apparire e funzionare in modi prevedibili.
• I developer hanno il potenziale per far funzionare o distruggere un sito web accessibile perché anche i design migliori falliranno se implementati in maniera scorretta. Se i vostri developer non hanno familiarità con WAI-ARIA, le accessible coding practices o JavaScript accessibile, allora devono imparare un po’ di cose. Gli sviluppatori dovrebbero pensare a sé stessi come designer perché giocano un ruolo molto importante nella progettazione di una user experience inclusiva. Fortunatamente, Google offre un breve corso gratuito, Introduction to Web Accessibility e, tramite Udacity, un corso gratis, avanzato di due settimane sull’accessibilità. Inoltre, The A11Y Project è un emporio pieno di pattern library, checklist e risorse di accessibilità gratiuite per front-end developer.
• Gli editorial rivedono il testo per la verbosità. Evitate di usare frasi che confonderanno le persone la cui prima lingua non è quella del sito. Non “menate il can per l’aia” (visto cosa ho fatto?). Fate in modo che il contenuto sia semplice, conciso e facile da capire. Non avete una laurea in lettere? Nessun problema. Ci sono delle app che possono aiutarvi a migliorare la chiarezza della vostra scrittura e che correggono la grammatica come un’insegnante di inglese delle scuole medie. Fate punti extra assicurandovi che il testo dei link sia comprensibile al di fuori del contesto. Sebbene questa sia una linea guida WCAG 2.0 Level AAA, è anche facilmente sistemabile e migliora enormemente la user experience per gli individui con varie abilità di apprendimento e cognitive.
• Gli analisti lavorano in tandem con gli editorial, il design, l’UX e la QA. Coordinano il lavoro che fanno questi gruppi e documentano i cambiamenti necessari. Siccome lavorano con questi team, gestiscono gli action item ed esaminano ulteriormente qualsiasi task, domanda o richiesta in sospeso. Gli analisti inoltre inviano le specifiche dei requisiti agli sviluppatori. Se i cambiamenti sono numerosi e complessi, gli sviluppatori potrebbero aver bisogno di ulteriori chiarimenti dagli analisti, che li aiuteranno a implementare appropriatamente i cambiamenti descritti nelle specifiche.
• I QA dovranno essere istruiti allo stesso livello degli altri specialisti di accessibilità visto che saranno i responsabili dei test dei cambiamenti che si stanno facendo e dovranno beccare qualsiasi questione che spunta fuori. Dovranno imparare come navigare in un sito web usando solo una tastiera e anche ad usare in maniera appropriata uno screen reader (idealmente una varietà di screen reader). Sottolineo “appropriatamente” perché anche se chiunque può scaricare NVDA o attivare VoiceOver, ci vuole un altro livello di abilità per comprendere la differenza tra “attraversare una pagina” e “attraversare una pagina con controlli da tastiera standard”. Può essere un vantaggio reale avere persone con problemi di vista, udito o mobilità nel team di QA, perché hanno maggiore familiarità con le tecnologie assistive e possono fare test in tandem con gli altri. Inoltre, c’è una varietà di strumenti automatici per testare l’accessibilità che si possono usare insieme ai test manuali. Questi strumenti tipicamente rilevano solo il 30% circa dei problemi comuni di accessibilità, quindi non sostituiscono i test continui fatti da persone, ma possono essere estremamente utili nell’aiutare un QA a capire quando un aggiornamento ha influenzato negativamente l’accessibilità del vostro sito web.

Accendete i motori!#section7

Dividete i task in pezzi che abbiano senso. Potrete voler gestire prima tutti gli elementi globali e poi procedere nel resto del sito, sezione per sezione. Tenete a mente che ogni pagina deve aderire agli standard di accessibilità che state seguendo perché la si possa giudicare “accessibile”. (Include anche i PDF).

Usate quello che avete imparato finora attraverso video, articoli e linee guida di accessibilità per fare un audit del vostro attuale sito. Mentre alcuni test manuali potrebbero sulle prime sembrare difficili, sarete felici di sapere che alcuni test manuali sono molto semplici. Indipendentemente dai test che si stanno facendo, tenete a mente che dovrebbero essere sempre fatti approfonditamente e considerando una varietà di utenti, inclusi:

• utenti da tastiera;
• utenti ciechi;
• utenti daltonici;
• utenti ipovedenti;
• utenti sordi o con problemi d’udito;
• utenti con disabilità nell’apprendimento e limiti cognitivi;
• utenti con mobilità ridotta;
• utenti con disabilità del linguaggio;
• utenti con epilessia.

Documentate i pattern#section8

Man mano che vi addentrate nei meandri della bonifica, tenete traccia dei pattern che state usando. Cominciate un knowledge repository per gli elementi e le situazioni. Fissate i design e i colori, programmate ogni elemento perché sia accessibile e testate questi pattern su varie piattaforme, browser, screen reader e device. Quando sapete che gli elementi sono a prova di bomba, salvateli in una pattern library da cui potete estrarli in seguito. Avere a portata di mano una pattern library migliorerà la consistenza e la compliance e vi aiuterà più avanti a rispettare le scadenze stringenti, specialmente quando si lavora in ambiente agile. Dovrete tenere aggiornati il knowledge repository e la pattern library. Dovrebbe essere un documento vivo.

Attraversare il traguardo… E andare avanti!#section9

Alcune persone credono erroneamente che l’accessibilità sia una soluzione “impostala e dimenticatene”. Non lo è. L’accessibilità è una sfida continua a migliorare costantemente la user experience così come fa ogni bravo UX practitioner. Questo è il motivo per cui è cruciale avere a bordo la leadership. Una volta che il vostro sito è completamente accessibile, dovete cominciare a lavorare sugli arretrati dei miglioramenti continui. Se non siete vigili sull’accessibilità, le persone che faranno anche piccoli aggiornamenti del sito potrebbero involontariamente eliminare dal sito delle feature di accessibilità su cui avevate lavorato così duramente. Sareste sorpresi da quanto capita rapidamente, quindi istruite tutti i vostri colleghi sull’importanza dell’accessibilità. Quando tutti quelli che lavorano sul vostro sito comprendono e sostengono con entusiasmo l’accessibilità, le vostre chance di protezione dell’accessibilità del sito saranno molto più alte.

Riguarda l’esperienza, non la legge#section10

Nel Dicembre del 2017, Winn-Dixie ha fatto ricorso in appello contro Juan Carlo Gil. La loro tesi è che un sito web non costituisce un luogo di alloggio e, pertanto, il loro caso avrebbe dovuto essere respinto. Questo caso, e altri, illustrano che la legalità dell’accessibilità del web è ancora molto in divenire. Tuttavia, come sviluppatori e progettisti di siti web, la nostra motivazione a costruire siti Web accessibili non dovrebbe avere nulla a che fare con la legge ma tutto ciò che riguarda l’esperienza dell’utente.

Una buona accessibilità è una buona UX. Dovremmo cercare di creare la miglior user experience per tutti e non dovremmo accontentarci semplicemente di soddisfare gli standard di accessibilità ma piuttosto impegnarci a fondo per creare un’esperienza che delizi gli utenti con tutti i tipi di abilità.

Ulteriori risorse e articoli#section11

Se siete pronti per imparare di più sugli standard di accessibilità web e diventare un accessibility evangelist nel vostro team, ecco alcune risorse in più che possono aiutarvi.

Risorse#section12#section12

• Interactive WCAG 2.0: una fantastica versione integrale delle linee guida WCAG 2.0 che vi permette di filtrare i success criteria per responsabilità.
• tota11y: è totalmente uno strumento di visualizzazione dell’accessibilità facile da usare di Khan Academy.
• L’A11Y Project: una tonnellata di librerie, checklist e risorse sull’accessibilità per i front-end developer.
• Web Accessibility by Google: Developing with Empathy: un corso di eLearning di due settimane, gratis, pensato per i front-end developer esperti.
• “Top Twenty-Five Awesome Accessibility Testing Tools for Websites”: una lista di venticinque tool di testing automatici dell’accessibilità con una breve descrizione per ciascuno di essi.

Articoli#section13

• “Why Designing for Accessibility Is Simply Good Business”: elenca sette vantaggi dell’avere un sito web accessibile adatti alle aziende.
• “Accessibility Is Part of UX (It Isn’t a Swear Word)”: un articolo bellissimo che spiega come la separazione tra HTML e CSS influenzi la navigazione, il layout e molto altro.
• “Reinquadrare l’accessibilità per il Web”: spiega gli stereotipi negativi, l’abilismo e come integrare l’accessibilità nei propri processi di testing.
• “What Does Responsive Web Design Have to Do with Accessibility?”: discute come il responsive web design migliori UX e accessibilità.
• “Ten Guidelines to Improve the Usability and Accessibility of Your Site”: vi aiuta a identificare le opzioni più facili per le questioni di accessibilità e vi mostra come risolverle.