{"id":127,"date":"2010-12-14T19:05:19","date_gmt":"2010-12-14T18:05:19","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/accessibilita-di-wai-aria\/"},"modified":"2010-12-14T19:05:19","modified_gmt":"2010-12-14T18:05:19","slug":"accessibilita-di-wai-aria","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/accessibilita-di-wai-aria\/","title":{"rendered":"L’accessibilit\u00e0 di WAI-ARIA"},"content":{"rendered":"

I web developers che si interessano di problemi di accessibilit\u00e0 discutono spesso di WAI-ARIA<\/a>, una candidate recommendation del W3C che verr\u00e0 presto pubblicata, il cui scopo \u00e8 quello di rendere le applicazioni web pi\u00f9 accessibili ai non vedenti e alle persone con disabilit\u00e0 visive. Ma si pu\u00f2 raccomandare WAI-ARIA senza riserve?<\/p>\n

La comunit\u00e0 dell’accessibilit\u00e0 ha dato il benvenuto allo sviluppo di WAI-ARIA. Chiaramente, presenta molti benefici per gli utenti di screen reader. Prima, quando le pagine web venivano aggiornate dinamicamente, gli utenti di screen reader non potevano accorgersi del cambiamento o, in altri casi, venivano buttati in cima alla pagina. Ora, WAI-ARIA \u00e8 in grado di informare lo screen reader sui cambi dinamici. Possiamo creare delle widget complesse e personalizzate, come i menu pulldown, i tab panel, gli alberi gerarchici o gli slider, rendendoli accessibili tramite mappatura dei loro elementi ai ruoli, alle propriet\u00e0 e agli stati definiti nello standard e supportati dalle API di accessibilit\u00e0 del sistema, ammesso che gli utenti abbiano delle versioni recenti dei browser e degli screen reader che supportino lo standard.<\/p>\n

Molti utenti, per\u00f2, non hanno accesso alle tecnologie pi\u00f9 recenti e migliori. Pertanto, i test di accessibilit\u00e0 si basano tipicamente su software che \u00e8 probabile che gli \u201cutenti l\u00e0 fuori\u201d incontrino sul loro posto di lavoro.<\/p>\n

\n

Un benchmark per i test di accessibilit\u00e0<\/h2>\n

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

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

Il dubbio rimane: i test di accessibilit\u00e0 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?<\/p>\n

Dobbiamo fare alcuni passi indietro per rispondere a questa domanda. Per prima cosa, cosa ci dicono le Web Content Accessibility Guidelines (WCAG) 2.0<\/a> riguardo il supporto di accessibilit\u00e0 richiesto dalle tecnologie come WAI-ARIA? Secondo punto: com’\u00e8 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?<\/p>\n<\/div>\n

\n

L’\u201cAccessibility support\u201d secondo le WCAG 2.0<\/h2>\n

Per usare una metafora, l’\u201caccessibility support\u201d<\/a> \u00e8 un ponte con due arcate. Solo se entrambe le arcate sono presenti, gli utenti delle tecnologie assistive possono accedere a tutta l’informazione che \u00e8 a disposizione degli utenti senza disabilit\u00e0.<\/p>\n

Il primo arco \u00e8 la tecnologia web che si usa. I web designer che si attengono alla specifica WAI-ARIA e alle Authoring Practices<\/a> raccomandate possono assicurare che il loro contenuto \u00e8 potenzialmente accessibile.<\/p>\n

Perch\u00e9 \u201cpotenzialmente\u201d? Perch\u00e9 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\u00f9 vecchie potrebbero semplicemente fare fiascho.<\/p>\n

Quindi dichiarare \u201caccessibility supported\u201d una particolare tecnologia web non \u00e8 semplicemente un problema di completamento dello standard. Dobbiamo anche misurare il grado di penetrazione degli user agent pi\u00f9 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<\/a> [\u201cCapire l’accessibility support\u201c, ndt<\/em>], il WCAG Working Group ed il W3C pertanto<\/p>\n

\n

non specificano quale o quante tecnologie assistive debbano supportare una tecnologia web perch\u00e9 questa sia classificata come accessibility supported.<\/p>\n<\/blockquote>\n

E<\/p>\n

\n

rimanda il giudizio riguardo quanto, quante o quali AT [tecnologie assistive] devono supportare una tecnologia alla comunit\u00e0 e alle entit\u00e0 pi\u00f9 vicine a ciascuna situazione.<\/p>\n<\/blockquote>\n

Mentre un dipartimento IT di un’azienda pu\u00f2 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.<\/p>\n

Questo \u00e8 il motivo per cui leWCAG 2.0 dicono chiaramente che<\/a>:<\/p>\n

\n

Creare del contenuto che non pu\u00f2 essere usato dal grande pubblico con una qualche disabilit\u00e0 dovrebbe essere evitato.<\/p>\n<\/blockquote>\n

Se accettiamo questo \u201cgrande pubblico\u201d come nostro benchmark, troveremo che attualmente, ci sono ancora molti ostacoli all’uso estensivo di WAI-ARIA.<\/p>\n<\/div>\n

\n

Il supporto per WAI-ARIA nei browser e nelle tecnologie assistive<\/h2>\n

Il supporto per alcune parti di WAI-ARIA, come i document landmark, \u00e8 gi\u00e0 abbastanza buono nelle ultime versioni dei browser e degli screen reader. Tuttavia rimangono ancora molti problemi.<\/p>\n

Supporto irregolare tra le tecnologie assistive<\/h3>\n

Il supporto per WAI-ARIA \u00e8 ancora lacunoso in molte combinazioni di screen reader\/browser l\u00e0 fuori, ad esempio, guardate (l’abbastanza datato) WAI-ARIA tests on code talks<\/a>. 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<\/a> pu\u00f2 rendere la vita difficile agli utenti di altri browser e screen reader pi\u00f9 compliant.<\/p>\n

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 \u00e8 esposto. Prendete un tab panel implementato secondo le best practices di WAI-ARIA: lo screen reader non dir\u00e0 agli utenti che sono appena entrati in un tab panel e possono adesso usare i tasti freccia per muoversi tra le tab, cos\u00ec 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.<\/p>\n

Non dobbiamo dimenticarci degli utenti \u201cvisually impaired\u201d. Le attuali versioni di alcuni tra i pi\u00f9 popolari screen magnifier non supportano WAI-ARIA. ZoomText evidentemente non \u00e8 nemmeno a conoscenza dell’esistenza di WAI-ARIA. Freedom Scientific offrir\u00e0 un supporto parziale in MAGic a partire dalla prossima versione (adesso siamo alla 11.0). Il supporto in HAL e Supernova di Dolphin \u00e8 atteso per la version 12.5.<\/p>\n

Usi corretti e scorretti di WAI-ARIA<\/h3>\n

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

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<\/a> \u00e8 gratis ed \u00e8 semplice da installare).<\/p>\n

Implicazioni delle widget per gli utenti da tastiera vedenti<\/h3>\n

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\u00f9 inaccessibili, ma la proliferazione di tali widget ha anche delle implicazioni per gli utenti da tastiera vedenti.<\/p>\n

Rispetto alle widget per il desktop e le loro convenzioni, le widget \u201cself-styled\u201d 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.<\/p>\n

Di nuovo, consideriamo i tab panels. Non c’\u00e8 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\u00f9 in basso nella pagina. E solo pochi tab panel l\u00e0 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’\u00e8 in effetti un problema in meno se i ruoli della widget sono annunciati nello stesso modo che nelle desktop widget).<\/p>\n

Un altro punto critico \u00e8 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\u00f9 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).<\/p>\n<\/div>\n

\n

Ostacoli all’utilizzo di WAI-ARIA sul posto di lavoro<\/h2>\n

C’\u00e8 un insieme piuttosto diversificato di problemi evidenti sul posto di lavoro. Abbastanza spesso i problemi sono fuori dall’influenza dell’utente:<\/p>\n