Valutazione dell’accessibilità di un sito web - Parte Terza, scavando più a fondo
Traduzione dell'articolo originale "Evaluating Website Accessibility Part 3, Digging Deeper" di Roger Johansson, www.456bereastreet.com.
13 Luglio 2006
In Valutazione dell’accessibilità di un sito web - Parte Prima – Storia e preparazione, ho riportato un po’ di storia ed un po’ di informazioni generali sull’accessibilità ed ho suggerito alcuni strumenti per valutare l’accessibilità dei siti web. Nel secondo articolo della serie, Valutazione dell’accessibilità di un sito web – Parte Seconda, controlli di base, ho esaminato quegli aspetti dell’accessibilità che possono essere valutati con degli strumenti automatici. Nello stesso articolo ho anche analizzato un paio di aspetti dell’accessibilità che richiedono dei controlli manuali relativamente semplici.
In questo ultimo articolo della serie chiarirò alcuni aspetti dell’accessibilità dei siti web che sono difficili da esaminare in maniera automatica e che richiedono più tempo e/o più esperienza per essere valutati in maniera manuale. Alcune descrizioni dei punti di controllo di questo articolo assumono che voi abbiate già letto i precedenti articoli. Quindi se non li avete ancora letti, vi prego di farlo prima di continuare.
Questo articolo contiene i seguenti controlli:
- Contrasto dei colori
- Titoli dei documenti
- Testo dei collegamenti
- Formati non HTML
- Discriminazione delle piattaforme
- Navigazione tramite tastiera
- Tabelle di dati
- Controlli dei form ed etichette
- Uso di un lettore di schermo (screen reader)
- Non trascurate il contenuto
- Ulteriori letture
1. Contrasto dei colori
Un modo facile per controllare che la differenza tra la tinta e la luminosità dei colori in primo piano e quelli sullo sfondo sia ottimale utilizzate l’eccellente Colour Contrast Check di Jonathan Snook. Inserite il valore esadecimale del colore del testo e dello sfondo, oppure spostate i cursori ed avrete un’anteprima in tempo reale delle differenze di contrasto e di colore.
Colour Contrast Analyser di Gez Lemon è uno strumento simile, che è anche disponibile come estensione per Firefox.
Entrambi questi strumenti usano un algoritmo fornito dal W3C per calcolare la visibilità dei colori.
Potete anche impostare il vostro schermo in bianco e nero per verificare che tutto il testo rimanga leggibile. Se utilizzate Mac OS X ci sono delle ottime opzioni per queste modifiche nel pannello delle preferenze “Accesso Universale”. Qui potrete invertire i colori, impostare lo schermo in bianco e nero (o monocromatico) e cambiare il contrasto. Se conoscete degli strumenti simili per altri sistemi operativi, vi pregherei di farcelo sapere.
Perchè? Se non c’è abbastanza differenza tra la tinta e la luminosità tra i colori in primo piano e quelli sullo sfondo molte persone avranno dei problemi a leggere il testo. Questo può succedere sia perché questi utenti hanno dei difetti alla vista oppure perché usano degli schermi monocromatici o in bianco e nero. Oppure, come me, essi hanno una vista perfetta, un ottimo monitor che mostra colori a 24 bit, ma hanno problemi lo stesso se un sito web usa del testo grigio chiaro su uno sfondo bianco.
Per la stessa ragione è importante non fare affidamento soltanto sul colore per fornire delle informazioni. I collegamenti, per esempio, non dovrebbero essere diversi dal testo vicino soltanto nel colore, ma anche nel formato o nella sottolineatura.
2. Titoli dei documenti
Controllate che ogni documento abbia un titolo unico e descrittivo e che il titolo non abbia un uso eccessivo della punteggiatura.
Non esistono regole certe che indichino quali caratteri utilizzare come separatori nei titoli. Comunque, i titoli delle vostre pagine non dovrebbero contenere segni di punteggiatura solo per uno scopo decorativo, ad esempio “:: Titolo ::” o “…=== Titolo ===…”. Ogni segno di punteggiatura potrebbe essere letto da un lettore di schermo, rendendo l’ascolto del titolo insopportabile. Per farvi un’idea di come alcuni caratteri speciali risultino in JAWS, controllate The Sound of the Accessible Title Tag Separator.
Il lettore di schermo VoiceOver di Apple legge “»” come “right pointing double angle quotation mark”. Questa regola sconsiglia l’utilizzo di questo carattere non solo nei titoli dei documenti, ma anche nei link, dove sfortunatamente è abbastanza popolare.
Una discussione sui diversi separatori per i titoli può essere trovata in Document titles and title separators.
Perchè? I titoli dei documenti sono importanti per diverse ragioni: spesso è la prima cosa restituita dagli strumenti di assistenza al caricamento di una nuova pagina, è usato nella barra del titolo del browser, nei bookmarks (favoriti in Internet Explorer e segnalibri in Firefox) e durante la stampa di un documento. Titoli descrittivi sono molto utili per tutti. Inoltre sono molto importanti anche per la visibilità nei motori di ricerca.
3. Testo dei collegamenti
I collegamenti dovrebbero avere un senso anche quando letti fuori dal loro contesto. “Premi qui” o “qui” non sono dei buoni testi per un collegamento, in quanto non forniscono alcuna informazione sulla destinazione del collegamento. Collegamenti che utilizzano interi paragrafi, come capita spesso nei siti dei giornali online, contengono troppa informazione e dovrebbero essere evitati.
In generale, non si dovrebbe utilizzare lo stesso testo per collegamenti che conducono a diverse destinazioni. Idealmente ogni collegamento dovrebbe essere indipendente e mantenere il proprio significato anche al di fuori del proprio contesto. Alcuni strumenti automatici per il controllo dell’accessibilità vi avviseranno nel caso si verifichi questa eventualità.
Esistono delle eccezioni. Testi per un collegamento come “Continua” o “Continua a leggere” possono andare bene in una lista di news o simili, sempre che i titoli delle notizie differenzino i collegamenti. Joe Clark spiega perchè sia accettabile in una intervista del Web Standard Group del Maggio 2005.
Per avere una panoramica di tutti i collegamenti presenti in un documento potete caricare il documento in Opera ed aprire il pannello “link”, oppure usate il comando “Link list” dell’estensione Fangs.
Perchè? I collegamenti sono più utili a tutti se contengono del testo descrittivo. Gran parte delle persone vedenti esaminano le pagine web per avere una idea del loro contenuto, ed i collegamenti spesso sono una parte importante del contenuto. Collegamenti chiari ed evidenti facilitano questa scansione. Persone non vedenti o con gravi problemi alla vista non possono esaminare le pagine web allo stesso modo, e solitamente passano da un collegamento ad un altro tramite il tasto tab o utilizzano una lista di collegamenti. Ancora di più in questi casi l’utilizzo di testo descrittivo per i collegamenti è di notevole aiuto.
Collegamenti descrittivi sono molto importanti anche per la visibilità ai fini dei motori di ricerca, tanto che ancora una volta l’accessibilità implica un buon SEO (ottimizzazione per i motori di ricerca).
4. Formati Non HTML
Se il sito web rende disponibili importanti informazioni in file PDF, Microsoft Word, Microsoft Excel, o in altri formati proprietari, dovrebbero essere fornite anche delle alternative in HTML. Vorrei far notare che non c’è nulla di sbagliato nel fornire informazioni con formati non-HTML purché siano disponibili anche in formato HTML.
Perchè? Anche se è possibile rendere ragionevolmente accessibile il contenuto di file PDF a coloro che hanno il software necessario, il formato HTML è tuttora il formato più supportato e dovrebbe sempre essere la scelta preferita. Non va dimenticato che non tutti hanno Microsoft Word o Excel o qualche altro strumento per aprire i documenti in questi formati. Se le informazioni sono disponibili soltanto in formati proprietari Microsoft (come spesso accade) molte persone sono effettivamente escluse.
5. Discriminazione delle piattaforme
Con il termine “discriminazione delle piattaforme” mi riferisco alla limitazione parziale o totale dell’ informazione a quegli utenti che utilizzano sistemi operativi o browsers non molto diffusi. Per questo controllo dovrete avere accesso a parecchi sistemi operativi differenti con vari browsers installati. Questo tipo di setup non è facilmente realizzabile per molti, quindi vi dovrete accontentare di falsificare la stringa dell’user agent del browser che usate durante i vostri test.
Siccome state usando Firefox (che vi ho raccomandato in Valutazione dell’accessibilità di un sito web - Parte Prima – Storia e preparazione) potete installare l’estensione User Agent Switcher, scaricare una lista di user agents ed essere pronti per verificare il vostro sito web.
Controllate se il sito permette l’accesso a user agents diversi da Internet Explorer per Windows. Ovviamente questo controllo verifica soltanto se il sito esaminato usa qualche tipo di rilevamento dei browser basandosi sulla stringa dell’User Agent. Se, come spesso accade, la discriminazione tra le varie piattaforme si basa su caratteristiche specifiche di qualche sistema operativo/browser, la modifica della stringa dell’user agent non aiuterà in questo controllo.
La discriminazione delle piattaforme potrebbe essere involontaria, ma troppe volte è completamente volontaria. E’ estremamente raro trovare un sito che discrimini degli utilizzatori di Internet Explorer per Windows. Dall’altra parte, a molti utilizzatori di Mac e Linux è probabilmente capitato di essere rifiutati da diversi siti perché utilizzano dei sistemi operativi/browsers “non supportati”.
Questo è assolutamente inaccettabile.
Spesso dico che l’accessibilità del web è un problema molto più ampio del semplice offrire informazioni a persone invalide. La discriminazione delle piattaforme è un ottimo esempio di questo, e a dire il vero è il fattore più importante che mi ha fatto capire quanto sia importante per il web la possibilità di essere accessibile a tutti. Poche cose sono così fastidiose quanto il fatto che alcune informazioni siano per me inaccessibili soltanto perché uso un Mac.
Perchè? Perchè una delle caratteristiche fondamentali del web è che dovrebbe essere indipendente dall’hardware e dal software utilizzati per accedervi. Il web per tutti, ovunque, e comunque.
6. Navigazione tramite tastiera
Mettete via il vostro mouse per un po’ e provate a navigare il sito usando soltanto la tastiera, passando attraverso i collegamenti ed i controlli dei form tramite l’utilizzo del tab. Ricordate che potrebbe essere necessario impostare i settings del vostro browser per abilitarlo a fare ciò. Sia Firefox che Safari non hanno questa funzionalità attiva di default. Funziona? Se ci sono dei menu a tendina controllate che possano essere utilizzati anche senza l’utilizzo del mouse.
Perchè? Gli utilizzatori di lettori di schermo non usano il mouse per navigare nel web, perciò questo è molto importante per loro. Ci cono anche molte persone che utilizzano la tastiera per scelta, considerando questo metodo più veloce e comodo rispetto all’utilizzo del mouse.
A seconda della struttura del sorgente e della dimensione del documento potrebbe essere molto utile a chi non utilizza il mouse la presenza di un collegamento per raggiungere immediatamente il contenuto principale del documento. Se il documento contiene un elevato numero di collegamenti di navigazione prima del contenuto principale, un collegamento al contenuto principale farà risparmiare un sacco di tempo a chi utilizza la tastiera per navigare.
Un sito accessibile deve obbligatoriamente essere indipendente dal mezzo e non presumere che l’utente utilizzi un particolare mezzo, in questo caso il mouse.
7. Tabelle di dati
E’ arrivato il momento di controllare l’uso appropriato o meno delle tabelle. L’estensione Web Developer torna ad essere utile di nuovo. Usatela per evidenziare tutte le tabelle selezionando Contorna – Contorna celle tabelle e Contorna – Contorna Tabelle. Se la pagina che state esaminando non contiene dati tabellari, non dovrebbe succedere niente. Se parte della pagina che non contiene dati tabellari è evidenziata, significa che delle tabelle sono utilizzate per il layout ed il sito non supera questo test.
Se la pagina contiene dei dati tabellari, controllate che questi dati siano presenti in una tabella e che siano utilizzata una marcatura corretta ed accessibile. Per avere ulteriori informazioni su come usare tabelle HTML nel modo corretto leggete l’articolo (in inglese) Bring on the tables.
Perchè? Non si dovrebbero utilizzare le tabelle per il layout di una pagina, ed i dati tabulari dovrebbero essere marcati correttamente con delle tabelle utilizzando gli elementi e gli attributi disponibili per migliorare l’accessibilità.
8. Controlli dei form ed etichette
Per questo controllo avete bisogno di una pagina che contenga almeno un form. Quando eseguirete questa verifica, controllate che ogni controllo del form abbia un’etichetta (label) associata, che le etichette siano marcate correttamente e che le etichette ed i controlli del form siano nell’ordine giusto (prima l’etichetta, poi il controllo, ad eccezione dei controlli a scelta singola o multipla (radio buttons e checkboxes) in cui l’etichetta dovrebbe seguire il controllo stesso).
Se il form usa dei campi di selezione per la navigazione controllate se il form è automaticamente inviato (attraverso JavaScript) quando si seleziona un’opzione. Nei casi in cui JavaScript non sia disponibile, assicuratevi che il form possa essere utilizzato ugualmente e che la validazione di tutti i dati inseriti dall’utente sia compiuta a livello del server.
Strumenti automatici per la valutazione dell’accessibilità vi informeranno di controlli dei form che non hanno etichette associate. Potete anche utilizzare l’estensione Web Developer: Forms – Visualizza informazioni form ed assicuratevi che tutti i controlli visibili del form abbiano un’etichetta associata.
Perchè? Etichette appropriate aiutano tutti siccome rendo l’area cliccabile più grande. Ogni controllo visibile di un form dovrebbe avere un’etichetta associata esplicitamente.
Sottomettere un form in maniera automatica quando un’opzione è cambiata crea dei problemi agli utenti che utilizzano la tastiera. L’utilizzo di JavaScript per inviare i dati di un form rende impossibile l’invio qualora JavaScript non fosse disponibile. Affidarsi a JavaScript per la validazione dei dati inseriti nel form potrebbe dare origine a valori inaspettati inviati e successivamente archiviati in un database.
9. Uso di un lettore di schermo (screen reader)
Innanzitutto vorrei sottolineare come l’accessibilità non riguardi soltanto i lettori di schermo. Niente di più lontano. Pensare che l’accessibilità del web corrisponda a “funziona nel lettore di schermo X” è un errore molto comune. L’accessibilità è molto più di questo.
Ora parliamo di lettori di schermo. Se non siete ciechi, è molto difficile immaginare cosa significhi navigare il web senza poter vedere. Potete provare, ma è molto difficile evitare di barare. Nonostante questo dovreste provare, e per far questo avrete bisogno di un lettore di schermo.
Se utilizzate un Mac potreste già avere un lettore di schermo – Mac OS X 10.4 e le versioni successive comprendono VoiceOver, un lettore di schermo di Apple. Non ha tutte le funzionalità avanzate di altri lettori di schermo disponibili, ma è abbastanza buono per darvi un’idea decente di come suoni un sito web a qualcuno che non può vedere. C’è un articolo (in inglese) in cui spiego le nozioni basilari di come utilizzare VoiceOver per navigare il web: VoiceOver and Safari: Screen reading on the Mac.
Se non possedete un Mac con Mac OS X 10.4 o una sua versione più recente, dovete installare un lettore di schermo. La maggior parte dei lettori di schermo sono molto costosi, e probabilmente dovrete accontentarvi di usare una versione dimostrativa. Di seguito è riportata una lista di lettori di schermo che sono disponibili anche con versioni dimostrative:
Perchè? Tutti gli altri controlli riportati negli articoli di questa serie vi renderanno degli esperti in accessibilità. Comunque, sperimentare come sia il web per qualcuno che non può vedere è importante siccome vi farà render conto dell’importanza di molte delle problematiche che sono state presentate.
10. Non trascurate il contenuto
Se il sito che state controllando ha passato tutti i controlli di questa serie di articoli, è abbastanza sicuro assumere che il sito sia tecnicamente accessibile a tutti. Questo, sfortunatamente, non significa che il contenuto del sito sia capibile da parte di tutti.
Scrivere o presentare del contenuto che sia veramente accessibile a tutti può essere estremamente difficile, e valutare questo aspetto dell’accessibilità è al di fuori dello scopo di questi articoli. Ricordate sempre che del contenuto scritto male ed in maniera incoerente può essere difficile da capire anche per persone altamente intelligenti ed istruite.
Ovviamente la comprensione del contenuto di un sito web può essere ancora più problematica se avete qualche problema di tipo cognitivo. Un articolo (in inglese) su questo argomento che vi consiglio di leggere è Developing sites for users with Cognitive disabilities and learning difficulties. In questo articolo, Roger Hudson, Russ Weakley, and Peter Firminger trattano alcune aree problematiche e forniscono alcuni suggerimenti su come migliorare l’accessibilità per persone con difficoltà di tipo cognitivo.
11. Ulteriori letture
Vi raccomando di leggere Web Content Accessibility Guidelines 1.0 (in inglese) e Techniques for Web Content Accessibility Guidelines 1.0 (in inglese). Sono dei documenti molto grandi e posso essere un pochino, uhm, inaccessibili, ma contengono un gran quantità d’informazioni.
Dovreste anche leggere la bozza attuale del WCAG 2.0 ed il documento collegato Techniques for WCAG 2.0. Vorrei sottolineare come i documenti del WCAG 2.0 siano delle bozze e potrebbero venire modificate prima di essere finalizzate.
E per finire, ricordate che l’accessibilità non è un caso di tutto o niente. Fare qualcosa per migliorare l’accessibilità è molto meglio che non far niente e sperare che nessuno se ne accorga.
Ti è piaciuto questo articolo? Aggiungilo a: del.icio.us
