L’accessibilità di WAI-ARIA

Un benchmark per i test di accessibilità#section1

Questo è il motivo per cui la tedesca BITV-Test (BITV è il regolamento federale tedesco che controlla l’accessibilità nell’information technology) ordina di utilizzare un browser datato (attualmente Internet Explorer 7) che è tipicamente usato in combinazione con uno screen reader datato come JAWS 8, che non supporta ancora WAI-ARIA.

Per ragioni pratiche il BITV-Test non richiede test con gli screen reader. Tuttavia, i suoi checkpoint considerano i limiti delle tecnologie assistive più vecchie. Il test abbasserà il punteggio dei siti i cui autori fanno affidamento su WAI-ARIA: ad esempio, implementando delle widget tali da essere inaccessibili per gli utenti degli screen reader più vecchi come JAWS 8.

Il dubbio rimane: i test di accessibilità devono accontentarsi di una combinazione datata di browser e tecnologia assistiva che non supporta ancora WAI-ARIA? Questo non fa da disincentivo per i web developers che adottano WAI-ARIA per far diventare le applicazioni web dinamiche richieste dai clienti qualcosa che sia altrettanto utilizzabile dagli utenti non vedenti?

Dobbiamo fare alcuni passi indietro per rispondere a questa domanda. Per prima cosa, cosa ci dicono le Web Content Accessibility Guidelines (WCAG) 2.0 riguardo il supporto di accessibilità richiesto dalle tecnologie come WAI-ARIA? Secondo punto: com’è il supporto attuale dei browser e degli screen reader per WAI-ARIA? Ed infine, quali sono gli ostacoli pratici per utilizzare WAI-ARIA sul posto di lavoro?

L’“Accessibility support” secondo le WCAG 2.0#section2

Per usare una metafora, l’“accessibility support” è un ponte con due arcate. Solo se entrambe le arcate sono presenti, gli utenti delle tecnologie assistive possono accedere a tutta l’informazione che è a disposizione degli utenti senza disabilità.

Il primo arco è la tecnologia web che si usa. I web designer che si attengono alla specifica WAI-ARIA e alle Authoring Practices raccomandate possono assicurare che il loro contenuto è potenzialmente accessibile.

Perché “potenzialmente”? Perché manca ancora la seconda arcata: gli user agent adatti. I browser e gli screen reader devono essere ridisegnati o modificati per essere in grado di funzionare effettivamente con le nuove tecnologie web. Le versioni più vecchie potrebbero semplicemente fare fiascho.

Quindi dichiarare “accessibility supported” una particolare tecnologia web non è semplicemente un problema di completamento dello standard. Dobbiamo anche misurare il grado di penetrazione degli user agent più nuovi che supportano tale tecnologia in un dato contesto d’uso. La situazione tende a variare considerevolmente tra le diverse contee, linguaggi ed ambienti d’uso. In una sezione su Understanding Accessibility Support [“Capire l’accessibility support“, ndt], il WCAG Working Group ed il W3C pertanto

non specificano quale o quante tecnologie assistive debbano supportare una tecnologia web perché questa sia classificata come accessibility supported.

E

rimanda il giudizio riguardo quanto, quante o quali AT [tecnologie assistive] devono supportare una tecnologia alla comunità e alle entità più vicine a ciascuna situazione.

Mentre un dipartimento IT di un’azienda può assicurare l’accessibility support per la sua intranet, i siti web pubblici forniscono informazioni a una popolazione molto variegata utilizzando un ampio range di user agent e di tecnologie assistive.

Questo è il motivo per cui leWCAG 2.0 dicono chiaramente che:

Creare del contenuto che non può essere usato dal grande pubblico con una qualche disabilità dovrebbe essere evitato.

Se accettiamo questo “grande pubblico” come nostro benchmark, troveremo che attualmente, ci sono ancora molti ostacoli all’uso estensivo di WAI-ARIA.

Il supporto per WAI-ARIA nei browser e nelle tecnologie assistive#section3

