WCAG 2.0 e Legge Stanca

venerdì, aprile 17th, 2009 | Accessibilità | Nessun commento

La mia proposta per i nuovi requisiti italiani.

La legge “Stanca” ha come problema principale, oltre al nome, una nota  inefficacia, questo è il presupposto dal quale non si può prescindere: se la legge  non funziona e non la si può cambiare (perchè ripassare dal Parlamento è impensabile), sarebbe opportuno cercare di assolvere almeno il principio fondamentale che ne è alla base.

La pubblicazione delle WCAG 2.0 permette la revisione dei requisiti italiani. Può essere l’occasione per un cambio di rotta. Probabilmente l’approccio migliore potrebbe essere ottenere il massimo dell’accessibilità per gli utenti, fornendo requisiti che abbattano solo le vere barriere. Dei requisitie che siano utili, efficaci, chiari ed il più automatici da verificare.

Gli attuali requisiti soffrono di 3 problemi principali:

  1. Numerosità: sono troppi, alcuni inutili altri di difficile verifica, altri di difficile implementazione o manutenibilità.
  2. Unicità: essere diversi da requisiti internazionali, e rendere formalmente inutilizzabili prodotti esteri.
  3. Genericità e incompletezza: essere troppo generali e soggettivi (es. semantica), non avere un livello di dettaglio (es. ingrandimento fino a quanto?), mancare degli esempi pratici che non sono mai stati rilasciati.

Sarebbe meglio fare tesoro dell’esperienza e porsi un obiettivo raggiungibile.

La proposta: solo 12 requisiti

Questo documento rappresenta il procedimento attraverso il quale sono arrivato alla proposta definitiva.

Sono partito dalle attuali WCAG 2.0. Ho selezionato alcuni requisiti dai vari livelli A, AA, AAA al fine di rispettare tutte le linee guida. Sono partito dal presupposto che sia impossibile sostenere tutti i checkpoint e regole delle WCAG 2.0: non è umanamente possibile (cfr L’accessibilità si aggiorna al web di oggi).

In seconda battuta ho  considerato la realtà, il mio lavoro quotidiano, i risultati delle  analisi sui siti e applicazioni della regione Emilia-Romagna, e le indagini sperimentali del CSI  Piemonte.

Alla luce dei risultati ho rielaborato la prima lista, eliminando anche tutto ciò che non poteva venire individuato come vera barriera, attenendomi quindi a quanto descritto in premessa.

La prima scrematura

La scelta più semplice sarebbe stata quella di usare i livelli delle WCAG 2.0. Decidere che per l’Italia andava bene il livello A o AA, cosa che probabilmente avverrà in Europa, per semplicità.  Ho invece cercato di attenermi ai presupposti che mi ero dato, e ho individuato un sottoinsieme di requisiti, non necessariamente tutti appartenenti al primo o secondo livello delle WCAG 2.0. Alcuni requisiti sono infatti più chiari, sintetici ed impositivi a livello AAA, e in Italia abbiamo bisogno di regole certe e ferree, o le aggiriamo. Il ragionamento è che i requisiti devono cercare di essere ben definiti, e lasciare poco spazio all’interpretazione, perciò ho scelto i più restrittivi.
L’approccio che ho mantenuto è quello di essere rigidi su requisiti di facile realizzabilità che danno vantaggi significativi a tutti gli utenti, e più laschi su requisiti con costi onerosi di implementazione.

Principio 1: Percepibile - Le informazioni e i componenti dell’interfaccia utente devono essere presentabili agli utenti in modalità che possono percepire.

Linea guida 1.1 Alternative testuali:
Fornire alternative testuali per qualsiasi contenuto non di testo in modo che possa essere trasformato in altre modalità fruibili secondo le necessità degli utenti come stampa a grandi caratteri, Braille, sintesi vocale, simboli o linguaggio più semplice.

