aria
Il modulo aria presente in html5, una tecnologia antica eppure ancora sconosciuta.
Interventi di Donato Taddei su nvda, dal 4\11\2013, h. 10.25.

sono un utente che usa nvda come unico screen-reder da pi di 5 anni.
Penso di aver anche io contribuito alla sua conoscenza.
nella raccolta pcciechi ospitata su Spazio ausili ci sono parecchi miei
interventi sul python.

Ma veniamo all'oggetto:
aria sta per "accessible rich internet application" ed  una delle
componenti che entrer a far parte della specifica definitiva
di html 5.
Aria  un set di informazioni aggiuntive che il browser passa alle api di
accessibilit del sistema cui attingono le tecnologie assistive.
Aria  qualcosa di "particolarmente ignoto" agli sviluppatori di contenuti
ancorch supportato nei principali browser e screen-reader fin dai tempi di
html 4.1. come jaws ed eyes anche nvda ha un suo modulo aria.py.
Obbiettivo finale di aria  rendere le pagine web molto pi simili ad
applicazioni desktop, quindi con la possibilit di inserire nelle pagine
tutti gli oggetti di uso comune delle applicazioni desktop: menu, slider,
barre di progresso, toolbar, toolkip ecc. ed assicurarne la fruizione
tramite tecnologie assistive con le stesse modalit delle applicazioni
desktop.
Per chi fosse interessato a saperne di pi in coda a questo messaggio trova
due miei post su altre liste, in cui racconto il mio incontro con aria e in
tre parole in cosa consiste.

Cosa chiedo da qualche volontario?
Di farsi un giro su un paio di siti che vi indicher, contenenti esempi di
demo di implementazioni aria per molti widgert per sintetizzare un repor
sulla esperienza di navigazione con nvda che non sia il frutto solo della
mia esperienza di uso.
Inoltre, poich quasi tutti siete utenti anche di jaws, non sarebbe male
avere un riscontro anche comparativo.
Chiedo a chi fosse disponibile di contattarmi in privato o, se si ritiene,
in lista.

Per farne che?
Sono riuscito ad impegnare IWA-Italy, alias Scano e compagni, a dedicare una
sezione del sito webaccessibile.org
ad aria in cui potrebbe verosimilmente confluire anche questo nostro lavoro.
Se il caso lo richiedesse, riportare questa esperienza agli sviluppatori dei
tools oggetto di test, nonch agli sviluppatori di nvda.

Il documento w3c di riferimento  :
wai-aria 1.0: Authoring practices"
http://www.w3.org/TR/wai-aria-practices/#accessiblewidget
in particolare il capitoloo 11.

I siti con gli esempi di implementazione da testare sono per ora due, ma
penso basteranno.
universit dell'Illinois e Urbana
Illinois Center for Information Technology and Web Accessibility
http://test.cita.illinois.edu/aria/
OAEG (Open Accessibility Everywhere Group) e commissione europea
http://www.accessiblemootoolsdemo.iao.fraunhofer.de/Mootools_Widgets/

Restando in attesa di riscontro riporto i messaggi relativi ad aria.

                        Don

