javascript e l'accessibilità

[gianiaz]

Ciao, mi trovo davanti a questo problema:

ho un'applicazione che fa uso massiccio di javascript, e ora mi chiedono di adeguarla ai canoni dell'accessibilità.

Il problema è che leggendo qua e là sembra proprio che javascript non sia per niente digerito dai browser per diversamente abili.

Come comportarsi allora?


faccio un paio di esempi:

1. Form di login che controlla con js che i campi non siano vuoti (evento onblur di ogni campo).
Qui ho messo nel tag noscript un form normalissimo, ma nel tag script ho dovuto scrivere tutto il form a botte di document.write().

Questo mi lascia perplesso, non credo che sia corretto, anche perchè i validatori xml saltano la parte di js.

2. Un form dove ci sono dei select che possono contenere veramente molti dati.
ad esempio 2 select, uno che sceglie la categoria, l'altro che viene popolato dai dati di dettaglio di ogni categoria.
In questo caso quindi all'onSelect del primo popolo il secondo.
Come posso gestire la cosa seguendo le buone norme dell'accessibilità?

io sono sempre + convinto che se uno deve seguire le norme dell'accessibilità deve fare un sito statico.
mbho..


consigli e commenti ?

[Mich_]

Chiaramente la pagina deve funzionare anche se i JS sono disattivati. Per fare una prova, ti basta disabilitare i JS nel tuo browser (e` una cosa che fai in un minuto).

Pero` l'accessibilita` non vieta di usare i JS, che anzi in molti casi favolriscono l'usabilita` della pagina.

Ecco le regole fondamentali che mi sento di poterti dare:
0. Usa i marcatori corretti, il codice XHTML Strict e i CSS il piu` possibile.
1. Usa meno JS possibile (compatibilmente con l'usabilita`).
2. Per i form: i controlli vanno ripetuti lato server, e nel caso di errori la pagina va ricaricata con tutti i campi riempiti (salvo quelli errati, se credi).
3. Non usare document.write(), salvo per le parti che non hanno senso in mancanza di JS.
4. Per le parti che non hanno senso in mancanza di JS usa il document.write().
5. Per gli eventi, se usi eventi legati ad un dispositivo, associa anche corrispondenti eventi ad un altro: ad esempio usa di preferenza onfocus (che non e` legato ad un dispositivo); se usi onmousequalcosa, usa anche onkeyqualcosa e viceversa.
6. Fai in modo che il prgramma sia da un alto fatto molto bene; dall'altro che sia "a prova di stupido".

[halmadaxx]

inoltre una cosa che faccio sempre per quanto riguarda il binomio accessibilità-javascript è includere il codice javascript in file esterni con opportuni link ref

[gianiaz]

Originariamente inviato da Mich_
Chiaramente la pagina deve funzionare anche se i JS sono disattivati. Per fare una prova, ti basta disabilitare i JS nel tuo browser (e` una cosa che fai in un minuto).

Pero` l'accessibilita` non vieta di usare i JS, che anzi in molti casi favolriscono l'usabilita` della pagina.

Ecco le regole fondamentali che mi sento di poterti dare:
0. Usa i marcatori corretti, il codice XHTML Strict e i CSS il piu` possibile.
1. Usa meno JS possibile (compatibilmente con l'usabilita`).
2. Per i form: i controlli vanno ripetuti lato server, e nel caso di errori la pagina va ricaricata con tutti i campi riempiti (salvo quelli errati, se credi).
3. Non usare document.write(), salvo per le parti che non hanno senso in mancanza di JS.
4. Per le parti che non hanno senso in mancanza di JS usa il document.write().
5. Per gli eventi, se usi eventi legati ad un dispositivo, associa anche corrispondenti eventi ad un altro: ad esempio usa di preferenza onfocus (che non e` legato ad un dispositivo); se usi onmousequalcosa, usa anche onkeyqualcosa e viceversa.
6. Fai in modo che il prgramma sia da un alto fatto molto bene; dall'altro che sia "a prova di stupido".

0. Ok, fin qui ci siamo
1. Questo non dipende da me, io ero abituato a usare meno javascript possibile, per questa applicazione invece il javascript viene usato per tutto, anche per i link e i submit dei form (e non solo per il controllo, ma anche per valorizzare un campo hidden che viene utilizzato per decidere quale pagina caricare).
2. Ok per i controlli lato server.
3/4

ti faccio un esempio pratico:

<input type="text" name="prova" onclick="doQualcosa();" onblur="doAltro();" />

per trasformare questo in qualcosa di usabile ho fatto:

<script type="text/javascript">
//<![CDATA[		
document.write('<input type="text" name="prova" onclick="doQualcosa();" onblur="doAltro();" \/>');
//]]>
</script>
<noscript>
<input type="text" name="prova" />
</noscript>

In questo caso questa soluzione so già essere una schifezza, voi come vi comportereste?

5. giusta osservazione, a questo non avevo pensato.
6. abbastanza soggettivo questo

Rimane il dubbio delle 2 select.
Per fare un esempio pratico, immaginate le classiche select che vi permettono di scegliere dapprima la provincia, per poi caricare nel secondo select i comuni appartenenti alla provincia scelta.
Questa cosa come può essere risolta senza javascript? (oppure questo è uno dei casi in cui il javascript è tollerato?).



per halmadaxx


Questo però in cosa aiuta a migliorare il discorso dell'accessibilità? io ci vedo solo una pulizia maggiore del codice...

ciao e grazie per il vostro commento.

[halmadaxx]

per halmadaxx


Questo però in cosa aiuta a migliorare il discorso dell'accessibilità? io ci vedo solo una pulizia maggiore del codice...

ciao e grazie per il vostro commento.

immagina ad un browser per non vedenti che ha come unico mezzo di comunicazione la lettura del codice. Cos'è meglio tra far leggere il codice javascript e trovare un riferimento ad una pagina che il browser riconosce come javascript?

io per l'accessibilità studio molto i casi d'uso anche se ovviamente tutte le linee guida sono da seguire

[Mich_]

ti faccio un esempio pratico:
<input type="text" name="prova" onclick="doQualcosa();" onblur="doAltro();" />

E` un classico caso in cui usi un evento legato al solo mouse. Sarebbe meglio usare onfocus al posto di onclick (ma non so quanto sia supportato in IE)

Per quanto riguarda il tuo esempio, con quello impedisci di inserire tag <input> diversi se uno ha JS disabiltato o no. Ma se uno ha JS disabilitato gli attributi onclick (o onfocus) e onblur non funzionano comunque, pertanto mi pare inutile la sovrastruttura che inserisci.


Per le select dipendenti dei form, la cosa deve essere fatta lato server: quindi in caso di JS non funzionante, ci deve essere un bottone "invia il form" (da inserire subti dopo la prima select dentro un <noscript>) per permettere di fare il lavoro lato server.
Invece puoi lasciare il lato client, che velocizza il tutto se JS funziona.

per il punto 6.
La parte "a prova di stupido" puo` essere soggettiva, ma se fai i test con utenti non particolarmente addestrati, trovi sicuro qualcuno che preme i bottoni in una sequenza che non ha nessuna logica: in tal caso deve sempre essere possibile tornare ad una situazione stabile (se il form e` breve basta un reset del form; se e` lungo occorre tornare ad uno step intermedio). Quindi non e` completamente soggettivo, perche` la "stupidita`" non ha limiti (e questo e` oggettivo). [NB: senza offesa per gli utenti, che magari non sono effettivamente stupidi: e` solo un modo comune di spiegarsi tra i programmatori - chiunque puo` essere "stupido" in certe condizioni]
Ma al punto 6 intendevo anche che lo script deve essere perfetto, senza variabili globali quando potrebbero stare locali, senza possibilita` di errori di alcun tipo, ecc.