EUCOOKIELAW_BANNER_TITLE

  • I think that

    Making the Web is like playing a game. Standard, Accessibility and Usability are only few rules.
    No game is awesome if you don't follow the rules.

    International Webmasters Association

  • Subscribe to my blog via email

    Insert here your e-mail address and you will receive a message when a new post will come.

10 errori tipici quando si implementa l’accessibilità del web

Nota di servizio

Questa è la traduzione dell’articolo 10 common errors when implementing accessibility di Trenton Moss, pubblicato originariamente su webcredible a Gennaio 2008. La traduzione eseguita da Silvia Dini della cooperativa David Chiossone viene qui presentata con il consenso dell’autore e dell’traduttore.

1. Non inserire testo ALT prolisso

Il web designer spesso inserisce troppi testi ALT e a tutte le immagini, nella speranza che questo aiuti chi usa gli screen reader.
Il testo ALT nelle immagini che danno informazioni deve essere breve e succinto, e non deve contenere più informazioni di quelle presenti nell’immagine stessa.
Immagini decorative non devono avere il testo alternativo (tag alt=””) in modo che siano ignorate dagli screen reader. Assegnare testo ALT che non aggiunge reale valore ai contenuti, infatti, appesantisce la lettura per gli utenti che usano screen reader.

2. Non usare caratteri casuali per separare i LINK

C’è un requisito, di minore importanza, che dice che i link adiacenti devono essere separati da un testo che non sia un link. La ragione di questa linea guida è che alcuni vecchi browser hanno problemi a interpretare link adiacenti e li considerano un unico grosso link (tutti puntano alla stessa pagina).
Questa linea guida oggi non è più importante, ma spesso chi realizza i siti web continua ad inserire caratteri invisibili per separare i link, tipicamente una barretta verticale.
Sfortunatamente lo screen reader legge il carattere anche se invisibile e pronuncia comunque “barra verticale”, il che rende piu’ difficile la comprensione dei testi dei link stessi perché crea confusione.

3. Non mettere testi nei campi dei moduli

Un’altra regola vecchia e datata richiede che sia presente un testo di esempio in ogni campo nelle pagine con i moduli. Questa regola era nata perchè in origine i vecchi screen reader non erano capaci di leggere i moduli con i campi vuoti.
Tutti gli screen reader di oggi sono in grado di rilevare campi vuoti nei moduli, senza problemi, così questa regola si può ignorare e si può evitare di inserire testi di esempio nei campi dei moduli.
Inoltre spesso gli screen reader non leggono questo testo campione, così gli utenti rischiano di inserire il loro testo senza cancellare quello già presente, con conseguenti problemi di utilizzo dei moduli.

4. Non usare access key

Si possono assegnare “access key” a ciascun link o a elementi dei moduli, in modo da avere scorciatoie da tastiera per attivarli.
In teoria questa è una buona idea per coloro che utilizzano screen reader o per tutti gli utenti che usano il computer solo da tastiera, perché dovrebbe essere più rapido e facile attivare i comandi in ogni pagina.
Ma sarebbe meglio non inserire access key (o almeno non eccessivamente) perché possono sovrapporsi alle scorciatoie dei comandi (shortcut) degli screen reader stessi, che diventano non usabili.
L’altro problema è che non esiste una convenzione ufficiale con cui creare questi shortcuts, valida in tutti i siti web, così che il visitatore, ogni volta che apre un nuovo sito web, deve spendere del tempo per scoprirli.

5. Non inserire il sommario nelle tabelle, quando non serve!

Il sommario delle tabelle può essere inserito in ogni tabella HTML, ed è essenzialmente una descrizione di ciò che rappresenta la tabella. Gli screen reader leggono il sommario e forniscono una descrizione della tabella, prima di passare a leggere l’intero contenuto.
Il sommario non dovrebbe essere messo nelle tabelle usate a scopo di layout (impaginazione). I siti web che usano uno schema di impaginazione a tabella talvolta hanno come sommario il testo “tabella di layout” (layout table) che ovviamente è inutile perché non porta alcuna informazione o valore aggiunto.
Solamente con tabelle di dati è necessario inserire il sommario, ma solo se nel testo della pagina non ci sono sufficienti informazioni relative alla comprensione della tabella.

