A mio avviso, per quel poco di tempo che ho affrontato il problema
chiacchierando con Gabriele, credo che la maggiore difficoltà sia quella
di adattare un’interfaccia basata sul punta e clicca, sul drag&drop, su
un uso esasperato del mouse, su riquadri e griglie, nel adattarla,
dicevo per essere usabile da chi non ha la possibilità di usare questi
mezzi. Le gui di 20 anni fa erano infinitamente più semplici e il loro
adattamento a screen reader era molto più semplice. Questo per dire che
ci vorrebbe un serio lavoro non tanto per rendere in qualche modo
compatibile una GUI visuale a un non vedente, quanto per fare interagire
il non vedente in modo ottimale con il model e dargli la possibilità nel
minor numero di passi di conseguire il risultato voluto. Ad esempio uno
dei widget che usiamo quotidianamente e che volevo provare ad
implementare per Gabriele è la ‘dbselect’. Si tratta di un campo dove
l’operatore digita e una serie di RPC propone ad ogni tasto battuto un
popup dove selezionare l’opzione voluta. Immaginiamo la stessa cosa con
uno screenreader su una tabella delle province italiane. L’utente digita
‘M’ e la tendina mostra varie province che iniziano per M. Cosa dovrebbe
fare lo screenreader ? Ad ogni tasto battuto dovrebbe leggere il popup ?
Non mi pare praticabile. In questo caso, ad esempio, mi parrebbe più
logico che l’operatore digitasse e quando resta una ed una sola
possibilità il sistema pronunciasse l’unica opzione possibile e con il
tasto TAB completasse l'input. Questo sproloquio solo per dire che
davvero la pagina da realizzare per un non vedente dovrebbe essere a mio
avviso, pensata ex novo per questo scopo e non il risultato di un
adattamento. Vorrei capire se è un’idea corretta o se ritenete che anche
una pagina pensata per una GUI tradizionale sia fruibile in modo
semplice da chi deve usare uno screen reader. Ciao G Ciao, lo quoto
tutto, perché rispondo a tutto.
Visual studio, che io uso regolarmente, ha l'editor del testo che
utilizza in modo quasi esasperante l'autocompletamento.
In pratica, quando tu inizi a digitare si apre un popup che man mano che
scrivi ti porta sulla voce che si avvicina maggiormente alla stringa che
stai scrivendo.
Lo screen reader legge solo la voce che al momento il sistema ritiene
papabile, ma continua a permetterti di scrivere. Ma questa interfaccia
non è stata afatto pensata per non vedneti, è il normale funzionamento
dei menu.
In html5 esiste un role chiamato "menu", che fa praticamente la stessa
cosa. O meglio, fa credere allo screen reader che stia succedendo
esattamente quello che succederebbe con un menu standard.
è questa la bellezza delle wai-aria, non fanno nient'altro che creare un
ponte fra l'html e lo screen reader.
Scusate la prolissità, ma per farvi capire ho bisogno di spiegarvi come
funziona:
Lo screen reader intercetta il dom, che il browser di turno gli passa.
Il dom viene parsato dallo screen reader, che si crea un suo albero
virtuale, indipendente dal browser.
Dunque l'utente non si muove esattamente dentro la pagina, ma dentro una
pagina virtuale che lo screen reader gli fornisce.
Ora, se allo screen reader si fa credere che dentro quella pagina c'è
una listbox, quando in realtà è soltanto una <ul>, lo screen reader
propone all'utente un comportamento analogo alle listbox del desktop...
Spero di essere stato
chiaro._______________________________________________ Python mailing
list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