1.1.1. Contenuti non testuali. Tutti i contenuti non testuali devono avere un’alternativa testuale che fornisca informazioni analoghe, ad eccezione delle seguenti situazioni (Livello A):

  • Controlli, Input: il testo alternativo dei moduli di controllo o degli oggetti che ricevono input deve descrivere la funzionalità degli oggetti stessi. (Per altri requisiti vedere linea guida 4.1).
  • Media sincronizzati: nel caso di contenuti multimediali sincronizzati il testo alternativo deve fornire almeno una descrizione significativa dell’oggetto. (Per altri requisiti vedere linea guida 1.2).
  • Test - il testo alternativo di test o di esercitazioni deve fornire una descrizione dell’esercizio in oggetto e non la sua soluzione.
  • Esperienze sensoriali: il testo alternativo di un’esperienza sensoriale deve essere in grado di fornire la descrizione adeguata di ciò che essa mostra.
  • CAPTCHA: Se è necessario confermare che un contenuto è stato letto da una persona anziché da un computer, è necessario fornire un testo alternativo che indichi la funzionalità dell’oggetto e delle versioni alternative al CAPTCHA utilizzando modelli di rappresentazione per differenti sensi per soddisfare le diverse disabilità.
  • Decorazioni, formattazioni, contenuti invisibili: il contenuto non testuale di oggetti esclusivamente decorativi, utilizzati solo per la formattazione o non presentati agli utenti deve essere implementato in modo da poter essere ignorato tecnologie assistive.

Linea guida 1.2 Media temporizzati:
Fornire alternative per i media temporizzati.

1.2.1. Solo audio e solo video (preregistrati): Per i media preregistrati di solo audio e di solo video, sono soddisfatti i seguenti punti, fatta eccezione nel caso in cui il media sia un’alternativa ad un contenuto testuale e venga chiaramente etichettato come tale: (Livello A)

  • Solo audio preregistrato: è fornita un’alternativa per il media temporizzato che presenti informazioni equivalenti per il contenuto audio preregistrato.
  • Solo video preregistrato: è fornita un’alternativa per il media temporizzato oppure una traccia audio che presenti informazioni equivalenti per il contenuto video preregistrato.

Linea guida 1.3 Adattabile:
Creare contenuti che possano essere rappresentati in modalità differenti (ad esempio, con layout più semplici), senza perdere informazioni o la struttura

1.3.1. Informazioni e relazioni: Le informazioni, la struttura e le relazioni interne alla presentazione possono essere determinate tramite programmi oppure sono disponibili in forma testuale. (Livello A)

1.3.2. Sequenze significative: Quando la sequenza in cui il contenuto è presentato incide sul suo significato, è possibile determinare in modo programmatico la corretta sequenza di lettura. (Livello A)

1.3.3. Caratteristiche sensoriali: Le istruzioni fornite per comprendere ed operare sui contenuti non devono basarsi unicamente su caratteristiche sensoriali dei componenti quali forma, dimensione, ubicazione visiva, orientamento o il suono. (Livello A)

Linea guida 1.4 Distinguibile:
Rendere più semplice agli utenti la visualizzazione e il sonoro dei contenuti, separando i contenuti in primo piano dallo sfondo.

1.4.1. Uso del colore: Il colore non deve essere utilizzato come unica modalità visiva per rappresentare informazioni, indicare azioni, richiedere risposte o come elemento di distinzione visiva. (Livello A)

1.4.2. Controllo del sonoro: Se un contenuto audio all’interno di una pagina Web è eseguito automaticamente per più di tre secondi è necessario fornire una funzionalità per metterlo in pausa o interromperlo, oppure è disponibile una modalità per il controllo dell’audio che sia indipendente dal controllo predefinito del sistema. (Livello A)

1.4.3. Contrasto (minimo): I testi e le immagini contenenti testo devono avere un rapporto di contrasto di almeno 4.5:1, fatta eccezione per i seguenti casi: (Livello AA)

  • Testi su larga scala: Testi su larga scala ed immagini contenenti testo su larga scala devono avere un rapporto di contrasto di almeno 3:1.
  • Testi incidentali: Testi o immagini contenenti testo che fanno parte di componenti inattive dell’interfaccia, che sono di pura decorazione, non visibili a nessuno, che fanno parte di immagini contenenti contenuti visuali maggiormente significati oppure che non hanno alcun requisito di contrasto.
  • Logotipi: Testo che è parte di un logo o marchio non ha alcun requisito minimo di contrasto.