Il supporto per alcune parti di WAI-ARIA, come i document landmark, è già abbastanza buono nelle ultime versioni dei browser e degli screen reader. Tuttavia rimangono ancora molti problemi.

Supporto irregolare tra le tecnologie assistive#section4

Il supporto per WAI-ARIA è ancora lacunoso in molte combinazioni di screen reader/browser là fuori, ad esempio, guardate (l’abbastanza datato) WAI-ARIA tests on code talks. Il solo numero di tipi e versioni di browser e tecnologie assistive rende arduo stimare un dato livello di supporto. E fornire dei workaround per alcuni bug degli screen reader può rendere la vita difficile agli utenti di altri browser e screen reader più compliant.

Gli utenti non vedenti che non hanno il supporto per WAI-ARIA potrebbero semplicemente non riconoscere una web widget se il suo ruolo WAI-ARIA non è esposto. Prendete un tab panel implementato secondo le best practices di WAI-ARIA: lo screen reader non dirà agli utenti che sono appena entrati in un tab panel e possono adesso usare i tasti freccia per muoversi tra le tab, così gli utenti probabilmente si sposteranno con il tab oltre il contenuto del tab panel. Ed il cambio di focus programmato con uno script per la navigazione con i tasti freccia tra le tab potrebbe non funzionare: intere sezioni sotto ai tab possono diventare inaccessibili.

Non dobbiamo dimenticarci degli utenti “visually impaired”. Le attuali versioni di alcuni tra i più popolari screen magnifier non supportano WAI-ARIA. ZoomText evidentemente non è nemmeno a conoscenza dell’esistenza di WAI-ARIA. Freedom Scientific offrirà un supporto parziale in MAGic a partire dalla prossima versione (adesso siamo alla 11.0). Il supporto in HAL e Supernova di Dolphin è atteso per la version 12.5.

Usi corretti e scorretti di WAI-ARIA#section5

Al momento, molte implementazioni non sono conformi alle WAI ARIA best practices per fare in modo che funzionino come nelle intenzioni della specifica. Gli errori di programmazione di WAI-ARIA possono in effetti deteriorare l’accessibilità di una widget. Quello che contribuisce alla complessità della programmazione è che la semantica nativa degli elementi HTML può essere in conflitto con la semantica aggiunta tramite i WAI-ARIA roles.

L’interazione di questi problemi fa in modo che progettare con WAI-ARIA sia una questione delicata. I web developer, pertanto, si sono messi ad usare i test con gli screen reader per assicurarsi che i loro progetti funzionino correttamente per un certo range di tecnologie assistive (per cominciare, lo screen reader NVDA è gratis ed è semplice da installare).

Implicazioni delle widget per gli utenti da tastiera vedenti#section6

I maggiori benefici di WAI-ARIA riguardano gli utenti non vedenti. Per loro le widget in una pagina web sullo stile di quelle per desktop non sono più inaccessibili, ma la proliferazione di tali widget ha anche delle implicazioni per gli utenti da tastiera vedenti.

Rispetto alle widget per il desktop e le loro convenzioni, le widget “self-styled” sul web sono parecchio differenti. Quelle che sono conformi alle best practices di WAI-ARIA sono rare. Quale sia, ammesso che vi sia, l’interazione da tastiera che una particolare widget mette a disposizione dell’utente si riduce quindi a delle ipotesi.

Di nuovo, consideriamo i tab panels. Non c’è un modo semplice per distinguere una comune barra di navigazione a tab ed una widget con una navigazione a tab panel che si trova più in basso nella pagina. E solo pochi tab panel là fuori offrono la navigazione per mezzo dei tasi freccia invece che con il tab. Gli utenti da tastiera vedenti dovranno provare quale tasto funziona. (Per i non vedenti che usano uno screen reader che supporta WAI-ARIA, c’è in effetti un problema in meno se i ruoli della widget sono annunciati nello stesso modo che nelle desktop widget).