----- Original Message -----
From: "Donato Taddei" do.taddei@virgilio.it
To: ebooktester@yahoogroups.com
Sent: Thursday, October 31, 2013 3:04 PM
Subject: Re: [ebooktester] Ogg: Ebook da testare

 Livio
 Aria  interessante, ne avevo scritto qui:
 http://www.biroblu.info/2013/10/html-5-wai-aria-che-editor-usare/

 Donato:
 mi ci sono subito fiondato e per poco non ho colto il bersaglio:
 Sto cercando da qualche ora appunto l'elenco dei "roles"  e deggl stati e
 propriet di aria, eventi ecc. giusto per averlo a portata di mano
 all'occorrenza.
 E tu lo hai pure riportato come schermata del griphon, ma  una immagine.
 Ho un po il sospetto che anche per te non  stata agevole la ricerca di un
 siffatto elenco se hai infine optato per questa soluzione.
 in ogni caso, come dicevo ieri, sono molto soddisfatto di questo thread, e
 se fosse capitato quattro mesi fa mi sarebba andato maggiormente a
 fagiolo.

 Infatti avrei avuto bisogno di fare una treeview o, per dirla con uno
 screen-reader, una visualizzazione ad albero, che si comportasse con lo
 screen-reader come le treeview di windows che si incontrano nelle altre
 applicazioni.
 s, perch ad esempio, i menu a discesa realizzati di solito con ul, anche
 nidificati, in realt nella resa del mio screen-reader, si comportano come
 una serie di links, per cui, scrivendo applicazioni innanzitutto per me,
 quando devo proporre scelte multiple all'utente preferisco di gran lunga
 il
 costrutto select - option, che visivamente si presenta in modo diverso da
 un
 menu, ma con gli screen-reader si comporta come un menu a discesa,
 navigabile con le frecce verticali.

 Beh, per farla breve, poich il costrutto select -option non pu essere
 nidificato, e col mio screen-reader optgroup non funziona come dovrebbe,
 mi
 sono dovuto inventare una soluzione un po pi arzigogolata per ottenere
 l'effetto desiderato di un menu contenente altri sottomenu.
 Ora so come implementare un treeview usando aria che mi soddisfi con nvda.
 Voglio pertando segnalare questa utile risorsa per chi fosse interessato.
 oltre a un corso online l'universit dell'Illinois mantiene una sezione
 dedicata ad Aria, nella quale vengono presentati anche alcuni esempi di
 implementazione, e ne viene mostrato il codice html, javascript e css
 relativo,
 http://test.cita.illinois.edu/aria/tree/tree1.php
 tra cui appunto il treeview:
 http://test.cita.illinois.edu/aria/tree/tree1.php

 Questi esempi che sono l da pi di un po sono realizzati in html 4.1 o
 xhtml 1 e per ciascuna implementazione vengono anche riportati i browser
 che
 la supportano.
 Ovviamente se provate a validare il codice di quesi esempi non passano il
 test di validazione perch html 4.1 non prevede gli attributi di Aria,
 mentre passsa la validazione se  in html 5 perch si prevede che anche
 wai-aria entrer a far parte della specifica definitiva di html 5.
 Esaminando questi esempi mi sono convinto che ci sia ancora un po di
 lavoro
 per gli sviluppatori di nvda, la  cui gestione di taluni oggetti trovo
 insoddisfacente, come di quelli annunciati come pulsanti ciclici, pi o
 meno
 onnipresenti sulle pagine di Google.
 Ho trovato per che tramite aria se ne pu migliorare la gestione dei
 pulsanti radio, anch'essa non perfetta, come nell'esempio radio3.
 Auspicherei che risorse come webaccessibile dedicassero degli
 approfondimenti per far conoscere questa tecnologia piuttosto sconosciuta
 agli sviluppatori rampanti, e forse ne scriver a Scano, Castaldo e
 compagni, ma Livio avrebbe pi ascendente di me.
                        Don

  ----- Original Message -----
  From: Donato Taddei
  To: La mailing list di webaccessibile.org
  Sent: Saturday, November 02, 2013 1:10 PM
  Subject: Re: [webaccessibile] UN'ORA D'ARIA PER GLI SVILUPPATORI WEB

  Ok. Dedicherete una apposita sezione.
  Poich per la mia ora d'aria  finita, e tra qualche settimana me ne sar
magari gi scordato,
  spero di non scocciare nessuno se posto queste brevi note in proposito, in
modo schrzoso, proprio perch la cosa p molto seria.

  Quando prendere aria?

  quando esiste una interazione con l'utente, quando il contenuto cambia
dinamicamente, e quando ci si renda conto o solo si sospetti che
quell'oggetto, riquadro, widget, bottone non risponda correttamente
utilizzando le tecnologie assistive.
  Dunque niente tonnellate di complicazioni da digerire ma solo la dovuta
particolare attenzione all'interazione con l'utente, nell'era del web
dinamico.

  Come si fa a pompare aria?

  in presenza di un nodo dom che contenga al suo interno o tra i suoi