1.4.4. Ridimensionamento del testo: I testi, ad eccezione dei sottotitoli e delle immagini contenenti testo, possono essere ridimensionati senza l’ausilio di tecnologie assistive senza perdita di contenuti e funzionalità sino al 200 percento. (Livello AA)

Principio 2: Utilizzabile - I componenti e la navigazione dell’interfaccia utente devono essere utilizzabili.

Linea guida 2.1 Accessibile da tastiera:
Rendere disponibili tutte le funzionalità tramite tastiera.

2.1.3 Tastiera (nessuna eccezione): Tutte le funzionalità del contenuto sono utilizzabili tramite un’interfaccia di tastiera senza richiedere tempi specifici per le singole battute. (Livello AAA)

Linea guida 2.2 Adeguata disponibilità di tempo:
Fornire agli utenti tempo sufficiente per leggere ed utilizzare i contenuti

2.2.3. Nessun tempo di esecuzione: Le temporizzazioni non sono indispensabili per la tipologia di contenuto, ad eccezione fatta dei contenuti multimediali sincronizzati ed eventi in tempo reale. (Livello AAA)

2.2.4. Interruzioni: Le interruzioni possono essere rinviate o sospese dall’utente ad eccezione di quelle che rappresentano un’ emergenza. (Livello AAA)

2.2.5. Reautenticazione: Quando una sessione autenticata scade, l’utente deve poter continuare l’attività senza perdita di dati dopo essersi riautenticato. (Livello AAA)

Linea guida 2.3 Convulsioni:
Non sviluppare contenuti che possano causare attacchi epilettici.

2.3.2 Tre lampeggiamenti: Le pagine Web non devono contenere nulla che lampeggi per più di tre volte al secondo. (Livello AAA)

Linea guida 2.4 Navigabile:
Fornire delle funzionalità di supporto all’utente per navigare, trovare contenuti e determinare la propria posizione.

2.4.1. Salto di blocchi: Fornire una modalità per saltare i blocchi di contenuto che si ripetono su più pagine. (Livello A)

2.4.2. Titolazione della pagina: Le pagine Web hanno titoli che ne descrivono l’argomento o la finalità. (Livello A)

2.4.7. Focus visibile: Qualsiasi interfaccia utente operabile tramite tastiera ha una funzionalità operativa in cui è visibile l’indicatore del focus. (Livello AA)

2.4.9. Scopo del collegamento (solo collegamento): Rendere disponibile una funzionalità per comprendere lo scopo dei collegamenti basandosi sul solo testo del collegamento, salvo il caso in cui lo scopo del collegamento potrebbe risultare ambiguo per la gran parte degli utenti. (Livello AAA)

2.4.10. Intestazioni di sezione: Le intestazioni di sezione sono utilizzate per organizzare il contenuto. (Livello AAA)

Principio 3: Comprensibile - Le informazioni e le operazioni dell’interfaccia utente devono essere comprensibili.

Linea guida 3.1 Leggibile:
Rendere il testo leggibile e comprensibile.

3.1.1. Lingua della pagina: L’impostazione predefinita del linguaggio umano di ogni pagina Web può essere determinata programmaticamente. (Livello A)

Linea guida 3.2 Prevedibile:
Creare pagine Web che appaiano e che siano prevedibili.

3.2.1. Al focus: Quando qualsiasi componente riceve il focus, lo stesso non avvia un cambiamento del contesto. (Livello A)

3.2.2. All’input: Cambiare l’impostazione di qualsiasi componente nell’interfaccia utente non deve provocare automaticamente un cambiamento di contesto, a meno che l’utente, sia stato informato del problema prima di utilizzare il componente. (Livello A)

Linea guida 3.3 Assistenza nell’inserimento:
Aiutare gli utenti ad evitare gli errori ed agevolarli nella loro correzione.

3.3.6. Prevenzione degli errori (tutti): Per tutte le pagine Web che richiedano l’invio di informazioni da parte dell’utente, è soddisfatta almeno una delle seguenti condizioni: (Livello AAA)
1.    Reversibilità: Le azioni di invio sono reversibili.
2.    Controllo: I dati inseriti dall’utente sono verificati per errori di inserimento, fornendo all’utente la possibilità di correggerli.
3.    Conferma: È disponibile una funzionalità per la revisione, conferma e correzione delle informazioni prima del loro invio definitivo.

