Buono, migliore, migliore: districare il complesso mondo dei modelli accessibili

Marc Benioff ha affermato in modo memorabile che l'unica costante nell'industria tecnologica è il cambiamento. Avendo lavorato nella tecnologia per oltre 15 anni, posso confermarlo. I compagni di dinosauri tecnologici possono attestare che il modo in cui il web funzionava all'inizio è drasticamente diverso da quanto molti di noi avrebbero persino potuto immaginare.

Sebbene questo costante cambiamento nel settore tecnologico abbia portato all'innovazione e ai progressi che vediamo oggi, ha anche introdotto il concetto di scelta. Sebbene la scelta, in apparenza, possa sembrare una cosa intrinsecamente positiva, non è sempre uguale ad arcobaleni e rose. L'afflusso del cambiamento tecnologico porta anche alla frammentazione dei linguaggi di codifica e ai sapori infiniti della "caldezza" della programmazione. A volte questa abbondanza di scelta si trasforma in una scelta eccessiva, un deterioramento cognitivo ben studiato in cui le persone hanno difficoltà a prendere una decisione a causa delle troppe opzioni.

In questo articolo, cercheremo di districare il complesso mondo dei modelli accessibili, un passo alla volta. Inizieremo le cose esaminando gli attuali modelli e librerie accessibili, quindi considereremo le nostre esigenze generali di modello e le potenziali restrizioni e, infine, analizzeremo una serie di esercizi di pensiero critico per imparare a valutare meglio i modelli per l'accessibilità.

Che rete aggrovigliata che tessiamo

Overchoice si è insinuato in tutti gli aspetti della tecnologia, inclusi i modelli e le librerie che utilizziamo per costruire le nostre creazioni digitali, dalla semplice casella di controllo al complesso modale dinamico e tutto il resto. Ma come facciamo a sapere quale modello o libreria è quello giusto quando ci sono così tante scelte? È meglio utilizzare modelli/librerie consolidati che gli utenti incontrano ogni giorno? O è meglio creare modelli nuovi di zecca per un'esperienza utente più piacevole?

Con la miriade di opzioni disponibili, possiamo diventare rapidamente paralizzati dalla sovrabbondanza di scelte. Ma se facciamo un passo indietro e consideriamo il motivo per cui costruiamo i nostri prodotti digitali in primo luogo (cioè l'utente finale) non ha senso scegliere il modello o la libreria che può aggiungere il maggior valore per il maggior numero di persone ?

Se pensavi che la scelta di un modello o di una libreria fosse un processo già abbastanza scoraggiante, questo potrebbe essere il punto in cui inizi a preoccuparti. Ma non c'è bisogno di preoccuparsi: la scelta di un modello/biblioteca accessibile non è scienza missilistica. Come ogni altra cosa nella tecnologia, questo viaggio inizia con un po' di conoscenza, un enorme cumulo di tentativi ed errori e la comprensione del fatto che non esiste un solo modello/libreria perfetto che si adatti a ogni utente, situazione o framework.

Come faccio a saperlo? Bene, ho passato gli ultimi cinque anni a ricercare, costruire e testare diversi tipi di pattern accessibili mentre lavoravo su A11y Style Guide, ARIA Pattern Library di Deque e valutavo i pattern SVG più diffusi. Ma ho anche esaminato molti modelli e librerie client su ogni framework/piattaforma immaginabile. A questo punto, posso dire senza scrupoli che esiste una gerarchia innata per l'accessibilità dei modelli che inizia a svilupparsi quando si guarda abbastanza a lungo. E mentre a volte ci sono schemi da evitare a tutti i costi, non è sempre così chiaro. Quando si tratta di accessibilità, direi che la maggior parte dei modelli cade in gradienti di buono, migliore, migliore. La parte difficile è sapere quale modello appartiene a quale categoria.

Pensare in modo critico ai modelli

Quindi, come facciamo a sapere quali modelli sono buoni, migliori, migliori quando si tratta di accessibilità? Dipende. Questa frase spesso invocata dalla comunità dell'accessibilità digitale non è una scappatoia ma è un'abbreviazione per "abbiamo bisogno di più contesto per essere in grado di darti la risposta migliore". Tuttavia, il contesto non è sempre chiaro, quindi quando si costruisce e si valuta l'accessibilità di un modello, alcune domande fondamentali che pongo includono:

• Esiste già un modello accessibile stabilito che possiamo utilizzare?
• Quali browser e dispositivi di tecnologia assistiva (AT) stiamo supportando?
• Ci sono limitazioni del framework o altre integrazioni/fattori da considerare?

Naturalmente, le tue domande specifiche possono variare dalle mie, ma il punto è che devi iniziare a usare le tue capacità di pensiero critico quando valuti i modelli. Puoi farlo osservando, analizzando e quindi classificando ogni modello per l'accessibilità prima di passare a una decisione finale. Ma prima di arrivare a questo, analizziamo un po' di più le domande iniziali.

Esiste già un modello accessibile stabilito?

Perché sembra che con ogni nuovo framework otteniamo una serie completamente nuova di modelli? Questa costante reinvenzione della ruota con nuove scelte di pattern può confondere e frustrare gli sviluppatori, soprattutto perché di solito non è necessario farlo.

Non mi credi? Bene, pensaci in questo modo: se ci abboniamo al sistema di progettazione atomica, capiamo che diversi piccoli "atomi" di codice si uniscono per creare un prodotto digitale più grande. Ma nel mondo scientifico, gli atomi non sono la più piccola componente della vita. Ogni atomo è composto da molte particelle subatomiche come protoni, neutroni ed elettroni.

Quella stessa logica può essere applicata ai nostri modelli. Se osserviamo più in profondità tutti i modelli disponibili nei vari framework esistenti, la struttura subatomica centrale è essenzialmente la stessa, indipendentemente dal linguaggio di codifica effettivo utilizzato. Questo è il motivo per cui apprezzo le librerie di codifica semplificate con modelli accessibili su cui possiamo costruire in base alle esigenze tecnologiche e di progettazione.

Nota : alcune ottime fonti affidabili includono Componenti inclusivi, Componenti accessibili e Sistema di progettazione Gov.UK, oltre all'elenco di modelli accessibili Smashing Magazine pubblicato di recente (oltre a un elenco più dettagliato di modelli e librerie alla fine dell'articolo) .