Un altro punto critico è che le widget custom dipendono dai fogli di stile per il posizionamento dei loro elementi. Senza CSS o visti con un foglio di stile personalizzato, queste widget si disintegrano e non sono più utilizzabili. Gli elementi della widget possono apparire due volte o essere molto lontani da quella che era la loro posizione originale. Inoltre, le immagini di background assegnate tramite CSS spariranno (la stessa cosa succede quando si usano degli schemi di colore personalizzati).

Ostacoli all’utilizzo di WAI-ARIA sul posto di lavoro#section7

C’è un insieme piuttosto diversificato di problemi evidenti sul posto di lavoro. Abbastanza spesso i problemi sono fuori dall’influenza dell’utente:

• Molte aziende utilizzando applicazioni internet personalizzate per una particolare combinazione di browser/screen reader. I costi per la personalizzazione spesso sono molto più alti di quelli delle licenze per screen reader o degli aggiornamenti. I buchi di sicurezza noti (come in Internet Explorer 7) possono necessitare di aggiornamento, ma questo argomento non è sufficiente se le applicazioni sono (o dovrebbero essere) usate sono su una intranet.
• Molte aziende usano ancora vecchi sistemi operativi come Windows 2000, che non è compatibile con le versioni più recenti dei browser, come IE8 e, a seguire, con le versioni di screen reader più recenti. Per le applicazioni e le tecnologie assistive che supportano procedure meccaniche non c’è un vero incentivo all’aggiornamento a meno che il workflow o degli importanti aggiornamenti di sistema lo richiedano.
• Molti utenti di computer non vedenti che usano degli screen reader che supportano WAI-ARIA, come JAWS 9 o le sue versioni più recenti non conoscono o non sono stati istruiti per sfruttarne tutto il potenziale.
• Mentre NVDA e JAWS al momento sono in grado di gestire WAI-ARIA, non dobbiamo dimenticarci degli utenti di altri screen reader meno potenti.

Spesso, una personalizzazione basata sugli script per le tecnologie assistive sul posto di lavoro risponde esattamente a quei controlli personalizzati che WAI-ARIA potrebbe rendere accessibili. Un migliore supporto per WAI-ARIA potrebbe far risparmiare tempo e denaro. Questo, tuttavia, presuppone che durante la creazione di applicazioni web o intranet, gli sviluppatori usino WAI-ARIA in maniera coerente e secondo le best practices.

Chi non ha accesso a degli screen reader WAI-ARIA-capable?#section8

Mentre facevamo delle ricerche per questo articolo, abbiamo preso in considerazione un campione preso da una grande azienda pubblica tedesca. Dei 15 posti di lavoro per non vedenti analizzati, nessuno supportava al momento WAI-ARIA:

• Sette postazioni usano HAL/Lunar (tra la Version 6 e la 10),
• Quattro postazioni usano JAWS 6 e
• Quattro postazioni usano Blindows (tra la Version 2 e la 4).

Ovviamente, la situazione potrebbe essere migliore in altri posti di lavoro. Nonostante ciò, il campione indica e una grande, forse molto grande, percentuale di persone non vedenti al momento non ha, sul posto di lavoro, accesso a degli user agent che supportano WAI-ARIA.

Indagini e statistiche d’uso#section9

Sfortunatamente, non ci sono statistiche che possono quantificare in maniera affidabile quanti utenti hanno degli screen reader WAI-ARIA-capable. Stando alla WebAIM screen reader survey (Ottobre 2009), lo 83,6% degli utenti aggiorna il proprio screen reader entro un anno dal rilascio di una nuova versione. Concentrandoci per un attimo solo su JAWS e considerando le molteplici release di JAWS dopo la prima versione dotata di supporto per WAI-ARIA del Novembre 2007, la percentuale di utenti che sta ancora usando JAWS 8 dovrebbe essere inferiore al 5%. Tuttavia, la survey rispecchia solo il mercato americano, la cui situazione è diversa da quella che c’è in Germania. Inoltre, è probabile che una percentuale più alta di utenti di screen reader che ha risposto alla survey appartenesse alla categoria degli utenti esperti e pertanto utenti pionieri. Possiamo ipotizzare che la media del tasso di aggiornamento fra tutti gli utenti sia molto inferiore.