Principio 4: Robusto
Il contenuto deve essere abbastanza robusto per essere interpretato in maniera affidabile mediante una vasta gamma di programmi utente, comprese le tecnologie assistive.

Linea guida 4.1 Compatibile
Garantire la massima compatibilità con i programmi utente attuali e futuri, comprese le tecnologie assistive.

4.1.1 Sintassi del codice: Nel contenuto strutturato utilizzando linguaggi di markup, gli elementi possiedono elementi di apertura e chiusura completi, gli elementi sono annidati in accordo alle proprie specifiche, gli elementi non contengono attributi duplicati e tutti gli ID sono unici, salvo il caso in cui le specifiche permettano eccezioni. (Livello A)

4.1.2. Nome, Ruolo, Valore: Per tutti i componenti dell’interfaccia utente (inclusi ma non limitati a: elementi di form, link e componenti generati da script), il nome e il ruolo devono essere determinati da codice; stati, proprietà e valori che possono impostati dall’utente possono essere determinati da programma , e le notifiche sui cambi di stato di questi elementi devono essere rese disponibili agli user agent, comprese le tecnologie assistive (Livello A)

L’accessibilità misurata

Questa prima lista pur essendo una sintesi, è comunque disarmante e ancora lontana dalla realtà. Conviene quindi fare tesoro dell’esperienza e prendere in esame le valutazioni eseguite su siti ed applicazioni web per la Regione Emilia-Romagna.
I risultati sono riferiti al primo report di analisi effettuato su ciascun prodotto: è sempre e solo stato il primo di una serie anche lunga di valutazioni su versioni corrette  ed aggiornate a seguito delle prime indicazioni.

I fornitori che si rapportano con l’amministrazione spesso, nonostante venga loro dato fin dall’inizio, un riferimento breve e semplice (le linee guida), per realizzare in modo conforme le pagine non si sono mai dimostrati in grado di soddisfare subito i requisiti.

La riflessione che occorre fare, deve tenere  conto sia del costo per l’amministrazione di questo processo iterativo analisi-correzione, sia del fatto che amministrazioni che non effettuano questo controllo di qualità, nella quasi totalità dei casi, ricevono materiale non a norma.

I dati

In tabella sono segnate le percentuali di NON conformità rilevate nelle varie analisi. Sono anche presenti le misurazioni effettuate durante il benchmark sui siti dei comuni dlla regione Emlia-Romagna 2007-2008 (Enti), su una serie di portali tematici di varie regioni del 2008 (Italia). Per un paragone più efficace ho riportato la corrispondenza con i requisiti delle WCAG 2.0 ed ho evidenziato i requisiti con la più alta percentuale di insuccesso.

*Il titolo sintetico fa riferimento al riepilogo dei requisiti della Regione il numero tra parentesi nella prima riga delle intestazioni è la quantità di siti/applicazioni misurate.

WCAG 2.0   Regione
siti (30)		 Regione
applicazioni (29)		 Enti
(180)		 Italia
(91)
4.1.1 HTML Codice valido 67% 90% 78% 50%
3.1.1 Definire lingua 27% 31%    
2.4.2 Titolo pagina 17% 66%    
2.4.1 Skiplink e accesskey 70% 66% 85% 30%
4.1.1 Frames Assenti 7% 17%   0%
4.1.1 CSS Codice valido 10% 48%    
1.4.1 Comprensibile in B/N 50% 48%    
1.4.3 Contrasto corretto 63% 69%    
1.4.4 Dimensioni % o em 43% 66%    
1.4.8 800×600 IE car. Grandi (perdita informazioni) 50% 41%    
1.1.1 Alternative alle immagini 57% 66%    
2.3.2 No flash/movimento 10% 0%   0%
1.4.5. 1.3.3 Immagini non al posto del testo 0% 10%    
1.1.1 Client: testi alternativi 0% 3%    
1.1.1 Server: link 0% 0%    
2.4.9 Link Significativi 7% 17%    
2.1.3 Link anche con tastiera 17% 24%    
  Distanze 0.5 em 0% 3%    
  Distanze 0.5 em 0% 0%    
  Intestazioni <TH> 3% 28%    
  Associazioni TH TD 17% 0%    
  Tabelle Linearizzabili 0% 21%    