Quali browser e dispositivi di tecnologia assistiva (AT) stiamo supportando?

Dopo aver ricercato alcuni modelli di base che potrebbero funzionare, possiamo passare alla questione del supporto per browser e dispositivi di tecnologia assistiva (AT). Di per sé, il supporto del browser non è uno scherzo. Quando aggiungi dispositivi AT e specifiche ARIA al mix, le cose iniziano a diventare complicate... non impossibili, solo molto più tempo, fatica e processo di pensiero necessari per capire tutto.

Ma non sono tutte cattive notizie. Ci sono alcune risorse favolose come l'Accessibilità HTML5 e il supporto per l'accessibilità che ci aiutano a comprendere meglio il browser attuale + il supporto per i dispositivi AT. Questi siti Web descrivono i diversi sottoelementi di pattern HTML e ARIA disponibili, includono test della comunità open source e forniscono alcuni esempi di pattern, sia per browser desktop che mobili/dispositivi AT.

Ci sono limitazioni del framework o altre integrazioni/fattori da considerare?

Dopo aver scelto alcuni modelli di base accessibili e preso in considerazione il supporto del browser/dispositivo AT, possiamo passare a domande contestuali più dettagliate sul modello e sul suo ambiente. Ad esempio, se utilizziamo un modello in un sistema di gestione dei contenuti (CMS) o abbiamo considerazioni sul codice legacy, ci saranno alcune limitazioni del modello. In questo caso, una manciata di scelte di pattern può essere rapidamente ridotta a una o due. D'altra parte, alcuni framework sono più indulgenti e aperti ad accettare qualsiasi modello, quindi possiamo preoccuparci meno delle restrizioni del framework e concentrarci maggiormente sulla scelta del modello più accessibile che possiamo fare.

Oltre a tutto ciò che abbiamo discusso finora, ci sono molte considerazioni aggiuntive da valutare quando si sceglie un modello, come prestazioni, sicurezza, ottimizzazione dei motori di ricerca, traduzione linguistica, integrazione di terze parti e altro ancora. Questi fattori giocheranno senza dubbio nella scelta del modello accessibile, ma dovresti anche pensare alle persone che creano il contenuto. Il modello accessibile che scegli deve essere costruito in modo sufficientemente solido da gestire eventuali limitazioni relative ai contenuti generati dall'editor e/o dagli utenti.

