Accessibilità: tecniche e validazione

3° Workshop
Accessibilità:
“primi passi per un mondo fruibile da tutti”
TECNICHE E VALIDAZIONE
dott. Dario Santarelli
e-Lios s.r.l. (Area Sviluppo)
Email: dario.santarelli@unicam.it
Mobile: +39 333 3742535
WeBlog: http://www.dariosantarelli.wordpress.com

Sommario
Introduzione
 Accessibilità: un fatto tecnico?
Separazione tra presentazione e contenuto
 XHTML e CSS
 Il supporto dei browser
WAI WCAG 1.0
 Alcune Demo
WAI WCAG 2.0
 Confronto con il passato
Validazione dell’ accessibilità
 I migliori strumenti
Conclusioni

Accessibilità: un fatto tecnico?
Schiacciante verità: un sito può essere tecnicamente accessibile, ma
di fatto non fruibile per un disabile… La vera sfida del Web è l’ usabilità!
Dov’è il Problema?
 L'accessibilità, così come è concepita dalle attuali WCAG 1.0, rivolge le sue
raccomandazioni al "content developer” (Someone who authors Web
pages or designs Web sites“)
 Progettista/Web Designer
 Sviluppatore
 L’autore dei contenuti
 Alcune raccomandazioni delle WCAG 1.0 hanno a che vedere con
l’usabilità, ma non forniscono metodologie.
Il primo passo per creare siti accessibili è creare siti che siano
accessibili alle macchine. La migliore chance per ottenere ciò è usare
linguaggi di markup standard.

Separazione tra
Contenuto e Presentazione
XHTML + CSS

Separare il contenuto dalla Presentazione
Il contenuto di un documento è ciò che questo comunica
all'utente attraverso linguaggio naturale, immagini, suoni,
filmati, animazioni, ecc.
La presentazione di un documento è il modo in cui il
documento è riprodotto
 (es. stampato, presentazione grafica bi-dimensionale, presentazione solo
testuale, discorso riprodotto da un sintetizzatore, braille, ecc.)
Tutti i possibili tipi di presentazione di un documento
dovrebbero mostrare contenuti equivalenti
 Prevedere più canali sensoriali
 Non prevedere vincoli su parametri di utilizzo di un
determinato “user agent”

Separare il contenuto dalla Presentazione
Primo passo da compiere: eliminare dal codice HTML gli
elementi e gli attributi di presentazione.
 A partire dalla versione 4 delle specifiche HTML, l'uso di elementi
e attributi di presentazione è stato disapprovato dal W3C in
favore, appunto, dell'uso dei fogli di stile.
Presentazione: Impatto dei CSS sul Web
 Riduzione del peso medio di una pagina del 50-60%.
 Possibilità di presentazioni alternative, ciascuna adatta alla
riproduzione su una differente periferica (schermo, stampa,
sintetizzatori vocali, ecc.)
 Ottenimento di un codice (x)HTML più lineare e pulito, senza il
ricorso ad artifici sconsigliati per l'accessibilità

Presentazioni alternative
Più dispositivi = Più presentazioni
 I browser non offrono un supporto uniforme