2.4.10 Semantica 57% 62%    
1.3.1 Associare campi-etichette 33% 55%    
1.3.2 Etichette vicine ai campi 0% 0%    
  Distanze pulsanti 0.5 em 3% 0%    
  Distanza interna 0.5em 3% 0%    
1.2.1 1.3.3 Alternative audio video 0% 0%    
1.4.2 Contrasto audio 0% 0%    
  Funziona se script disabilitati 27% 69%    
3.2.1 3.2.2 Script Direttamente accessibili 0% 41%    
2.1.3 Script Indipendenti dal mouse 13% 41%    
2.2.3 Tempo 0% 0%    

Nella tabella precedente ho barrato alcune voci per diversi motivi:
•    perché il requisito è incluso in altre voci relativamente alle WCAG 2 (es. testi alternativi e mappe client)
•    era quasi sempre soddisfatto (immagini non usate al posto del testo)
•    era quasi sempre insoddisfatto e non costituiva una vera barriera (skip link)
•    perché non era misurabile (contrasto audio, distanze pari a 0.5 em,…)
•    perché non portava alcun beneficio o oggi non crea veri ostacoli anche in considerazione delle tecnologie a disposizione da tempo agli utenti (semantica, caratteri in %, intestazioni TH,…)

Finalmente la sintesi

Dalla sintesi delle WCAG 2.0 precedente, passando dalla verifica sperimentale, ho elaborato la proposta.
La selezione vuole portare alla possibilità di effettuare verifiche oggettive e soprattutto il rispetto del principio che è alla base della legge: abbattere le vere barriere e non migliorare semplicemente la qualità del web e di chi lo fa.
L’ approccio dei precedenti requisiti Italiani, quello di cercare la qualità con una legge, è risultato oneroso e spesso inefficace.

Ho quindi omesso anche delle intere linee guida: ad esempio quelle che riguardano la navigabilità, o la verifica di una corretta semantica (l’uso dei titoli, delle intestazioni ecc. ecc.). Anche se è provato il beneficio da parte degli utenti delle soluzioni indicate dalle linee guida, non si può affermare che il non rispettarle, crei una effettiva barriera all’accesso.

Con la sintesi che ho elaborato non intendo affermare che i requisiti eliminati fossero inutili, anzi l’invito dovrebbe essere a raggiungere almeno il livello A o AA, ma intendo affermare che non si possono imporre requisiti che sono utili ma non fondamentali all’accesso: troppe regole portano a non essere rispettate.

La sintesi porta quindi a 12 requisiti, 2 dei quali sono stati inseriti principalmente perchè verificabili automaticamente, a dispetto degli esiti negativi delle verifiche: si può così semplificare il lavoro da parte della amministrazioni nel valutare la fornitura, automatizzandolo e rendendolo in parte oggettivo.


I 12 requisiti

Principio 1: Percepibile

Le informazioni e i componenti dell’interfaccia utente devono essere presentabili agli utenti in modalità che possono percepire.

Linea guida 1.1 Alternative testuali:

Fornire alternative testuali per qualsiasi contenuto non di testo in modo che possa essere trasformato in altre modalità fruibili secondo le necessità degli utenti come stampa a grandi caratteri, Braille, sintesi vocale, simboli o linguaggio più semplice.
1.1.1. Contenuti non testuali. Tutti i contenuti non testuali devono avere un’alternativa testuale che fornisca informazioni analoghe, ad eccezione delle seguenti situazioni (Livello A):
•    Controlli, Input: il testo alternativo dei moduli di controllo o degli oggetti che ricevono input deve descrivere la funzionalità degli oggetti stessi. (Per altri requisiti vedere linea guida 4.1).
•    Media sincronizzati: nel caso di contenuti multimediali sincronizzati il testo alternativo deve fornire almeno una descrizione significativa dell’oggetto. (Per altri requisiti vedere linea guida 1.2).
•    Test - il testo alternativo di test o di esercitazioni deve fornire una descrizione dell’esercizio in oggetto e non la sua soluzione.
•    Esperienze sensoriali: il testo alternativo di un’esperienza sensoriale deve essere in grado di fornire la descrizione adeguata di ciò che essa mostra.
•    CAPTCHA: Se è necessario confermare che un contenuto è stato letto da una persona anziché da un computer, è necessario fornire un testo alternativo che indichi la funzionalità dell’oggetto e delle versioni alternative al CAPTCHA utilizzando modelli di rappresentazione per differenti sensi per soddisfare le diverse disabilità.
•    Decorazioni, formattazioni, contenuti invisibili: il contenuto non testuale di oggetti esclusivamente decorativi, utilizzati solo per la formattazione o non presentati agli utenti deve essere implementato in modo da poter essere ignorato tecnologie assistive.