Modi non problematici per l’utilizzo di WAI-ARIA#section10

Molte applicazioni di WAI-ARIA hanno come scopo l’arricchimento del HTML per correggere alcuni deficit semantici. Dal momento che HTML 4 non ha degli elementi espliciti per marcare le regioni di una pagina, la specifica WAI-ARIA offre i cosiddetti “document landmarks”. Ad esempio, possiamo assegnare ad un semplice div il role="navigation" ed esporre il contenuto principale della pagina con role="main". Questo permette agli utenti di screen reader che supportano WAI-ARIA di muoversi rapidamente tra le differenti regioni della pagina.

Altri attributi migliorano il markup delle form. Ad esempio, possiamo assegnare ad un elemento input l’attributo aria-required="true" per comunicare agli utenti di screen reader che il campo richiede che venga inserito qualcosa prima che la form possa essere inviata. Le ARIA live regions sono un altro utile costrutto che informa gli utenti di screen reader riguardo i cambiamenti dinamici all’interno della pagina senza perdere l’attuale focus da tastiera.

Le pagine arricchite semanticamente attraverso WAI-ARIA al momento non vengono validate, ma questo questo è uno svantaggio accettabile: i browser comuni non hanno problemi con il markup aggiuntivo (Il passo di validazione del codice del BITV test mantiene un’eccezione per gli errori di validazione causati dal markup WAI-ARIA). Alcuni siti attualmente aggirano il problema di validazione aggiungendo degli attributi WAI-ARIA al codice sorgente attraverso uno script che viene eseguito quando si carica una pagina.

Più problematico: le widget personalizzate#section11

La specifica WAI-ARIA supporta un range di widget di controllo dell’interfaccia personalizzate utilizzate comunemente nelle applicazioni desktop, così che gli autori le possano usare nelle applicazioni web-based (una lista completa è contenuta in WAI-ARIA Roles Model).

Estensione degli elementi standard#section12

Gli autori spesso puntano ad estendere il comportamento degli elementi standard: ad esempio, per creare una checkbox a tre stati o un elemento select che possa anche accettare del testo di input (il combobox). Per ottenere ciò, gli elementi noti di HTML vengono ricreati dando un nuovo scopo ad elementi non semantici, come div o img, (sostituendo questi al momento della richiesta attraverso degli script che riflettono i vari stati), usando contemporaneamente WAI-ARIA per informare la tecnologia assistiva sui ruoli e sugli stati designati.

Widget personalizzate self-styled#section13

Poi ci sono le widget personalizzate che i web designer hanno creato per un po’ di tempo: le widget che WAI-ARIA dovrebbe ora rendere accessibili, inclusi i pulldown menu, i tabpanels, gli alberi gerarchici, gli slider, gli spinbutton e perfino le interfacce drag-and-drop. Il comportamento da tastiera desiderato per la widget non è come il comportamento di default dei normali elementi HTML che possono avere il focus: deve essere esplicitamente definito attraverso JavaScript. Questo costituisce il primo problema, dal momento che per molte widget personalizzate non c’è un comportamento standard in risposta all’input da tastiera. Cosa funziona e cosa no deve essere stabilito empiricamente dall’utente.

La mancanza di robustezza di WAI-ARIA è un altro problema: la sua implementazione nei browser e nelle tecnologie assistive non è ancora stabile. A volte servono dei trucchi per essere certi che una widget funzioni come desiderato, come in un piccolo ritardo programmato con uno script per assicurare che gli elementi aggiunti all’alberatura DOM ricevano effettivamente il focus dagli script.

Opzioni di fallback per gli utenti senza supporto per WAI-ARIA#section14