Valutazione dei modelli per l'accessibilità

Il codice spesso parla più forte delle parole, ma prima di entrare in tutto questo, una breve nota che i seguenti esempi di schemi non sono gli unici schemi disponibili per ogni situazione, né quello ritenuto "migliore" nel gruppo è l'opzione migliore nel intero mondo di modelli accessibili.

Per le demo dei pattern di seguito, dovremmo immaginare una situazione ipotetica in cui stiamo confrontando ciascun gruppo di pattern con se stessi. Sebbene questa non sia una situazione realistica, eseguire questi esercizi di pensiero critico e valutare i modelli per l'accessibilità dovrebbe aiutarti a essere più preparato quando incontri la scelta del modello nel mondo reale.

Modelli di pulsanti accessibili

Il primo gruppo di modelli che esamineremo per l'accessibilità è onnipresente in quasi tutti i siti Web o app: i pulsanti. Il primo modello di pulsante utilizza il ruolo del pulsante ARIA per simulare un pulsante, mentre il secondo e il terzo modello di pulsante utilizzano l'elemento HTML <button> . Il terzo modello aggiunge anche aria-describedby e CSS per nascondere le cose visivamente.

Bene: role="button"

 <a role="button" href="[link]">Sign up</a>

Meglio: <button>

 <button type="button">Sign up</button>

Migliore: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Sebbene i primi schemi sembrino semplici a prima vista, evocano alcune domande sull'accessibilità. Ad esempio, sul primo pattern di pulsanti, vediamo che ARIA role="button" è usato sul pattern "good" invece di un elemento HTML <button> . Pensando in termini di accessibilità, poiché sappiamo che l'elemento HTML <button> è stato introdotto in HTML4, possiamo ragionevolmente ipotizzare che sia pienamente supportato dalle ultime versioni di tutti i principali browser e funzionerà bene con la maggior parte dei dispositivi AT. Ma se scaviamo più a fondo e osserviamo il supporto per l'accessibilità per ARIA role=“button” vediamo un leggero vantaggio dal punto di vista della tecnologia assistiva, mentre l'elemento HTML <button> manca di alcune aree di copertura del browser + AT, specialmente se consideriamo supporto per il controllo vocale.

Allora perché il pattern ARIA non è nella categoria "migliore"? ARIA non lo rende più accessibile? No. Infatti, in casi come questo, i professionisti dell'accessibilità spesso recitano la prima regola di ARIA — non usare ARIA. Questo è un modo ironico per dire di usare gli elementi HTML quando possibile. ARIA è davvero potente, ma nelle mani sbagliate può fare più male che bene. In effetti, il rapporto WebAIM Million afferma che "le pagine con ARIA presente avevano in media il 60% di errori in più rispetto a quelle senza". Pertanto, devi sapere cosa stai facendo quando usi ARIA.

Un altro sciopero contro l'utilizzo di ARIA in questa situazione è che la funzionalità del pulsante di cui abbiamo bisogno dovrebbe essere creata per il pattern role="button" , mentre quella funzionalità è già preimpostata nell'elemento <button> . Considerando che l'elemento <button> ha anche il supporto del browser al 100% ed è un modello facile da implementare, è leggermente più avanti nella gerarchia quando si valutano i primi due modelli. Si spera che questo confronto aiuti a sfatare il mito secondo cui l'aggiunta di ARIA rende uno schema più accessibile - spesso è vero il contrario.

Il terzo modello di pulsante mostra l'elemento HTML <button> accoppiato con aria-describedby collegato a un elemento ID che è visivamente nascosto con CSS. Sebbene questo schema sia leggermente più complesso, aggiunge molto in termini di contesto creando una relazione tra il pulsante e lo scopo. In caso di dubbio, ogni volta che possiamo aggiungere più contesto alla situazione, meglio è, quindi possiamo presumere che se codificato correttamente, è il modello migliore quando si confrontano solo questi modelli di pulsanti specifici.

Modelli di collegamento contestuali accessibili

Il secondo gruppo di modelli che esamineremo sono i collegamenti contestuali. Questi modelli aiutano a fornire più informazioni agli utenti AT rispetto a quelle visibili sullo schermo. Il primo modello di collegamento utilizza CSS per nascondere visivamente le informazioni contestuali aggiuntive. Mentre il secondo e il terzo modello di collegamento aggiungono attributi ARIA al mix: aria-labelledby e aria-label , rispettivamente.