discendenti elementi interattivi
  immettere aria in tre modi diversi e/o concorrenti:

  - il noto attributo tabindex usato correttamente: amen;

  - l'attributo role supportato perfettamente dai moderni browser,facendo
attenzione ad aggiungere questo attributo anche a tutti gli elementi
interattivi figli,
  Esso pu assumere una sessantina di valori, immediatamente comprensibili,
perch noti come widget e oggetti interattivi.
  entra qui in ballo la tassonomia dei ruoli:
  in soldoni: se un menu o una toolbar o un gruppo di pulsanti radio ne  il
contenitore, bisogner impostare il relativo attributo role per ciascun
elemento del menu o della toolbar.
  se una div ha come attributo role="menubar"
  dovr contenere un elemento con attributo role="menu",
  il quale a sua volta dovr contenere per  ciascuna voce del menu il
relativo attributo role="menuitem".
  Ma ora che abbiamo comunicato alla api di accessibilit che con
quell'oggetto deve comportarsi come con la classe cui l'oggetto appartiene,
bisogner anche informarla dei cambiamenti di stato e di propriet che
avvengono o dinamicamente o a seguito dell'interazione con l'utente:
  cambiamenti di colore, di contenuto, di dimensione, connessi con
l'interazione: una casella  selezionata, un pulsante attivato, un elemento
 invisibile, p sotto il puntatore del mouse, ecc. o altre propriet
dell'oggetto

  - Attraverso una serie di attributi che iniziano tutti per "aria-" e
dunque possono avere come valore, numeri, stringhe, liste ecc.
  Sono circa 35 ma spalmati su una sessantina di ruoli per cui ad ogni ruolo
ne corrisponde solo qualcuno.
  In generale per ciascun elemento interattivo con un attributo role
appropriato, un tabindex usato appropriatamente, e uno o due attributi aria
si  in grado di far fronte ad ogni esigenza.

  In quali casi  necessario pompare aria nelle "biciclette assistive"?

  - nei controlli dii input dell'utente;
  - negli elementi dell'interfaccia utente: menu toolbar, widget in genere
  - quando sia necessario aggiungere informazioni aggiuntive sulla struttura
del documento che aiutino la tecnologia assistiva e l'umano al suo rimorchio
ad orientarsi, a sapere dove sei e quindi come comportarti o cosa
aspettartti;
  - in particolari aree dedicate a funzioni specifiche come una barra di
stato, una finestra di alert o di log, una progressbar ecc.
  - negli elementi soggetti a trascinamento;
  - quando sia necessario segnalare una relazione tra elementi come
l'elemento attivo di un menu.

  Cosa dovrebbe fare chi, anzicch gonfiare la sua bicicletta scassata,
volesse progettare una centrale eolica.

  - mettere in fila la trentina di oggetti o widget dei principali ruoli;
  _ per ciascuno verificare l'attuale livello di supporto da parte delle
tecnologie assistive: poich  almeno dal 2005 che si parla di aria, alcune
funzionalit potrebbero o sono gi ben supportate da browser e screen-reader
evitando inutili rompicapi agli sviluppatori, mentre al contrario per altri
il supporto potrebbe risultareancora insufficiente e nel qual caso, se
possibile, trovare soluzioni equivalenti;
  - fornire ai malcapitati tutti i riferimenti per gli approfondimenti sui
vari aspetti, focalizzare la problematica, proporre qualche esempio di
implementazione.

  Dunque niente paura.
                          Don
***
ti ricordiamo che al momento non  possibile andare in no mail.
Se quindi desideri per qualche motivo non ricevere pi i messaggi, per
favore ti chiediamo di disiscriverti dalla lista mandando un messaggio a:
nvda-request@spazioausili.net
e nell'oggetto scrivi la parola "unsubscribe" senza le virgolette.
***_______________________________________________
Nvda mailing list
Nvda@spazioausili.net
http://ml.spazioausili.net/cgi-bin/mailman/listinfo/nvda