Non è possibile, allora, fornire delle opzioni di fallback per gli user agent che non supportano WAI-ARIA? Nella trattazione del role presentation, il documento WAI-ARIA Roles dice che esso “può essere usato per fornire un fallback accessibile nei browser più vecchi che non supportano WAI-ARIA.”

Guardandoci in giro, mancano degli esempi pratici di tali soluzioni di fallback. E’ difficile pensare ad alcuna applicazione utile. Considerate una checkbox personalizzata con una checkbox nativa come opzione di fallback per gli utenti di screen reader che non supportano WAI-ARIA: tolta dallo schermo con CSS per nasconderla agli utenti senza disabilità visive e marcata con role="presentation" per nasconderla ai browser WAI-ARIA-capable.

Funziona? Il ruolo presentation sopprime gli attributi WAI-ARIA (tranne gli attributi globali) ma espone ancora gli elementi che possono avere il focus come i checkbox. La WAI-ARIA 1.0 User Agent Implementation Guide dice chiaramente:

…l’elemento deve essere ancora esposto se (…) può avere il focus, così che gli eventi focus possano essere attivati (il focus non deve mai essere perso)

Pertanto, per gli utenti di screen reader senza supporto per WAI-ARIA ma con JavaScript attivato la checkbox personalizzata riceveranno il focus ma non riveleranno il loro ruolo ed il loro stato. Per gli utenti di screen reader con il supporto per WAI-ARIA, la non necessaria checkbox di fallback non annuncerà il suo ruolo, ma sarà ancora nel tab order, sarà selezionabile e cambierà il suo stato dopo la selezione. Infine, gli utenti dotati di vista saranno in grado di usare la custom checkbox, ma probabilmente anche spostarsi con il tab e attivare la checkbox nascosta senza alcun feedback visivo. Questo ovviamente non ha senso.

WAI-ARIA nelle librerie UI di JavaScript#section15

Molti designer che attingono le funzionalità di JavaScript dalle famose librerie UI di JavaScript implementeranno implicitamente WAI-ARIA, dal momento che queste librerie stanno aggiungendo il supporto alle loro widget e ai loro componenti. La situazione è disparata. Si dice che Dojo offra un supporto maturo per WAI-ARIA, YUI offre dei plugin di ARIA per un certo assortimento di widget; ci si aspetta il supporto completo per WAI-ARIA a partire dalla release 2.0 di JQuery. Altre librerie, comunque, o non la supportano o ne hanno un supporto limitato.

L’inclusione di WAI-ARIA nelle librerie UI di JavaScript è una buona cosa dal momento che ci sono motivi per aspettarsi qui un’implementazione di WAI-ARIA conforme alle ”best practices”. Tuttavia, rimane il fatto che a livello degli hardware e dei software attualmente in uso, il supporto di accessibilità di WAI-ARIA non può esser dato per scontato.

Raccomandazioni#section16

Gli elementi HTML semantici appropriati, quando sono disponibili, sono da preferirsi all’utilizzo di widget personalizzate ottenute con JavaScript e WAI-ARIA. La difficoltà di dare uno stile in maniera consistente agli elementi nativi con CSS potrebbe sembrare un punto dolente per i web designer: a vantaggio degli utenti, gli elementi dell’interfaccia saranno più riconoscibili e prevedibili quando avranno semplicemente l’aspetto e la funzionalità come quella degli elementi di sistema noti.

I designer dovrebbero controllare se le widget personalizzate complesse possono essere sostituite da elementi nativi più semplici. E’ davvero necessario usare una combobox per una funzione di autocompletamento? Davvero non si può evitare di avere una checkbox a tre stati? I radio button con dei valori discreti possono rimpiazzare uno slider?