Linea guida 1.2 Media temporizzati:

Fornire alternative per i media temporizzati.

1.2.1. Solo audio e solo video (preregistrati): Per i media preregistrati di solo audio e di solo video, sono soddisfatti i seguenti punti, fatta eccezione nel caso in cui il media sia un’alternativa ad un contenuto testuale e venga chiaramente etichettato come tale: (Livello A)
•    Solo audio preregistrato: è fornita un’alternativa per il media temporizzato che presenti informazioni equivalenti per il contenuto audio preregistrato.
•    Solo video preregistrato: è fornita un’alternativa per il media temporizzato oppure una traccia audio che presenti informazioni equivalenti per il contenuto video preregistrato.

Linea guida 1.3 Adattabile:

Creare contenuti che possano essere rappresentati in modalità differenti (ad esempio, con layout più semplici), senza perdere informazioni o la struttura
.3.1. Informazioni e relazioni: Le informazioni, la struttura e le relazioni interne alla presentazione possono essere determinate tramite programmi oppure sono disponibili in forma testuale. (Livello A)
1.3.3. Caratteristiche sensoriali: Le istruzioni fornite per comprendere ed operare sui contenuti non devono basarsi unicamente su caratteristiche sensoriali dei componenti quali forma, dimensione, ubicazione visiva, orientamento o il suono. (Livello A)

Linea guida 1.4 Distinguibile:

Rendere più semplice agli utenti la visualizzazione e il sonoro dei contenuti, separando i contenuti in primo piano dallo sfondo.

1.4.1. Uso del colore: Il colore non deve essere utilizzato come unica modalità visiva per rappresentare informazioni, indicare azioni, richiedere risposte o come elemento di distinzione visiva. (Livello A)
1.4.3. Contrasto (minimo): I testi e le immagini contenenti testo devono avere un rapporto di contrasto di almeno 4.5:1, fatta eccezione per i seguenti casi: (Livello AA)
•    Testi su larga scala: Testi su larga scala ed immagini contenenti testo su larga scala devono avere un rapporto di contrasto di almeno 3:1.
•    Testi incidentali: Testi o immagini contenenti testo che fanno parte di componenti inattive dell’interfaccia, che sono di pura decorazione, non visibili a nessuno, che fanno parte di immagini contenenti contenuti visuali maggiormente significati oppure che non hanno alcun requisito di contrasto.
•    Logotipi: Testo che è parte di un logo o marchio non ha alcun requisito minimo di contrasto.

Principio 2: Utilizzabile

I componenti e la navigazione dell’interfaccia utente devono essere utilizzabili.

Linea guida 2.1 Accessibile da tastiera:

Rendere disponibili tutte le funzionalità tramite tastiera.

2.1.3 Tastiera (nessuna eccezione): Tutte le funzionalità del contenuto sono utilizzabili tramite un’interfaccia di tastiera senza richiedere tempi specifici per le singole battute. (Livello AAA)

Linea guida 2.2 Adeguata disponibilità di tempo:

Fornire agli utenti tempo sufficiente per leggere ed utilizzare i contenuti

2.2.3. Nessun tempo di esecuzione: Le temporizzazioni non sono indispensabili per la tipologia di contenuto, ad eccezione fatta dei contenuti multimediali sincronizzati ed eventi in tempo reale. (Livello AAA)

Linea guida 2.3 Convulsioni:

Non sviluppare contenuti che possano causare attacchi epilettici.

2.3.2 Tre lampeggiamenti: Le pagine Web non devono contenere nulla che lampeggi per più di tre volte al secondo. (Livello AAA)

Principio 3: Comprensibile