Buono: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Meglio: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Migliore: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Sebbene tutti e tre i modelli di collegamento contestuali abbiano lo stesso aspetto, quando ispezioniamo il codice o li testiamo con dispositivi AT, ci sono alcune ovvie differenze. Il primo modello utilizza una tecnica CSS per nascondere visivamente il contenuto per gli utenti vedenti, ma rende comunque il contenuto nascosto per gli utenti AT non vedenti. E mentre questa tecnica dovrebbe funzionare nella maggior parte dei casi, non c'è una vera relazione formata tra il collegamento e le informazioni aggiuntive, quindi la connessione è nella migliore delle ipotesi provvisoria. In quanto tale, il primo schema di collegamento è una scelta OK ma non il modello di collegamento più robusto dei tre.

I prossimi due schemi di collegamento sono un po' più difficili da valutare. Secondo le specifiche ARIA del W3C “Lo scopo di aria-label è lo stesso di aria-labelledby . Fornisce all'utente un nome riconoscibile dell'oggetto. Quindi, in teoria, entrambi gli attributi dovrebbero avere la stessa funzionalità di base.

Tuttavia, le specifiche sottolineano anche che i programmi utente danno la precedenza ad aria-labelledby su aria-label quando decidono quale nome accessibile trasmettere all'utente. La ricerca ha anche mostrato problemi relativi alla traduzione automatica e agli attributi dell'etichetta aria. Quindi questo significa che dovremmo usare aria-labelledby , giusto?

Beh, non così in fretta. Le stesse specifiche ARIA continuano dicendo: "Se l'interfaccia è tale che non è possibile avere un'etichetta visibile sullo schermo (o se un'etichetta visibile non è l'esperienza utente desiderata), gli autori dovrebbero usare aria-label e non dovrebbero usa aria-labelledby .” Parla di confusione, quindi quale modello dovremmo scegliere?

Se avessimo esigenze di traduzione su larga scala, potremmo decidere di cambiare l'aspetto visivo e scrivere i collegamenti con il contesto completo visualizzato (ad es. " Leggi di più su questa cosa fantastica ") o decidere di utilizzare aria-labelledby . Tuttavia, supponiamo di non avere esigenze di traduzione su larga scala o di poter soddisfare tali esigenze in un modo ragionevole/accessibile e di non voler cambiare l'aspetto visivo – e allora?

Sulla base delle attuali raccomandazioni di ARIA 1.1 (con la promessa della traduzione di aria-label in ARIA 1.2) oltre al fatto che aria-label è un po' più facile da implementare per gli sviluppatori rispetto ad aria-labelledby , potremmo decidere di soppesare aria-label su aria-labelledby nella nostra valutazione del modello. Questo è un chiaro esempio di quando il contesto pesa molto nella nostra scelta di modelli accessibili.

Pattern <svg> accessibili

Ultimo, ma certamente non meno importante, esaminiamo un gruppo di modelli di immagini SVG per l'accessibilità. Gli SVG sono una rappresentazione visiva del codice, ma lo stesso codice. Ciò significa che un dispositivo AT potrebbe saltare un'immagine SVG non decorativa a meno che non venga aggiunto role="img" al pattern.

Supponendo che i seguenti modelli SVG siano di natura informativa, in ciascuno è stato incluso un role="img" . Il primo modello SVG utilizza <title> e <text> insieme a CSS per nascondere visivamente il contenuto agli utenti vedenti. I successivi due pattern SVG coinvolgono gli elementi <title> e <desc> , ma con un attributo aria-labelledby aggiunto all'ultimo pattern.

Bene: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Meglio: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Migliore: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Diamo prima un'occhiata al primo pattern usando <title> e <text> e CSS visivamente nascosti. A differenza del precedente testo visibilmente nascosto nei pattern, esiste una relazione intrinseca tra gli elementi <title> e <text> poiché sono raggruppati sotto lo stesso ombrello di elementi SVG. Tuttavia, questa relazione non è molto forte. In effetti, se guardi indietro alla mia ricerca sui modelli SVG, vediamo che solo 3 su 8 combinazioni browser/AT hanno ascoltato il messaggio completo. (Nota: lo schema del maiale n. 1 è equivalente allo schema della lampadina n. 7.)

