Apri File

L’accessibilità dei siti Web
Le raccomandazioni del
World Wide Web Council
(W3C)
Giorgio Sommi - ASPHI
G. Sommi - ASPHI
Accessibilità
• Possibilità di accedere
• Possibilità di fare uso di qualcosa
• Possibilità di fare uso di qualcosa in
presenza di fattori condizionanti
(disabilità)
G. Sommi - ASPHI
Accessibilità
• Accessibilità fisica (mobilità)
• Accessibilità al computer
• ai dispositivi
• alle applicazioni
G. Sommi - ASPHI
Accessibilità a Internet
Si riferisce al contenuto delle pagine Web, cioè
a quanto viene presentato come
•
•
•
•
•
•
linguaggio naturale
immagini
suoni
filmati
animazione
...
G. Sommi - ASPHI
Accessibilità a Internet
I criteri (guidelines) per rendere accessibili le
pagine Web sono definite nel documento
Web Content Accessibility Guidelines 1.0 (WCAG)
raccomandazione emessa dal
World Wide Web Consortium (W3C)
nel quadro della
Web Accessibility Initiative (WAI)
G. Sommi - ASPHI
World Wide Web Consortium
Ha come Enti rappresentativi in
• USA (Laboratorio di Computer Science, MIT)
• Europa (INRIA, Francia)
• Giappone (Università di Keio)
con il supporto di
• DARPA (USA)
• Unione Europea
Raccoglie attualmente più di 400 soci
G. Sommi - ASPHI
Attività del W3C
• Interfaccia utente
Document Object Model: DOM
Graphics: SVG (Scalable Vector Graphics, WebCGM
(Computer Graphics Metafile)
HTML
Internationalization
Math: MathML
Mobile Access
Style Sheets: CSS, XSL(Extensible Stylesheet Language
Synchronized Multimedia: SMIL (SM Integration Language)
Television and the Web
Voice Browser
G. Sommi - ASPHI
Attività del W3C
• Tecnologia e Società
Electronic Commerce
Metadata: RDF (Resource Description Framework),
PICS (Platform for Internet Content Selection)
Privacy: P3P (Platform for Privacy Preferences)
XML Signature
• Architettura
HTTP
Web Characterization
XML
G. Sommi - ASPHI
Attività del W3C
• Accessibilità al Web (WAI)
WAI Accessibility Guidelines
WAI International Program Office
WAI Technical Activity
G. Sommi - ASPHI
Web Accessibility Initiative
I principali contributi all’iniziativa vengono da
• U.S. National Science Foundation,
• U.S. Department of Education's National Institute on Disability and
Rehabilitation Research,
• European Commission's DG XIII Telematics Applications
Programme for Disabled and Elderly,
• the Government of Canada,
• IBM,
• Lotus Development Corporation,
• Microsoft Corporation, and
• NCR.
G. Sommi - ASPHI
Aspetti della accessibilità
• Contenuto del Web
• Authoring Tools
Editors HTML, Strumenti per la conversione di
documenti, Strumenti che generano pagine
Web da databases
•User Agents
Software per accedere alle pagine Web
(browsers, browsers a voce, telefonia mobile,
personal computers a bordo di automobili, oltre
a screen readers, screen magnifiers e
software per l’immissione a voce
(assistive technology).
G. Sommi - ASPHI
Altri documenti
sull’accessibilità (1)
• Authoring Tools Accessibility Guidelines 1.0 - ATAG
(Raccomandazione W3C, febbraio 2000)
• User Agent Accessibility Guidelines - UAAG
/Raccomandazione proposta, marzo 2000)
G. Sommi - ASPHI
Altri documenti
sull’accessibilità (2)
• "Techniques for Web Content Accessibility
Guidelines 1.0” ([TECHNIQUES]),
• "Core Techniques for Web Content Accessibility
Guidelines 1.0" ([WCAG10-CORE-TECHNIQUES]),
• "HTML Techniques for Web Content Accessibility
Guidelines 1.0" ([WCAG10-HTML-TECHNIQUES]
• "CSS Techniques for Web Content Accessibility
Guidelines 1.0" ([WCAG10-CSS-TECHNIQUES]),
G. Sommi - ASPHI
A chi servono le linee guida
del WAI
• Anche se primariamente intese per i disabili le
raccomandazioni servono a rendere più accessibili
le pagine Web a tutti indipendentemente da
• user agent
• condizioni operative
(ambienti rumorosi, locali poco o troppo
illuminati, necessità di operare a mani libere,
ecc.)
G. Sommi - ASPHI
Gli utenti con problemi di
accessibilità (1)
• Coloro non in grado di vedere, di udire, di muoversi, o non in grado
di trattare con facilità o non trattare del tutto certe informazioni.
• Coloro che hanno difficoltà a leggere o a comprendere i testi.
• Coloro che non dispongono di tastiera o di mouse o non sono in
grado di usarla .
• Coloro che hanno schermi a solo testo, uno schermo piccolo, o
un collegamento a Internet lento.
G. Sommi - ASPHI
Gli utenti con problemi di
accessibilità (2)
• Coloro che non parlano o non capiscono il linguaggio nel quale un
certo documento è scritto
• Coloro che sono in una situazione nella quale i loro occhi, orecchi
e mani sono impegnati o in qualche modo impediti (per es. guida
dell’auto per recarsi al lavoro, ambiente di lavoro rumoroso)
• Coloro che non dispongono dell’ultima versione di un browser,
hanno un browser totalmente diverso, un browser a voce, o
un diverso sistema operativo
G. Sommi - ASPHI
Una progettazione
accessibile deve
• Assicurare una trasformazione agevole (graceful)
delle pagine
• Rendere i contenuti comprensibili e navigabili
G. Sommi - ASPHI
Alcune definizioni
Elemento ciò che specifica la struttura (i tag HTML)
Struttura come il documento è organizzato logicamente
Presentazione come il documento viene reso per l’utente
(testo o sintesi vocale o braille ...)
Stylesheet un insieme di specifiche che descrivono la
presentazione di un documento. Può essere
- fornito con il contenuto
- creato dall’utente
- inserito nello user agent
Tecnologia per l’assistenza
Meccanismo di navigazione
G. Sommi - ASPHI
Linee guida
per l’accessibilità
•
•
•
•
Il documento WCAG ne fornisce 14
Da 1 a 11 sono relative alla trasformazione agevole
Da 12 a 14 alla navigabilità e comprensibilità
Per ciascuna vengono indicati
• L’enunciato
• Il razionale che sta dietro l’enunciato
• Una lista di checkpoints (come la linea guida si applica
in scenari tipici). Per ogni checkpoint viene dato
• enunciato
• priorità, che specifica come deve essere rispettato il
checkpoint
1. Must
2. Should
3. May
G. Sommi - ASPHI
1. Fornire alternative equivalenti ai
contenuti uditivi e visivi
Fornire un contenuto che, quando presentato,
assolve essenzialmente alla stessa funzione o scopo
sia come contenuto visivo che uditivo.
Text equivalent di informazione grafica o audio
Non-text equivalent di una presentazione visiva in
audio o in linguaggio dei segni
G. Sommi - ASPHI
1. Fornire alternative equivalenti ai
contenuti uditivi e visivi
Checkpoints e priorità
1.1 Fornire un testo equivalente per ogni elemento non testo (1)
1.2 Fornire collegamenti testuali ridondanti per ogni regione
attiva di una image map posta dal lato del server (1)
1.3 Fino a quando gli user agent non saranno in grado di leggere a voce il
testo che accompagna una sequenza visiva, fornire una descrizione
testuale della sequenza (1)
1.4 Per ogni presentazione multi mediale che dipende dal tempo (filmato o
animazione) sincronizzare le alternative equivalenti (testo o messaggio
vocale) con le immagini (1)
1.5 Fino a quando gli user agent non evidenzieranno gli equivalenti per i
collegamenti a immagini dal lato client, fornire collegamenti testuali
ridondanti per ogni regione attiva di una image map posta dal lato
del client (3)
G. Sommi - ASPHI
2. Non affidarsi soltanto al colore
Assicurarsi che il testo e le figure siano comprensibili
anche senza colore
Alcune persone non distinguono i colori
Se hanno la stessa tonalità due colori confondibili
possono essere percepiti senza sufficiente contrasto
G. Sommi - ASPHI
2. Non affidarsi soltanto al colore
Checkpoints e priorità
2.1 Assicurarsi che tutta l’informazione trasmessa dall’uso del colore sia
derivabile anche senza colore, ad esempio dal contesto o dal markup (1)
2.2 Assicurarsi che le combinazioni di colori di primo piano e di sfondo
forniscano un contrasto sufficiente per un osservatore che abbia deficit nella
visione del colore o quando la pagina deve essere visualizzata sulo schermo
in bianco e nero (2 per le immagini, 3 per il testo.)
G. Sommi - ASPHI
3. Usare in modo appropriato
markup e style sheets
Nei documenti usare gli elementi strutturali adatti
Per la presentazione servirsi di style sheets piuttosto
che di elementi e attributi.
Per es. usare una tabella per specificare un layout o un
header per cambiare il font può rendere difficile sia la
comprensione del contenuto sia la navigazione attraverso di esso a chi fa uso di software speciale.
Evitare sia l’uso non appropriato per essere compatibili
con vecchi browsers, sia l’uso appropriato del tag
TABLE perché alcuni browsers non lo supportano.
G. Sommi - ASPHI
3. Usare in modo appropriato
markup e style sheets
Checkpoints e priorità
3.1 Quando esiste un linguaggio di markup appropriato, usare il markup
anziché le immagini per trasmettere l’informazione (2)
3.2 Creare documenti validabili da grammatiche formali pubblicate (2).
3.3 Usare style sheets per controllare la struttura e la presentazione(2).
3.4 Usare unità relative anziché assolute per gli attributi del linguaggio
markup e le proprietà degli style sheet (2)
3.5 Usare elementi “header” per strutturare i documenti e usarli secondo le
specifiche (2)
3.6 Usare propriamente il Mark up per le liste e per gli elementi di liste (2)
3.7 Usare il mar up per testi fra apici. Non usare il markup per ottenere
effetti di formattazione come il rientro (indentazione) (2)
G. Sommi - ASPHI
4. Rendere chiaro l’uso del linguaggio naturale
Usare notazioni che facilitano la pronuncia o la comprensione di testo in lingua straniera o abbreviato
Se vi è un cambiamento di lingua nel testo segnalarlo
in modo che i sintetizzatori ne possano tener conto.
Dare indicazioni per esteso del contenuto di abbreviazioni o sigle.
Oltre ad essere utili per tutti questo criterio è particolarmente utile per chi ha disabilità di apprendimento
o cognitive oppure è sordo.
Sigle e abbreviazioni risultano particolarmente indecifrabili se rese in sintesi vocale o in braille.
G. Sommi - ASPHI
4. Rendere chiaro l’uso del linguaggio naturale
Checkpoints e priorità
4.1 Identificare chiaramente i cambiamenti nella lingua usata nel testo di un
documento e in ogni equivalente di testo (ad es. didascalie) (1)
4.2 Specificare il contenuto esteso di una abbreviazione o di una sigla la
prima volta che questa compare in un documento (3)
4.3 Identificare la lingua di base di un documento (3).
G. Sommi - ASPHI
5. Creare tabelle che si trasformano
agevolmente
Assicurarsi che le tabelle abbiano il markup necessario
per essere trasformate da browser accessibili e da altri
user agents.
Le tabelle vanno usate solo per dati strutturati in forma
tabellare e non per organizzare la disposizione. Diversamente si creano problemi a chi usa screen readers.
Come pure a chi usa PC a bordo di auto, o a chi vede
una porzione di schermo alla volta (chi ha problemi di
ipovisione o deve usare schermi piccoli).
G. Sommi - ASPHI
5. Creare tabelle che si trasformano
agevolmente
Checkpoints e priorità
5.1 Nelle tabelle di dati identificare le intestazioni di righe e di colonne (1)
5.2 Nelle tabelle di dati che hanno due o più livelli logici di intestazione di
riga o colonna usare il markup per associare celle di dati con celle di
intestazione (1)
5.3 Non usare tabelle per strutturare la pagina a meno la tabella non abbia
senso una volta linearizzata. Altrimenti fornire una versione equivalente (ad
es. una versione linearizzata) (2)
5.4 Se si usa una tabella per l’impaginazione, non usare alcun mark up
strutturale per conseguire una formattazione visiva (2)
5.5 Fornire sommari delle tabelle (3)
5.6 Usare abbreviazioni per le etichette delle intestazioni (3)
G. Sommi - ASPHI
6. Fare in modo che le pagine che fanno uso di
nuove tecnologie si trasformino agevolmente
Assicurarsi che le pagine siano accessibili anche se
le tecnologie più recenti non sono supportate o sono
disabilitate
Anche se è consigliato prendere in considerazione le
nuove tecnologie che aiutano a superare problemi, il
fatto di adottarle non deve precludere la possibilità
di accedere alle pagine a chi usa versioni non aggiornate di browser o sceglie di non attivare la nuova
tecnologia (p.e. stylesheets)
G. Sommi - ASPHI
6. Fare in modo che le pagine che fanno uso di
nuove tecnologie si trasformino agevolmente
Checkpoints e priorità
6.1 Organizzare i documenti in modo che si possano leggere senza style sheets. Ad
esempio, un documento HTML deve risultare leggibile se visualizzato senza far uso
degli style sheets che contiene (1)
6.2 Assicurarsi che gli equivalenti di un contenuto dinamico si aggiornino col
cambiare del contenuto (1)
6.3 Assicurarsi che le pagine si possano ancora usare quando scripts, applets, o altri
oggetti di programmazione siano disattivati o non supportati. Se ciò non è possibile,
fornire un’informazione equivalente in un’altra pagina accessibile (1)
6.4 Per gli scripts e applets, assicurarsi che gli “event handlers” siano indipendenti
dal dispositivo di input (2)
6.5 Assicurarsi che il contenuto dinamico sia accessibile o fornire una presentazione o
una pagina alternative (2)
G. Sommi - ASPHI
7. Assicurare che l’utente possa controllare il
contenuto dipendente dal tempo
Fare in modo che oggetti o pagine che si muovono, lampeggiano, scorrono o si auto-aggiornano possano essere
messi in pausa o fermati.
Alcune persone con problemi cognitivi o di visione non
riescono a leggere il testo in movimento. Così pure gli
screen readers. Chi ha disabilità agli arti superiori può
avere problemi nell’interagire con oggetti in movimento.
G. Sommi - ASPHI
7. Assicurare che l’utente possa controllare il
contenuto dipendente dal tempo
Checkpoints e priorità
7.1 Fino a quando gli user agents non consentano di controllare il
“flickering”, evitare il tremolio dello schermo (1)
7.2 Fino a quando gli user agents non consentano di controllare il “blinking”,
evitare di far lampeggiare il contenuto (ad es., cambiare la presentazione a
intervalli regolari attivandola e disattivandola) (2)
7.3 Fino a quando gli user agents non permettano di congelare il movimento,
evitare parti in movimento nelle pagine (2)
7.4 Fino a quando gli user agents non forniscano la possibilità di fermare il
refresh, non creare pagine che periodicamente fanno auto-refresh (2)
7.5 Fino a quando gli user agents non consentano di fermare l’” autoredirect”, non usare il markup per ridirigere le pagine. Invece, configurare il
server per eseguire il “redirect” (2)
G. Sommi - ASPHI
8. Assicurare la diretta accessibilità delle
interfacce d’utente incorporate
Assicurarsi che l’interfaccia d’utente segua i principi
della progettazione accessibile: accesso alle funzioni
indipendente dal dispositivo, operabilità con tastiera,
vocalizzazione ...
Quando l’oggetto incorporato ha una sua interfaccia
questa deve essere accessibile. Se non può essere
resa accessibile deve essere trovata una soluzione
alternativa che sia accessibile.
G. Sommi - ASPHI
8. Assicurare la diretta accessibilità delle
interfacce d’utente incorporate
Checkpoints e priorità
8.1 Rendere gli elementi programmatici come scripts e applets direttamente
accessibili o compatibili con la tecnologia di assistenza (1)
G. Sommi - ASPHI
9. Progettare per la device-independence
Usare accorgimenti che attivano gli elementi di una
pagina attraverso diversi dispositivi d’ingresso
Accesso indipendente dal dispositivo significa che
l’utente per accedere può scegliere il dispositivo
che preferisce: mouse, tastiera, voce, caschetto ...
Se il controllo di un modulo è attivabile col mouse
o con altro dispositivo di puntamento esclude dallo
accesso chi non ha la vista, può usare solo la voce
o dispone della tastiera o di un dispositivo non di
puntamento
G. Sommi - ASPHI
9. Progettare per la device-independence
Checkpoints e priorità
9.1 Far uso di immagini dal lato client invece di immagini dal lato server
tranne il caso in cui le aree sull’immagine non possono essere riferite a una
forma geometrica disponibile (1)
9.2 Assicurarsi che ogni elemento che possiede una sua specifica interfaccia
possa essere impiegato in modo device-independent (2)
9.3 Per gli scripts, specificare gestori di eventi logici piuttosto che gestori di
eventi device-independent (2)
9.4 Creare un ordine di tabulazione logica tramite links, controllo di form e
oggetti (3)
9.5 Usare scorciatoie via tastiera verso collegamenti importanti (inclusi quelli
in immagini lato server), controlli di form e gruppi di controlli di form (3)
G. Sommi - ASPHI
10. Usare soluzioni ad interim
Usare soluzioni ad interim per l’accessibilità in modo che le
tecnologie per l’assistenza e browsers di vecchio tipo possano
operare correttamente.
Tali browsers non consentono certe navigazioni, come pure i
vecchi screen readers leggono liste di links consecutivi come un
unico link.
Tali elementi attivi sono dunque di difficile o impossibile accesso.
Inoltre, cambiare la finestra attiva o fare pop-up di nuove finestre
può disorientare gli utenti non in grado di vedere che ciò è
accaduto.
G. Sommi - ASPHI
10. Usare soluzioni ad interim
Checkpoints e priorità
10.1 Fino a quando gli user agent non permetteranno agli utenti di chiudere finestre
“spawned”, non fare apparire pop-up o altre finestre e non cambiare la finestra attiva
senza informarne gli utenti (2)
10.2 Fino a quando gli user agent non consentano un’associazione esplicita tra
etichette e controllo di forms, per tutti i controlli che hanno associate etichette
implicite, assicurarsi che l’etichetta sia messa al posto giusto (2)
10.3 Fino a quando gli user agent (inclusa la tecnologia di assistenza) non rendono
correttamente il testo side-by-side, usare una alternativa a testo lineare (sulla pagina
corrente o in qualche altra)per tutte le tabelle che dispongono il testo in colonne
parallele e “word-wrapped” (3)
10.4 Fino a quando gli user agent non tratteranno in modo corretto i controlli vuoti,
includere caratteri place-holding di default in edit box e aree di testo (3)
10.5 Fino a quando gli user agent (inclusa la tecnologia di assistenza) non
tratteranno in modo distinto i link adiacenti, includere caratteri non appartenenti al
link e stampabili (compresi fra spazi) tra due link adiacenti (3)
G. Sommi - ASPHI
11. Usare tecnologie e linee guida W3C
Usare le tecnologie W3C e seguire le linee guida per la
accessibilità. Quando non è possibile usare una
tecnologia W3C, o il farlo produce materiale che non si trasforma
agevolmente, fornire una versione alternativa del contenuto
che sia accessibile
Le tecnologie W3C (per es. HTML, CSS) sono consigliate perché
• hanno funzioni della accessibilità incorporate
• le specifiche vengono riviste perché tengano conto della
accessibilità fin dalla fase di progetto
• le specifiche sono portate avanti in forma aperta col consenso
delle industrie
G. Sommi - ASPHI
11. Usare tecnologie e linee guida W3C
Checkpoints e priorità
11.1 Usare tecnologie W3C quando sono disponibili e adatte al compito e
usare le più recenti versioni supportate (2)
11.2 Evitare aspetti delle tecnologie W3C caduti in disuso (3)
11.3 Inserire l’informazione che consente agli utenti di ricevere i documenti
secondo le loro preferenze (ad es. lingua, tipo di contenuto, ecc.) (3)
11.4 Se, dopo i migliori sforzi, non si riesce a creare una pagina accessibile,
fornire un collegamento a una pagina alternativa che usa tecnologie W3C, è
accessible, ha informazione (o funzionalità) equivalenti ed è aggiornata tanto
spesso quanto la (originale) pagina inaccessibile (1)
G. Sommi - ASPHI
12. Fornire informazioni di contesto e di
orientamento
Fornire informazioni di contesto e orientamento aiuta
gli utenti a capire pagine o elementi complessi
Raggruppare gli elementi e fornire informazioni sulle
relazioni fra gli elementi è di aiuto a tutti gli utenti.
Relazioni complesse sono di difficile interpretazione da
parte di chi ha problemi cognitivi o di vista.
G. Sommi - ASPHI
12. Fornire informazioni di contesto e di
orientamento
Checkpoints e priorità
12.1 Dare un titolo a ogni “frame” per facilitare l’identificazione del frame e
la navigazione (1)
12.2 Descrivere lo scopo dei frames e come i frames sono in relazione fra di
loro se ciò non è chiaro dai soli titoli dei frames (2)
12.3 Dividere blocchi di informazione larghi in gruppi più gestibili, quando ciò
risulti naturale e appropriato (2)
12.4 Associare esplicitamente le etichette ai loro controlli (2)
G. Sommi - ASPHI
13. Fornire meccanismi chiari di navigazione
Provvedere chiari e consistenti meccanismi di
navigazione (informazioni d’orientamento, barre di
navigazione, mappe dei siti) per aumentare la probabilità che una persona trovi in un sito quello che sta
cercando.
Tali meccanismi sono importanti per le persone con
disabilità cognitive o cecità e sono utili a tutti gli utenti
G. Sommi - ASPHI
13. Fornire meccanismi chiari di navigazione (1)
Checkpoints e priorità
13.1 Indicare chiaramente a che cosa punta ogni collegamento (2)
13.2 Fornire meta-dati che aggiungano informazione di significato a pagine e
siti (2)
13.3 Fornire informazione sulla struttura generale di un sito (ad es. una
mappa del sito o un indice) (2)
13.4 Usare i meccanismi di navigazione in modo consistente (2)
13.5 Fornire barre di navigazione per illustrare il meccanismo di navigazione
e darvi accesso (3)
G. Sommi - ASPHI
13. Fornire meccanismi chiari di navigazione (2)
Checkpoints e priorità
13.6 Raggruppare i collegamenti correlati, identificare il gruppo (per gli user
agent), e, fino a quando non lo faranno gli user agent, dare il modo di
scavalcare il gruppo (3)
13.7 Se sono disponibili funzioni di ricerca, abilitare tipi diversi di ricerca,
livelli di abilità e tipi di preferenze diversi (3)
13.8 Porre informazioni che consentano di fare distinzioni, all’inizio di testate,
paragrafi, liste, ecc. (3)
13.9 Dare informazioni su raccolte di documenti (ad es. documenti che
comprendono pagine multiple) (3)
13.10 Fornire un modo per scavalcare parti in “multi-line ASCII art” (3)
G. Sommi - ASPHI
14. Assicurarsi che i documenti siano chiari e
semplici
Assicurarsi che i documenti siano chiari e semplici fa
sì che siano più facilmente compresi
Una disposizione consistente sulla pagina, una
grafica comprensibile e un linguaggio facile giovano
a tutti gli utenti. In particolare a chi ha problemi
cognitivi o di vista. Un linguaggio chiaro e semplice
rende la comunicazione più efficace e aiuta chi non
è della stessa lingua madre.
G. Sommi - ASPHI
14. Assicurarsi che i documenti siano chiari e
semplici
Checkpoints e priorità
14.1 Usare il linguaggio più semplice e chiaro per descrivere in modo
appropriato il contenuto di un sito (1)
14.2 Integrare il testo con presentazioni grafiche o vocali quando queste
siano in grado di facilitare la comprensione della pagina (3)
14.3 Creare uno stile di presentazione che sia consistente attraverso le varie
pagine (3)
G. Sommi - ASPHI
Convalida (1)
Le pagine costruite devono essere convalidate sia con
procedimenti automatici che “umani”. Si suggerisce di
1. Usare strumenti automatici per l’accessibilità e la verifica del
browser
2. Verificare la sintassi (es., HTML, XML, ecc.).
3. Verificare gli style sheets (es., CSS).
4. Usare un browser a solo testo o un emulatore
5. Use più di un browser grafico, con:
 suoni e grafica attivati,
 grafica non attivata,
 suoni non attivati,
 senza mouse,
 frames, scripts,G.style
Sommisheets
- ASPHI e applets non attivati
Convalida (2)
6. Usare diversi browsers, vecchi e nuovi.
7.Usare un browser con voce, uno screen reader, un software di
ingrandimento, uno schermo piccolo ...
8. Usare controlli ortografici e grammaticali.
9. Rivedere il documento per chiarezza e semplicità. Statistiche di
leggibilità sono consigliate, oltre a una revisione umana che tenga
conto di aspetti culturali
10. Invitare persone disabili a rivedere i documenti. Disabili
sia esperti che principianti forniranno entrambi utili indicazioni
sui problemi di accessibilità e usabilità e sulla loro gravità
G. Sommi - ASPHI