Le informazioni e le operazioni dell’interfaccia utente devono essere comprensibili.

Linea guida 3.2 Prevedibile:

Creare pagine Web che appaiano e che siano prevedibili.

3.2.5. Modifiche su richiesta: I cambiamenti di contesto devono essere avviati solo dagli utenti, oppure è disponibile una funzionalità per disattivare tali modifiche. (Livello AAA)

Principio 4: Robusto

Il contenuto deve essere abbastanza robusto per essere interpretato in maniera affidabile mediante una vasta gamma di programmi utente, comprese le tecnologie assistive.

Linea guida 4.1 Compatibile

Garantire la massima compatibilità con i programmi utente attuali e futuri, comprese le tecnologie assistive.

4.1.1 Sintassi del codice: Nel contenuto strutturato utilizzando linguaggi di markup, gli elementi possiedono elementi di apertura e chiusura completi, gli elementi sono annidati in accordo alle proprie specifiche, gli elementi non contengono attributi duplicati e tutti gli ID sono unici, salvo il caso in cui le specifiche permettano eccezioni. (Livello A)

4.1.2. Nome, Ruolo, Valore: Per tutti i componenti dell’interfaccia utente (inclusi ma non limitati a: elementi di form, link e componenti generati da script), il nome e il ruolo devono essere determinati da codice; stati, proprietà e valori che possono impostati dall’utente possono essere determinati da programma , e le notifiche sui cambi di stato di questi elementi devono essere rese disponibili agli user agent, comprese le tecnologie assistive (Livello A)

Tags:

Valutazione accessibilità: ParmaePiacenzaonline.it

martedì, maggio 19th, 2009 | Verifica accessibilità | Nessun commento

Quel che si comprende da questo sito è che l’accessibilità va verificata, non basta provare a seguire alcune regole: sarebbe bastato provare a ingrandire un po’ il testo, per accorgersi dei problemi.
Parma e Piacenza Online ha un aspetto gradevole, è abbastanza leggibile e la grafica si adatta anche a monitor con risoluzioni ridotte (800×600), cosa ottima per chi ha problemi di vista. Purtroppo, proprio chi vede poco, su questo sito deve necessariamente ingrandire il testo perché piuttosto piccolo: o non si ingrandisce o le parole si sovrappongono.
Nonostante qualche accorgimento per l’accessibilità sia stato utilizzato, e si veda un tentativo di strutturazione del codice, i risultati sono deludenti e la qualità davvero limitata per un sito di così nuova realizzazione.

valutazione_accessibilita_parmapiacenza

Valutazione accessibilità: Ravennasociale

martedì, maggio 19th, 2009 | Verifica accessibilità | Nessun commento

Questo sito ha due anime, una il sito informativo, l’altra il “social network”. La seconda anima ora non è che un forum, non molto animato, la prima invece è ricca di informazioni.
I colori sono sicuramente un problema, non sempre il testo è leggibile come conferma il fatto che non supera l’algoritmo per il calcolo del contrasto luminoso. Ma il sito è ben strutturato e con qualche lieve correzione qua e là potrebbe diventare completamente a norma, il che sarebbe davvero auspicabile visto l’argomento che tratta.
La soluzione a canali tematici, presente in home page, è utile alla navigazione, ma se per ogni canale tematico si ripetono i 3 link “servizi”, “progetti” o “normative” si appesantisce sia l’estetica che la fruizione da parte di chi non vede: meno “rumore sulla pagina, è molto meglio per tutti.

valutazione-accessibilita-ravennasociale

Analisi accessibilità: AgriParma

giovedì, maggio 7th, 2009 | Verifica accessibilità | Nessun commento

Anche questo sito non risulta a norma. Presenta molti dei problemi di accessibilità che hanno tanti altri siti di pubbliche amministrazioni del parmense. Nelle misurazioni effettuate negli anni passati sui siti di provincia e comuni, lo scarso rispetto delle norme sull’accessibilità era già stato evidenziato, e questo sito non si differenzia dagli altri.
I problemi non sono insormontabili, non è un sito fatto male e presenta contenuti utili ed interessanti, è solo la sua realizzazione tecnica che ha delle carenze.

analisi-accessibilita-agriparma

« Previous Entries

Categorie

Archivio

Funzioni