Jakob Nielsen nell’ultimo numero della sua Alertbox se la prende con i costruttori di browser, rei di non consentire agli utenti di modificare efficacemente le dimensioni dei caratteri.
E’ proprio così, come abbiamo avuto modo di parlare nella quinta puntata del nostro corso di accessibilità web.
Jakob rimpiange i bei tempi di Internet Explorer 4, tanto che se ne esce con un:
Mr. Gates, please give us back the good design you shipped in IE4 for the Mac.
Questo articolo fa parte di un corso gratuito di accessibilità web ospitato su questo sito.
Il browser svolge un ruolo centrale per l’accessibilità web:
In questa e nella successiva lezione ci occupiamo di supporto all’accessibilità da parte dei browser in due contesti:
In questa puntata ci soffermiano in particolare su alcune caratteristiche dei browser, che possono influenzare il modo di sviluppare le pagine.
Nella prossima lezione vedremo invece come 15 tipi di browser interpretano le specifiche accessibili dell’Html, con un esempio completo e alcune tabelle comparative di riepilogo da tenere sempre a portata di mano.
È tra gli argomenti più delicati quando si parla di accessibilità: la possibilità di modificare ed ingrandire i caratteri presenti nella pagina.
Internet Explorer consente di alterare le dimensioni dei caratteri di una pagina intervenendo con il menù View. Purtroppo, questa opzione non funziona con tutti i tipi di carattere definiti mediante Css.
Se provate questa “pagina di esempio con caratteri“ [nuova finestra], in cui sono definite alcune classi Css contententi regole su diversi tipi di dimensione, capirete quello che intendiamo:
Come si vede, non tutti i tipi di carattere sono ridimensionati. In particolare, le classi definite in punti (pt) e pixel (px) non variano la loro dimensione anche modificando le opzioni in Internet Explorer.
Un vero peccato, perché pt e px sono le unità di misura che lo sviluppatore riesce a controllare al meglio e che sono trattate quasi allo stesso modo dalle diverse piattaforme.
Netscape 6+ si comporta in modo diverso e, fortunatamente, ridimensiona tutti i tipi di carattere, indipendentemente da come sono stati definiti.
Opera consente non solo di ridimensionare i caratteri, ma di zoomare nella pagina, così da ingrandire anche immagini e menù. Una funzionalità particolarmente utile e immediata da usare.
Internet Explorer dà la possibilità di creare ed utilizzare un foglio Css alternativo rispetto a quelli presenti nella pagina.
Per farlo (nella versione 6) è necessario intervenire dal menù Tool / Internet Options / Accessibility.
È possibile a questo punto creare con un editor di testo un foglio di stile alternativo. Come esempio, abbiamo realizzato un foglio di stile ad alto contrasto per FucinaWeb.com.
Sfortunatamente, non sembra possibile poter utilizzare il nuovo foglio di stile senza selezionare le altre 3 opzioni presenti nella finestra. Sarebbe stato più logico pensare che il foglio di stile avesse la precedenza su quello di default.
Sono interessanti le potenzialità offerte da Netscape 6+ e Mozilla.
La stessa pagina può infatti contenere le dichiarazioni di più Css, distinte tra loro dall’attributo title.
FucinaWeb.com contiene, infatti, alcune tipologie di Css, proprio per questo scopo.
Se provare a visualizzare il nostro sito con Netscape 6+ o Mozilla, e andate al menù View / Use Stylesheet, vi accorgerete che compaiono 2 scelte (oltre a “nessun Css”).
Sono infatti utilizzati diversi fogli di stile. Semplificando, ecco i Css specificati in testa al sorgente Html:
Come si vede, sono presenti 2 Css e a ognuno è associato un attributo title diverso.
Non solo, ricordatevi che per gli elementi di default il valore dell’attributo rel è “stylesheet“, mentre per gli altri “alternate stylesheet“. State attenti a non dimenticarlo, poichè a quel punto i browser caricano per primo quello che vogliono, a loro discrezione (e, come spesso succede, Netscape e Opera sembrano comportarsi diversamente uno dall’altro).
Questo dà la possibilità allo sviluppatore di realizzare fogli diversi per esigenze diverse, ma anche di provare in modo veloce diverse soluzioni di design.
L’unica nota negativa è che l’opzione non viene mantenuta durante la navigazione tra le pagine dei siti, costringendo ogni volta a riselezionare i Css.
Normalmente, una pagina in FucinaWeb.com ha questo aspetto:
Se però viene scelto il foglio di stile ad alto contrasto, i colori delle sezioni vengono alterati:
Il browser Opera merita un discorso a parte, visto che uno dei suoi punti di forza è dato dalle diverse opzioni di configurazione, tanto da farne una delle piattaforme ideali per il testing dell’accessibilità.
Non abbiamo qui la pretesa di analizzarle tutte ma ci limiteremo, come sempre, a quelle di particolare interesse.
Con Opera è possibile definire due personalizzazioni della pagina:
Saltare da una all’altra è semplice e a portata di mouse
Opera rende molto facile l’operazione di “linearizzazione delle tabelle”.
Come vedremo meglio in un’altra lezione, gli screen reader associano un ordine di lettura alle celle di una tabella. Togliendo le tabelle, l’ordine procede dall’alto verso il basso ed è facile capire se il senso della pagina si è alterato.
È possibile richiamare le funzioni usate più frequentemente con alcuni movimenti del mouse e la pressione di alcuni tasti.
A sinistra della barra degli indirizzi sono presenti alcuni pulsanti che facilitano l’utilizzo delle opzioni normalmente impiegate nel test delle pagine. È possibile:
Hai notato qualche caratteristica particolarmente utile, ma della quale non abbiamo parlato? Scrivici e condividiamo la tua esperienza!
Questo articolo fa parte di un corso gratuito di accessibilità web ospitato su questo sito.
Garantire l’accessibilità web, lo abbiamo detto più volte, non è solo una questione di software. Non esistono strumenti totalmente automatici che verifichino le pagine e ne correggano tutti i problemi di accessibilità.
Le linee guida facilitano comunque la verifica e la correzione delle pagine da parte di tutte le figure professionali coinvolte nella costruzione di un sito accessibile.
Le più importanti linee guida oggi disponibili sono:
Altre linee guida sono state realizzate da aziende software, tra le quali ricordiamo le
Ibm Web Accessibility Checklist [nuova finestra]
È uno dei tre tipi di linee guida rilasciati dalla Wai e si preoccupa di definire uno standard per la costruzione di pagine web che siano accessibili nella loro struttura e nel loro contenuto.
Le altre linee guida realizzate dal Wai sono:
Il documento è suddiviso in 14 linee guida, di cui riportiamo una libera traduzione in italiano:
Accanto alle linee guida, sono disponibili altri documenti Wai che ne approfondiscono l’uso:
Le linee guide sono suddivise in punti (checkpoint), a loro volta raggruppati in 3 categorie di priorità:
Il numero del checkpoint segue quello della linea guida ed è separato da un punto. 1.4, ad esempio, indica il checkpoint 4 della linea guida 1.
Le linee guida del W3c sono alla base della Section 508 e di quasi tutte le proposte per la realizzazione di documenti accessibili.
La critica che spesso viene rivolta a queste linee guida è che non sembra facile riuscire ad applicarle tutte insieme, cioé i checkpoint di livello 1,2 e 3.
In particolare, garantire una visualizzazione corretta ad un vasto pubblico, ma utilizzare i fogli di stile anche per il layout della pagina sono due esigenze all’oggi inconciliabili. Difficile quindi costruire un sito accattivante e con un buon numero di pagine che riesca a tenere conto di tutte le esigenze delle linee guida, anche se nel medio periodo la penetrazione dei browser versione 5+ non può che favorire questa situazione.
Le Wcag sono in fase di attenta revisione e per rendersene conto è possibile dare un’occhiata ad una proposta di riorganizzazione [nuova finestra].
Sono state pubblicate dall’US Access Board nel 2000 e coprono diversi aspetti dell’accessibilità in ambito informatico, non solo nel web.
Tutti i siti creati o gestiti per conto del governo americano devono soddisfare i requisiti di queste linee guida.
Sono basate sulle Wcag 1.0 del W3c e ne presentiamo una libera traduzione in italiano:
Impossibile ignorare una profonda somiglianza tra le linee guida Wcag e Section 508, fatto normale considerato che le Section 508 si basano sulle specifiche del Wai.
Quasi tutti i checkpoint uno sono presenti nella Section 508, ad eccezione di:
Alcune linee guida della Section 508 sono in corrispondenza con i checkpoint di priorità 2 e 3.
In generale non esistono sostanziali differenze, se non per il fatto che alcuni checkpoint Wcag di priorità 2 e 3 sono “premiati” nella Section 508.
Per un’approfondita analisi delle differenze tra le due serie di linee guida vi suggeriamo la lettura di un articolo [nuova finestra] scritto da Jim Thatcher, autore di Constructing Accessible Web Sites.
Una circolare firmata dal ministro Bassanini nel Marzo del 2001 pone l’accento sui requisiti di usabilità ed accessibilità per i siti delle pubbliche amministrazioni. Il documento [nuova finestra] indica come riferimento primario le linee guida del W3c.
A seguito del documento, Aipa ha prodotto una circolare [nuova finestra] per chiarire gli strumenti e i metodi a disposizione per migliorare l’accessibilità web. Si tratta di una riscrittura e in qualche caso di un approfondimento alle linee guida del W3c, ed è incluso anche qualche parametro quantitativo per misurare l’accessibilità, come i browser da usare per valutare il grado di accessibilità di un documento.
Siamo comunque ancora in una fase in cui sono fornite indicazioni di massima su come includere le politiche di accessibilità nel proprio sito. Basta navigare i siti delle pubbliche amministrazioni per rendersi conto che c’è ancora molta strada da compiere. Nei casi più fortunati sono state predisposte delle versioni alternative accessibili dei siti, come è accaduto per la Camera dei Deputati [nuova finestra].
Come abbiamo visto, la scelta tra le Section 508 e le Wcag è sostanzialmente equivalente. Ricordate comunque che il vostro unico metro di giudizio sarà il test finale al quale sottoporre ogni pagina del sito per verificarne l’accessibilità.
Un test, come vedremo più avanti, non ha l’unico scopo di verificare la conformità del codice scritto, ma anche il livello di efficacia dell’interfaccia grafica del sito, nonché lo stile di scrittura, che nel web dev’essere particolarmente diretto e facilmente scansionabile.
Nel corso dei nostri esempi cercheremo di soddisfare sia le Wcag sia la Section 508, senza nascondervi che questo a volte non sarà possibile o non sarà conveniente. Giustificheremo allora le nostre sceltre proponendo delle personali, e come tali sicuramente criticabili, soluzioni.