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"
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
test.cita.illinois.edu/aria/
OAEG (Open Accessibility Everywhere Group) e commissione europea
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:
 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,
 test.cita.illinois.edu/aria/tree/tree1.php
 tra cui appunto il treeview:
 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
ml.spazioausili.net/cgi-bin/mailman/listinfo/nvda
Torna all'indice