Questo è vero anche se le specifiche di lavoro del W3C SVG definiscono l'elemento <text> come “un elemento grafico costituito da testo... i caratteri da disegnare sono espressi come dati di caratteri. Di conseguenza, i dati di testo nel contenuto SVG sono facilmente accessibili agli ipovedenti". Questo primo schema va bene, ma possiamo fare di meglio.

Il secondo modello rimuove l'elemento <text> e lo sostituisce con un elemento <desc> . Le specifiche del W3C SVG affermano:

"L'elemento figlio <title> rappresenta un'alternativa di testo breve per l'elemento... e l'elemento <desc> rappresenta informazioni testuali più dettagliate per l'elemento, ad esempio una descrizione."

Ciò significa che gli elementi <title> e <desc> negli SVG possono essere usati in modo simile al testo alternativo dell'immagine e alle opzioni di descrizione lunga che si trovano tradizionalmente negli elementi <img> . Dopo aver aggiunto l'elemento <desc> al secondo SVG, vediamo un supporto browser/AT simile con 3 combinazioni su 8 che ascoltano il messaggio completo. (Nota: il modello di maiale n. 2 è equivalente al modello di lampadina n. 10.) Sebbene questi risultati del test sembrino rispecchiare il primo modello, il motivo per cui questo modello ottiene un urto nella categoria "migliore" è che è leggermente più facile implementare il codice- saggio e ha un impatto su più utenti AT, poiché funzionava su JAWS, VoiceOver desktop e VoiceOver mobile, mentre il primo modello supportava combinazioni browser/AT meno popolari.

Il terzo pattern usa di nuovo gli elementi <title> e <desc> ma ora ha aria-labelledby plus ID aggiunto al mix. Secondo gli stessi test SVG, l'aggiunta di questo pezzo aggiuntivo di codice significa che possiamo supportare completamente 7 su 8 combinazioni browser/AT. (Nota: il modello Pig n. 3 è equivalente al modello lampadina n. 11.) Dei tre modelli SVG, questo terzo è il "migliore" poiché supporta la maggior parte dei dispositivi AT. Ma questo modello ha uno svantaggio nell'usare alcune combinazioni browser/AT; ascolterai il titolo dell'immagine/il contenuto della descrizione duplicati per questo modello. Anche se potenzialmente fastidioso per gli utenti, direi che generalmente è meglio ascoltare contenuti duplicati piuttosto che nessuno.

Pensieri di chiusura

Mentre tutti apprezziamo sicuramente la scelta nella tecnologia, mi chiedo se siamo arrivati ​​a un punto nel tempo in cui la sovrabbondanza di opzioni ci ha lasciato paralizzati e confusi su cosa fare dopo? In termini di selezione di modelli accessibili, possiamo porre domande dirette su opzioni di modelli/librerie, supporto browser/dispositivo AT, limitazioni del framework e altro ancora.

Con i dati giusti in mano, è abbastanza facile rispondere a queste domande. Tuttavia, diventa un po' più complicato quando andiamo oltre gli schemi e consideriamo davvero le persone che li usano. È allora che ci rendiamo conto dell'impatto che le nostre scelte hanno sulla capacità dei nostri utenti di avere successo. Come afferma eloquentemente il Prof. George Dei:

"L'inclusione non sta portando le persone in ciò che già esiste, sta creando un nuovo spazio, uno spazio migliore per tutti".

Prendendo un po' più di tempo per pensare in modo critico ai modelli e scegliere quelli più accessibili, creeremo senza dubbio uno spazio più inclusivo per raggiungere più utenti, alle loro condizioni.

Risorse correlate

Utensili

• Supporto per l'accessibilità, Michael Fairchild, a11ysupport.io
• Accessibilità HTML5, Steve Faulkner

Librerie di modelli

• Progetto di accessibilità
• Guida allo stile di accessibilità
• Componenti accessibili, Scott O'Hara
• Plug-in di riordino elenco drag-and-drop accessibile, Harris Schneiderman
• Libreria di modelli ARIA di Deque
• Libreria React accessibile di Deque
• Sistema di progettazione GOV.UK
• Componenti inclusi, Heydon Pickering
• Sistema di progettazione web statunitense (USWDS)
• Esercitazioni sull'accessibilità del Web