ed universale al cambio automatico del foglio di
stile a seconda del tipo di media.. Si deve spesso
ricorrere a Tecniche di Style Switching
Terminali / Telescriventi / Palmari
(media="tty” o media=“handheld”)
Impossibile trovare un foglio di stile universalmente
adatto
 Braille
(media=“braille”)
Sono realmente supportati dai CSS?
Uno sviluppatore vedente possiede le
competenze per generare un tale foglio di stile?
 Sintetizzatori vocali
(media=“aural”)
Praticamente nessuno sviluppatore conosce le
esigenze di ascolto dell’utente finale..
CSS 2 Media Types
all
aural
braille
embossed
handheld
print
projection
screen
tty
tv

XHTML (eXtensible HyperText Markup Language)
XHTML è il successore di HTML
 XHTML 1.0 = riformulazione di HTML 4.01 in XML 1.0
Obiettivi
 Separazione tra la struttura del documento e la presentazione
 utilizzare CSS preferibilmente esterni
 Riformulare HTML come XML
Versioni
 XHTML 1.0 Transitional
 XHTML 1.0 Strict
 XHTML 1.0 Frameset
 XHTML 1.1
 XHTML 2.0

Creazione di pagine XHTML (1/3)
Specificare un XHTML DOCTYPE valido
XHTML 1.0 Transitional (default in ASP.NET 2.0)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
XHTML 1.0 Strict
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XHTML 1.0 Frameset
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml11.dtd">
XHTML 2.0
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml2.dtd">

L’elemento root deve referenziare un namespace XHTML
<html xmlns="http://www.w3.org/1999/xhtml" >
Tutti gli elementi e gli attributi devono essere “lowercase”
I valori degli attributi devono essere compresi tra “quotation
marks”
Gli elementi non vuoti che possiedono un tag di apertura devono
avere un corrispondente tag di chiusura.
 Es. <br>  <br></br> o <br /> (meglio!)
No “tag overlapping”
No “attribute minimization”
 <input id=“mcb” type="checkbox" checked /> (NO)
Usare l’attributo ‘id’ invece dell’attributo ‘name’

Il contenuto di <script> e <style> all’interno di una pagina deve
essere compreso nella sezione CDATA
<script type="text/javascript">
<![CDATA[
function isLess(a, b) { if (a < b) return true;
else return false; }
]]>
</script>
<script type="text/javascript">
/* <![CDATA[ */
function isLess(a, b) { if (a < b) return true;
else return false;}
/* ]]> */
</script>

XHTML e MIME (Content) Types
W3C specifica un MIME Type per i documenti XHTML
application/xhtml+xml
Come presentare contenuti XHTML
 IE6+ non supporta application/xhtml+xml
 Firefox e Opera supportano application/xhtml+xml
Possibili Rendering Workarounds per IE6+:
Utilizzare il MIME Type text/html (ASP.NET default)
Utilizzare application/xml o text/xml (XML + XSL)
Negoziazione: MIME Types differenti in base al Browser
 ASP.NET: evento Application_PreSendRequestHeaders

Usato dai browser per effettuare il corretto rendering di siti Web
sia standard-compliant che legacy
QUIRKS
Mode
DOCTYPE Sniffing (Switching)
ALMOST
Standards
Mode
Standards
Mode
FULL
Standards
Mode
Javascript Property document.compatMode
BackCompat/QuirksMode
CSS1Compat (Standards)

W3C WAI (Web Accessibility Initiative)

Web Content Accessibility Guidelines 1.0
Priorità
 Ogni checkpoint (65 in totale) ha un livello di priorità a
seconda dell’impatto che esso possiede a livello di
accessibilità
 Priorità 1: must (requisiti di base)
 Priorità 2: should (rimozione di barriere per l’accessibilità)
 Priorità 3: may (miglioramenti per l’accessibilità)
Conformità
 Tutti i checkpoints con priorità 1 sono soddisfatti
 Tutti i checkpoints con priorità 1 e 2 sono soddisfatti
 Tutti i checkpoints con priorità 1,2 e 3 sono soddisfatti
La dichiarazione di conformità è responsabilità del webmaster o del content provider.
Lo spirito è quello di dimostrare l' impegno e testimoniare i risultati conseguiti.

1. Fornire alternative equivalenti al contenuto audio e
visivo
 “Fornire un contenuto che, quando viene presentato all'utente, gli
trasmetta essenzialmente la stessa funzione o scopo del contenuto
audio o visivo.”
Considerazioni
 La versione testuale può essere velocemente incanalato verso la
sintesi vocale e la display braille, e può essere presentato
visivamente (in vari formati) sul video del computer o su carta.
 Anche fornire equivalenti non testuali (come immagini, video e
audio pre-registrati) del testo scritto è di beneficio per alcuni utenti,
specialmente per gli illetterati o per le persone che hanno difficoltà di
lettura.

Web Captioning
Caption = versione testuale di una parola pronunciata
 Sincronizzazione: il testo dovrebbe apparire approssimativamente nello stesso istante in
cui l’audio diventa disponibile
 Equivalenza: il contenuto fornito nella versione testuale dovrebbe essere equivalente a
quello pronunciato
 Accessibilità: la versione testuale deve essere leggibile da un qualunque dispositivo
Tecnologie
 SMIL (Synchronized Multimedia Integration Language)
 Quicktime e RealPlayer
 SAMI (Synchronized Accessible Media Interchange)
 Windows Media Player
 Text Track
 Quicktime
 MAGpie
 Creazione di “caption files”
 Hi-Caption
 Creazione di “caption files”

2. Non fare affidamento sul solo colore
“Assicurarsi che il testo e la parte grafica siano comprensibili se
consultati senza il colore.”
 2.2 [Priorità 2 per le immagini, Priorità 3 per il testo] (Sbagliato?)
Assicurarsi che le combinazioni fra colori dello sfondo e del primo piano forniscano un
sufficiente contrasto se visti da qualcuno con deficit percettivi sul colore o se visti su uno
schermo in bianco e nero.
Considerazioni
Tra primo piano e sfondo ci dovrebbe essere il massimo contrasto
possibile, privilegiando la luminosità e non il tono (frequenza).
Per gli ipovedenti, usare colori non eccessivamente luminosi e saturi,
altrimenti possono verificarsi fastidiosi fenomeni di abbagliamento.
Evitare sia Texture sotto il testo che il movimento disaccoppiato del
testo rispetto all’immagine sullo sfondo

3. Usare marcatori e fogli di stile e farlo in modo
appropriato
 “Marcare i documenti con i corretti elementi strutturali. Controllare la
presentazione con fogli di stile piuttosto che con elementi e attributi
di presentazione.”
Considerazioni
 Un titolo = un contenuto
 Non saltare livelli logici nell'uso delle intestazioni (H1…H6)
 Scegliere bene gli elementi strutturali
 Quando esiste un linguaggio di marcatori adatto, per veicolare
informazione usare un marcatore piuttosto che le immagini (es.
MathML – Mathematical Markup Language).

4. Chiarire l'uso di linguaggi naturali
 “Utilizzare marcatori che facilitino la pronuncia o l'interpretazione di
testi stranieri o abbreviati.”
Considerazioni
 Contrassegnare i cambiamenti di linguaggio naturale: gli screen
reader e le periferiche braille possono selezionare automaticamente
la nuova lingua, rendendo il documento più accessibile agli utenti
multilingue.
 Gli sviluppatori dovrebbero identificare il linguaggio naturale
principale del contenuto di un documento (mediante marcatori o
intestazioni HTTP).…  anche per i motori di ricerca!
 quando una stessa sigla ricorre più volte, viene definita da un
elemento ABBR o ACRONYM solo la prima volta che appare nel
testo

5. Creare tabelle che si trasformino in maniera elegante.
 “Assicurarsi che le tabelle abbiano la marcatura necessaria per
essere trasformate dai browser accessibili e da altri interpreti.”
Considerazioni
 Le tabelle, in qualsiasi modo siano usate, presentano problemi
particolari per gli utenti con lettori di schermo
 Alcuni interpreti consentono agli utenti di navigare fra le celle delle
tabelle e di accedere alle intestazioni e ad altre informazioni nelle
celle.
 Due tipi: tabelle dati e tabelle di impaginazione, distinguibili
tramite relazioni semantiche (orizzontali/verticali) tra celle nella
versione linearizzata
 Caso critico: tabelle di impaginazione contenenti tabelle dati.
 Le tabelle dati possono essere rese accessibili, o più accessibili,
utilizzando un apposito codice di marcatura strutturale

6. Assicurarsi che le pagine che danno spazio a nuove
tecnologie si trasformino in maniera elegante.
 “Assicurarsi che le pagine siano accessibili anche quando le
tecnologie più recenti non sono supportate o sono disabilitate”.
Considerazioni
 Comunicare la struttura logica unicamente per mezzo della presentazione
visuale non è una soluzione accessibile!
7. Assicurarsi che l'utente possa tenere sotto controllo i
cambiamenti di contenuto nel corso del tempo.
 “Assicurarsi che gli oggetti in movimento, lampeggianti, scorrevoli o
che si autoaggiornano possano essere arrestati temporaneamente o
definitivamente”.

8. Assicurare l'accessibilità diretta delle interfacce
utente incorporate.
 “Assicurarsi che la progettazione delle interfacce utente segua i
principi dell'accessibilità: accesso alle diverse funzionalità
indipendente dai dispositivi usati, possibilità di operare da tastiera,
comandi vocali, ecc.”
9. Progettare per garantire l'indipendenza da dispositivo
 “Usare caratteristiche che permettono di attivare gli elementi della
pagina attraverso una molteplicità di dispositivi di input.”
 In genere, le pagine che permettono di interagire tramite tastiera sono accessibili
anche tramite input vocale o interfaccia a linea di comando.

Javascript e Accessibilità
Questioni Critiche
Navigazione, Contenuti Nascosti, Controllo da parte
dell’utente, Disorientamento
Soluzioni
 Usare Gestori di eventi indipendenti dal dispositivo (ad esempio,
quelli che non richiedono l'uso del solo mouse)
 Pagine web che utilizzano gli script devono essere completamente
navigabili da tastiera
 Javascript non dovrebbe modificare o ridefinire le normali
funzionalità del browser
 Nel caso in cui javascript non possa essere reso direttamente
accessibile, deve essere predisposta un'alternativa accessibile
 Contenuti e funzionalità devono comunque essere accessibili

10. Usare soluzioni provvisorie.
 “Usare soluzioni provvisorie in modo che le tecnologie assistive e i
browser più vecchi possano operare correttamente.”
11. Usare le tecnologie e le raccomandazioni del W3C.
 “Usare le tecnologie del W3C (in conformità con le specifiche) e
seguire le raccomandazioni sull'accessibilità. Nei casi in cui non sia
possibile usare una tecnologia del W3C, oppure se nell'utilizzarla si
ottenesse materiale che non si trasforma in maniera elegante,
fornire una versione alternativa del contenuto che sia accessibile.”
12. Fornire informazione per la contestualizzazione e
l'orientamento.
 “Fornire informazione per la contestualizzazione e l'orientamento,
per aiutare gli utenti a comprendere pagine od elementi complessi.”

13. Fornire chiari meccanismi di navigazione.
 Identificare con chiarezza l'obiettivo di ogni collegamento
 Creare una Mappa oppure un indice del sito
 Usare meccanismi di navigazione in modo coerente.
 Fornire barre di navigazione
 Raggruppare i collegamenti correlati, identificare i gruppi (per gli interpreti) e, fornire un
modo per saltare il gruppo.
 Se sono fornite funzionalità di ricerca, rendere possibili diversi tipi di ricerca per differenti
livelli di abilità e per preferenze diverse.
14. Assicurarsi che i documenti siano chiari e semplici.
 “Assicurarsi che i documenti siano chiari e semplici in modo che possano
essere compresi più facilmente.”
 Usare il linguaggio più chiaro e semplice possibile che sia adatto al contenuto di un sito.
 Integrare il testo con presentazioni grafiche o uditive nei casi in cui esse possano
facilitare la comprensione della pagina.
 Creare uno stile di presentazione coerente fra le pagine.

Evoluzione delle WCAG 1.0
Stessi principi ispiratori
Struttura diversa
Si considerano anche aspetti di qualità del sito:
 usabilità
 rispetto delle specifiche tecniche.
Concetti generali da applicare ai contenuti web
Principi di progettazione non specifici per HTML, XML, o altre
tecnologie
Principi da applicare a una varietà di situazioni e tecnologie,
anche non ancora esistenti
Attualmente a livello di Working Draft
 (aprile 2007: Candidate Recommendation)

La struttura
Quattro principi di progettazione
 Percezione: il contenuto deve essere percettibile
 Operabilità: gli elementi dell' interfaccia presenti nel contenuto
devono essere azionabili
 Comprensibilità: contenuto e controlli devono essere comprensibili
 Robustezza: il contenuto deve essere abbastanza robusto da poter
operare con le tecnologie presenti e future
Per ogni principio, delle linee guida (13 in tutto) definiscono
come si applica il principio in un' area specifica
Per ogni linea guida, tre livelli di criteri di successo (“success
criteria”), verificabili, per definire meglio le linee guida e
determinare la conformità

Confronto tra WCAG 1.0 e WCAG 2.0
Stato del documento
 WCAG 1.0: unico documento stabile e referenziabile (Recommendation)
 WCAG 2.0: documento ancora in fase di raffinamento (Working Draft)
Conformità
 WCAG 1.0: guideline con checkpoint. Conformità basata su checkpoint.
 WCAG 2.0: principi, guideline e “success criteria”. Conformità basata su
success criteria.
Tecniche
 WCAG 1.0: un documento contenente i link alle varie tecniche, un documento
("Core") generale, e due documenti specifici (HTML e CSS)
 WCAG 2.0: un documento generale, contenente link e tecniche generali, e
vari documenti specifici (già disponibili HTML, CSS, client-side scripting, etc.)
Checklist
 WCAG 1.0: lista di checkpoint raggruppati per priorità
 WCAG 2.0: lista di proposizioni verificabili che specificano cosa è richiesto
per essere conformi alle WCAG 2.0 in quella specifica tecnologia

Validare XHTML
Un documento XHTML, come HTML è valido se
Al suo inizio è dichiarata la DTD utilizzata nel documento;
Gli elementi e gli attributi adoperati rispettano alla lettera la
sintassi per loro definita nella DTD dichiarata all'inizio
Markup Validator Service (http://validator.w3.org/)
Errori comuni:
 Elementi aperti e non chiusi o viceversa
 Elementi incastrati invece che annidati (p.es. <b><i> ... </b></i>,
invece di <b><i> ... </i></b>)
 Uso di elementi e attributi non consentiti dalla Dtd adoperata
 Uso del carattere ‘&' in una stringa di query invece di ‘&'
 Uso di valori di attributo non consentiti
 Il testo di <noscript> deve essere incluso in un elemento strutturale
 lang invece di xml:lang
 L’attributo language non può essere usato per <script> e <style>

Validare CSS
CSS Validator (http://jigsaw.w3.org/css-validator/)
CSS Check (http://www.htmlhelp.com/tools/csscheck/)
Errori Comuni
 Mancanza del punto e virgola finale che chiude la dichiarazione di una
proprietà
 Mancanza della parentesi graffa che chiude un elenco di proprietà
 Un colore dichiarato in valori esadecimali non preceduti dal simbolo ‘#'
 ‘Sans-serif' scritto senza il trattino separatore
 Nomi di classe e id non validi
 Un commento (/* ... */) aperto e non chiuso, o viceversa
Risolvere gli avvertimenti (warning)
 Mancata indicazione di una famiglia di caratteri generica (Sans-Serif)
 Mancata definizione del colore di primo piano se è stato definito il colore di
sfondo, e viceversa
 Uso di dimensionamenti fissi in luogo di quelli relativi e percentuali

Validazione dell’accessibilità (W3C)
WCAG 1.0 – Appendice A
 “Verificate l'accessibilità per mezzo di strumenti automatici e della
revisione umana. I metodi automatici sono in genere rapidi e
convenienti ma non possono identificare tutti i problemi di accessibilità.
La revisione umana può aiutare a garantire la chiarezza del linguaggio
e la semplicità della navigazione”
Consigli W3C
Controllare con strumenti automatici la validità della sintassi (x)HTML
e CSS, nonché le misure prese per favorire l'accessibilità.
 Nessun controllo automatico è in grado di valutare al 100% l'accessibilità di
una pagina web
Verificare la percepibilità dei contenuti per mezzo della vista e
dell'udito nelle più disparate condizioni d'uso
Controllare l’ortografia e valutare la leggibilità, eventualmente con
strumenti automatici
Ricorrere al giudizio possibilmente di persone con disabilità

Dichiarare la conformità alle WCAG 1.0
La guerra dei bollini
 Una pretesa di conformità spesso senza certificazione
 Di fatto è una truffa per l’utente che non ha bisogno di bollini, ma di
accessibilità
 Senza revisori umani l’accessibilità non esiste
 Esporre soltanto le dichiarazioni di conformità di cui si è
assolutamente sicuri e che possono essere verificate dall'utente
 Predisporre nel sito una pagina, in cui dichiarate quali controlli di
revisione umana sono stati effettuati in aggiunta ai test automatici, e
quando e come sono stati eseguiti l'ultima volta.
Portale “Spazio Europa della regione Emilia Romagna”
 Conformità ad HTML 4.01, CSS 2.0, Bobby AAA e Bobby Section
508, WCAG 1.0 AAA … NOOOO!
 Diffidare di siti con abbondanza di bollini, soprattutto se sono
teoricamente incompatibili

I migliori strumenti automatici
AIS (Web Accessibility Toolbar) IE
Web Developer (Firefox)
Internet Explorer Developer Toolbar IE
Lynx Browser/Viewer
Fang (Firefox)
HTML Tidy
 strumento a linea di comando molto potente: è in grado di individuare e correggere
errori di sintassi (X)HTML e di fornire utili suggerimenti per il miglioramento
dell'accessibilità. Ora su Source Forge
A-Prompt
 Un valutatore dell'accessibilità sviluppato dall'Università di Toronto, da scaricare in
locale: è in grado di fornire indicazioni di conformità sia alla Section 508 sia alle
WCAG 1.0.
Wikipedia (Paragone tra Screen Reader)
 ( http://en.wikipedia.org/wiki/List_of_screen_readers )

I migliori strumenti automatici
WebXact (http://webxact.watchfire.com)
 Strumento di validazione on line della Watchfire, la stessa casa produttrice di Bobby.
Offre all'incirca le stesse informazioni di Bobby, ma in un modo più organizzato ed
usabile.
Cynthia Says portal (http://www.contentquality.com)
 Consente una valutazione dell'accessibilità che si estende in qualche misura anche
alla proprietà dei testi alternativi: valuta per esempio la lunghezza dei testi ALT e se
questi ripetono il nome dell'immagine a cui si riferiscono.
Torquemada (http://www.webxtutti.it)
 Valutatore automatico dell'accessibilità tutto italiano, sviluppato dalla Fondazione Ugo
Bordoni.
WAVE 3.5 Accessibility Tool (development version) (
http://dev.wave.webaim.org)
 I risultati della validazione sono rappresentati graficamente e gli avvertimenti sono
contestuali alla posizione di rilevamento.
Web Accessibility Checker (http://checker.atrc.utoronto.ca)
 Supporto alla Legge Stanca

Conclusioni
Consigli Finali per una buona accessibilità
Separare SEMPRE la presentazione dal contenuto
Usare DTD rigorose (es. XHTML 1.1 o XHTML 1.0 Strict)
Mai basarsi sul colore per fornire informazioni
Evidenziare la struttura logica dei contenuti testuali
 H1,H2,H3 etc.
Realizzare moduli accessibili
 FIELDSET, LEGEND, LABEL etc. + CSS
Massima attenzione alle tabelle dati
 TH, SUMMARY, CAPTION etc.
Occhio alla linearizzazione dei contenuti (sostituire le tabelle usate
a scopo di impaginazione con soluzioni basate sui CSS)
 Scrivere testi accessibili e non dipendenti da un ambito

Conclusioni
Consigli Finali per una buona accessibilità
Non usare i FRAME
Assicurarsi di scrivere XHTML e CSS validi
Usare revisione automatiche per gli errori di accessibilità legati
al codice
Usare la revisione umana
Porsi come obiettivo il raggiungimento di un'accessibilità
reale

Grazie per l’attenzione…
FINE

Accessibilità: tecniche e validazione

Recommandé

Recommandé

Contenu connexe

Similaire à Accessibilità: tecniche e validazione

Similaire à Accessibilità: tecniche e validazione (20)

Plus de DotNetMarche

Plus de DotNetMarche (20)

Accessibilità: tecniche e validazione

Notes de l'éditeur