Non stiamo spingendo verso l’austerità del design delle interfacce utente. Si fanno pochi danni usando dei controlli elaborati se viene fornita una loro versione alternativa accessibile. Prendete, ad esempio, uno slider che gli utenti possono spostare con il mouse per impostare la somma che vogliono donare a SOS-Kinderdorf, un’organizzazione nell’ambito della beneficenza molto nota. Controllate il secondo passaggio del processo di donazione a SOS-Kinderdorf (progettato da Aperto AG). A seconda della somma specificata, una piccola bambina sulla destra esprime la sua gratitudine in termini moderati o calorosi (in tedesco). A quanto pare, la generosità è aumentata molto dopo l’introduzione dello slider, il che dovrebbe essere una prova sufficiente della sua utilità.

Sebbene fosse possibile far funzionare lo slider per gli utenti di screen reader con il supporto per WAI-ARIA, i designer hanno preferito come alternativa un semplice input testuale per la somma da donare: l’ordine di tab per il focus salta semplicemente lo slider. E’ importante la reazione della bambina nella nuvoletta della battuta, che viene azionata da entrambe i tipi di input.

Riassumiamo. E’ abbastanza chiaro che JavaScript è diventato onnipresente e che WAI-ARIA è una soluzione benvenuta per gestire il gap di accessibilità che questo sviluppo ha creato. Gli sviluppatori che oggi utilizzano WAI-ARIA possono essere d’aiuto per eliminare i bug di implementazione presenti nei browser e nelle tecnologie assistive. Allo stesso tempo, possono contribuire alle best practices con degli esempi che possono essere usati da molti altri come modello.

Ma finché le combinazioni di vecchi screen reader/browser che non sono in grado di interpretare WAI-ARIA continueranno a costituire una parte significativa delle installazioni, i designer che hanno a cuore l’accessibilità devono usare il markup WAI-ARIA solo per arricchire i loro siti. Non dovrebbero fare affidamento solo su di esso.

Illustrazioni: {carlok}

Ringraziamenti#section17

Per i suggerimenti ed i commenti, ringrazio molto Carsten Albrecht, Alexander Farkas, Michael Große-Drenkpohl, Jan-Eric Hellbusch, Werner Hoog, Martin Kliehm, Werner Krauße, Oliver Nadig, Hans-Herbert Suhling, Timo Wirth, Tiffany Wyatt e Marco Zehe.

Traduzioni: Tedesco.

Risorse utili#section18

• WCAG 2.0 Understanding Conformance—Understanding Accessibility Support Questa sezione delle WCAG 2.0 descrive il concetto di supporto di accessibilità ed elenca i success criteria.
• WAI-ARIA Overview: An introduction of the W3C Web Accessibility Initiative into WAI-ARIA
• WAI-ARIA 1.0 User Agent Implementation Guide
• WAI-ARIA 1.0 Authoring Practices
• Introduction to WAI ARIA di Gez Lemon
• The DHTML Style Guide. Il DHTML Style Guide Working Group (DSGWG) ha creato una recommendation per le scorciatoie da tastiera che devono essere usate nelle widget all’interno dei siti web.
• Using WAI ARIA Landmark Roles di Steve Faulkner (Paciello Group Blog). Include un confronto tra gli ARIA landmarks e gli elementi strutturali di HTML5.
• An HTML5 plus ARIA “Sanity Check”: Working Around Bugs in AT di Jason Kiss descrive alcuni dei problemi con i bug nelle tecnologie assistive quando si usano gli ARIA landmarks in HTML5.
• WebAIM Screen reader Survey: A survey of the preferences of screen reader users. Questa risorsa contiene anche delle statistiche sui software per gli screen reader e le abitudini degli utenti per quel che riguarda gli upgrade.
• C’è anche un follow-up della statistica sull’uso degli screen reader.
• Code Talks: Set of ARIA Test Cases. Non molto recente: molte combinazioni di browser/screen reader non sono state testate.
• Marco’s accessibility blog. Il blog di Marco Zehe copre diverse tecniche di WAI-ARIA che migliorano l’accessibilità e l’usabilità per gli utenti non vedenti, spesso basate su un software della Mozilla Foundation. Piuttosto datato (Luglio 2009): The WAI-ARIA Windows screen reader shootout (in Firefox 3.5)