6. Non dimenticare il contenuto

Il modo in cui il contenuto è strutturato in ogni sito web ha una parte enorme nell’accessibilità.
Un sito web può essere perfetto sul piano del codice e della conformità agli standard. Ma se il suo contenuto è strutturato e presentato malamente, il sito diventerà difficile e impossibile per molti utenti che navigano nel web con ausili.
Ci sono alcune considerazioni sull’importanza dell’accessibilità del contenuto, fra le quali:

  • mettere prima il contenuto di rilievo (ad es. ogni paragrafo inizi con le conclusioni);
  • assicurarsi che il contenuto sia suddiviso in pezzi maneggevoli e con intestazioni descrittive;
  • usare elenchi quando servono;
  • usare linguaggio semplice e chiaro.

7. Non dedicare troppo tempo alle dichiarazioni di accessibilità

Molti siti web che tentano di offrire la massima cura dell’accessibilità inseriscono specifiche pagine in cui sperano di fare cosa utile descrivendo gli elementi di accessibilità. Tipicamente queste pagine contengono informazioni sulle caratteristiche di accessibilità del sito, come ridimensionare i caratteri ecc.
In realtà I navigatori web con disabilità consultano raramente queste dichiarazioni. Come navigatori, noi non badiamo mai a consultare l’help di un sito ma piuttosto procediamo per tentativi per raggiungere la meta.
Sebbene non ci sia nulla di sbagliato a creare una pagina con dichiarazioni e informazioni di accessibilità c’è nessuno bisogno di spender troppo tempo su qualcosa che nella realtà non verrà usato.

8. Non insistere su acronimi e abbreviazioni

E’ facile in HTML dichiarare se qualcosa è un acronimo o abbreviazione, semplicemente usando il tag <acronym> o <abbr>. L’acronimo o abbreviazione possono essere espansi poi proprio dentro questo tag.
Tuttavia gli screen reader non supportano questi tag, che di fatto non offrono alcun beneficio a utilizzatori che necessitano di screen reader.
Gli utenti che ne beneficiano sono persone in grado di vedere e di usare il mouse; infatti quando si posa il mouse su uno di queste scritte si apre un “tooltip” in cui appare la piena espansione dell’acronimo o dell’abbreviazione.
Questo tag può essere considerato certamente utile per l’usabilità del sito, ma non offre alcun beneficio per l’accessibilità.

9. Non cambiare l’ordine di tabulazione, se non c’è una buona ragione!

L’attributo può essere usato per cambiare l’ordine di tabulazione in una pagina web, ma raramente è necessario.
L’ordine di tabulazione originario di solito è logicamente perfetto e non necessita di cambiamenti.
Gli utenti che adoperano screen reader o navigano solo con la tastiera, saltano fra i link e le caselle dei moduli con il tasto Tab, nell’ordine in cui essi sono presenti nel codice sorgente HTML.
Appurato perciò che gli utenti possano tabulare in ogni sezione della pagina con direzione dall’alto a sinistra verso il basso a destra, l’ordine di tabulazione è da ritenersi perfettamente adeguato.

10. Non dimenticare di far leggere la pagina web da uno screen reader

Quando si sta realizzando il proprio sito web accessibile, non bisogna dimenticare di fare prove e test delle pagine man mano che si costruiscono. In particolare, è bene ascoltarle lette da uno screen reader per controllare che le caratteristiche di accessibilità implementate funzionino come previsto.
Per esempio se per aiutare chi naviga con screen reader, sono stati inseriti testi resi invisibili usando scopriremo subito che non vengono letti neppure dallo screen reader! Gli screen reader, infatti, ignorano il testo formattato con questo comando CSS.