Requisiti 4, 5, 6

Requisito 4

Enunciato: Garantire che tutti gli elementi informativi e tutte le funzionalità siano disponibili anche in assenza del particolare colore utilizzato per presentarli nella pagina.

Riferimenti WCAG 1.0: 2.1

Riferimenti Section 508: 1194.22 (c)

Motivazione

I problemi legati alla percezione del colore sono più diffusi di quanto si pensi, ed hanno cause ed effetti diversi: si pensi che studi attuali fanno notare che addirittura una persona su dodici ne soffre. Per veicolare l’informazione il colore viene usato in maniera massiccia anche sul Web, e ciò può rendere difficoltosa o addirittura impossibile la navigazione o l’uso di un software per queste persone. Se inoltre pensiamo al costante innalzamento dell’età media dei navigatori abituali, è facile comprendere come per un designer sia importante conoscere queste problematiche, in modo da evitare non solo l’uso di combinazioni cromatiche che siano di fatto un ostacolo alla corretta fruizione dei contenuti nelle pagine Web da realizzare (requisito 6) ma soprattutto di non affidare esclusivamente ai colori il compito di dare informazioni.

Implementazione

Il requisito chiede di garantire la fornitura di informazioni indipendente da particolari colori. Lo sviluppatore dovrà quindi seguire le semplici raccomandazioni ispirate alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 per fornire allo sviluppatore le informazioni necessarie per uno sviluppo conforme.

Punto di controllo 2.1 (Priorità 1). Garantire che tutta l’informazione veicolata dal colore sia disponibile anche in assenza di colori

Gli utenti con problemi di corretta visione dei colori o chi utilizza periferiche di navigazione in bianco e nero (per esempio, vecchi modelli di palmari) non potrà accedere al sito se forniamo informazioni basandoci esclusivamente sui colori. Per esempio, se si utilizzano i fogli di stile per cambiare il colore dei collegamenti rimuovendone la sottolineatura (il formato predefinito dei collegamenti ipertestuali), gli utenti del sito con le suddette problematiche si troveranno in forte difficoltà a distinguere i collegamenti dal normale testo. Per soddisfare questo punto di controllo quindi è consigliabile rendere chiaramente identificabili le parti di testo che richiedono attenzione da parte dell’utente. Se, per esempio, desideriamo evidenziare i collegamenti ipertestuali, è consigliabile impostare nel foglio di stile il valore underline (sottolineatura) della proprietà text-decoration e, a ulteriore definizione, usare un carattere con peso maggiore.

a {
font-weight: bold;
text-decoration: underline;
color: #000;
background: transparent;
}

Spesso invece accade che per questioni “estetiche” viene richiesto allo sviluppatore di eliminare la sottolineatura dei collegamenti ipertestuali e di utilizzare un altro colore per identificare il collegamento attivo. Un utente con disabilità legate ai colori o disabilità cognitive troverà difficoltoso poter identificare i collegamenti e ciò renderà la pagina inaccessibile a tali categorie di utenti.

Questo punto di controllo richiede allo sviluppatore di controllare che tutte le informazioni disponibili nel sito siano indipendenti dai colori: se il sito presenta informazioni sul bilancio comunale e abbiamo evidenziato con una tonalità di rosso le voci negative, gli utenti precedentemente citati non potranno comprendere se una determinata voce sia positiva o negativa. In questo caso, l’indicare chiaramente con segno negativo i valori negativi rappresenterà la soluzione migliore per ogni categoria di utente. In un sito di un ente se si evidenzia con una tonalità di rosso un bando in scadenza, gli utenti con disabilità visive e utenti con tecnologie assistive potrebbero non ottenere tale importante informazione. In questo caso, è consigliato usare elementi di marcatura, come ad esempio <strong>.

Spesso, inoltre, si utilizzano formattazioni CSS per identificare, ad esempio, l’area attiva di una particolare sezione utilizzando uno specifico colore. Al fine di rispettare il requisito, è necessario fornire anche informazioni alternative che non siano vincolate al colore.

Un esempio che consente il rispetto del requisito 4 è il seguente:

<ul>
<li><a href="m1.asp">Menu 1</a></li>
<li><a href="m2.asp" class="attivo" title="(attivo)">Menu 2</a></li>
<li><a href="m3.asp">Menu 3</a></li>
</ul>

In questo modo lo sviluppatore può sbizzarrirsi assegnando diversi colori alle aree selezionate tramite la classe “attivo” ma, in mancanza del foglio di stile, dei colori o a causa della presenza di particolari colori l’utente potrà sempre ottenere informazioni sul collegamento attivo tramite l’attributo “title”.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la Barra dell’accessibilità per:

  • verificare la presenza di informazioni legate a specifici colori.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Immagini

Attiva/Disattiva i CSS. Attiva/disattiva i fogli di stile esterni (Punto di controllo 2.1).

Disattiva i CSS inline. Rimuove l’attributo style (se presente) da tutti gli elementi della pagina al fine di consentire l’identificazione di eventuali link (Punto di controllo 2.1).

Visualizza foglio di stile. Consente di verificare se all’interno del foglio di stile sono stati utilizzate in modo corretto le proprietà per gli stili dei collegamenti ipertestuali (Punto di controllo 2.1).

Colori

Scala di grigi. Visualizza il contenuto della pagina corrente in scala di grigi in modo da identificare visivamente eventuali problematiche di accessibilità legate a specifici colori (Punto di controllo 2.1).

L’esperto dovrà quindi controllare, ad esempio, che i collegamenti ipertestuali siano forniti della classica sottolineatura e che siano chiaramente identificabili. Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Requisito 5

Enunciato: Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di intermittenza possano provocare disturbi da epilessia fotosensibile o disturbi della concentrazione, ovvero possano causare il malfunzionamento delle tecnologie assistive utilizzate; qualora esigenze informative richiedano comunque il loro utilizzo, avvertire l’utente del possibile rischio prima di presentarli e predisporre metodi che consentano di evitare tali elementi.

Riferimenti WCAG 1.0: 7.1, 7.2, 7.3

Riferimenti Section 508: 1194.22 (j)

Motivazione

Il requisito intende riferirsi ai problemi legati all’uso di oggetti in movimento (testo ed immagini) che possono presentare le seguenti problematiche:

  • epilessie fotosensibili: in questo caso si richiede di evitare frequenze di lampeggio comprese tra 2 Hz e 55 Hz;
  • disturbi della concentrazione: oggetti in movimento, seppur realizzati nel rispetto del punto precedente, possono generare disturbi della concentrazione. In questo caso, in linea di massima, i problemi nascono sulla base della numerosità e della posizione nella pagina degli oggetti in movimento;
  • malfunzionamento delle tecnologie assistive: quando si utilizzano scritte scorrevoli o pagine che si autoaggiornano le tecnologie assistive hanno difficoltà a renderne il contenuto all’utente;
  • esigenze informative: ci si riferisce al caso di pagine che mostrino esempi di cattivo utilizzo di oggetti in movimento, per spiegare ad esempio il significato del presente requisito <http://ncam.wgbh.org/richmedia/examples/127.html>, oppure di pagine che mostrino esempi di arte visiva con oggetti in movimento.

Implementazione

Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti della pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 7.1 (Priorità 1). Fino a quando i programmi utente non permetteranno agli utenti di controllare lo sfarfallio, evitare di far sfarfallare lo schermo

Gli utenti con epilessia fotosensibile possono avere dei problemi con testi o immagini ad intermittenza con intervalli compresi tra 4 e 59 flash per secondo (Hertz). Uno schermo con testi e immagini in movimento o lampeggianti può causare delle crisi epilettiche agli utilizzatori che soffrono di epilessia fotosensibile perciò i professionisti che curano i contenuti dovrebbero evitare di far lampeggiare o scorrere velocemente contenuti sullo schermo. Un attacco epilettico può essere provocato da sfarfallii o lampeggiamenti nella fascia di valori che va da 4 a 59 lampeggiamenti al secondo (Hertz), con un picco di sensibilità a 20 lampeggiamenti al secondo, oppure da veloci passaggi dall’oscurità alla luce (come luci intermittenti, banner pubblicitari che segnalano novità oppure offerte speciali). Tali valori nella normativa americana Section 508 sono definiti invece tra 2 e 55 Hz e la nostra normativa ha deciso di recepire tale indicazione.

Effetti come l’effetto di transizione di pagina di Microsoft Internet Explorer, spesso utilizzato dagli sviluppatori, devono quindi essere controllati. L’effetto di transizione viene effettuato all’ingresso o all’uscita dalla pagina:

<meta http-equiv="Page-Enter"
content="revealTrans(duration=2, Transition=6)" />

Se la transizione è troppo lenta, i visitatori troveranno noiosa la navigazione, mentre se è troppo veloce può causare sfarfallii e lampeggiamenti pericolosi per gli utenti predisposti ad attacchi di epilessia. Questi effetti di transazione di pagina, non avendo degli scopi funzionali, è preferibile non utilizzarli. Lo stesso problema può essere riscontrabile nelle immagini animate, nei filmati e specialmente nei banner pubblicitari, quindi attenzione! Nella valutazione del requisito vedremo come un italiano ha prodotto il primo strumento al mondo in grado di valutare se delle immagini gif animate rientrano negli intervalli critici previsti dalla normativa.

Punto di controllo 7.2 (Priorità 2).Fino a quando i programmi utente non permetteranno agli utenti di controllare il lampeggiamento, evitare di far lampeggiare il contenuto

Alcune tecnologie assistive, come i lettori di schermo riscontrano difficoltà di interazione con i testi lampeggianti: in alcuni casi essi si bloccano sul campo di testo, in altri lo leggono a ripetizione o addirittura il sistema diventa instabile.

È importante inoltre sottolineare che l’utilizzo dell’elemento <blink> (lampeggiamento) non consente la validazione del codice secondo le raccomandazioni W3C HTML 4.x / XHTML 1.x in quanto è una definizione creata da Netscape per pURI effetti visivi. E’ comunque disponibile un valore della proprietà CSS text-decoration (blink) che consente di ottenere lo stesso effetto di lampeggiamento ma per il superamento del requisito ne sconsiglio l’utilizzo:

.lampeggiante
{
...
text-decoration: blink;
}

L’utilizzo di testi lampeggianti distrae i visitatori dal resto del contenuto della pagina: è pressoché inutile utilizzare l’elemento <blink> per attirare l’attenzione in quanto l’utente di fatto è già presente all’interno della vostra pagina Web e, verosimilmente, desidera fruirne i contenuti senza condizionamenti. In ogni caso, se non viene offerta la possibilità all’utente di disabilitare il lampeggiamento, l’uso di tale elemento (o del valore CSS blink) non consente il superamento del requisito. Se si ritiene assolutamente necessario indirizzare l’attenzione di un visitatore su un argomento importante, è possibile utilizzare elementi di enfasi (<em>) impostando per essi una classe nel foglio di stile:

<em>Contenuto da evidenziare</em>

È necessario precisare che l’uso di elementi di enfasi va moderato, in quanto nella modalità di visualizzazione predefinita è definito un carattere di tipo corsivo/italico che può causare problemi di lettura (affaticamento) ad alcune categorie di utenti e che, se si trattasse esclusivamente di utilizzo decorativo, è necessario utilizzare l’elemento <i> anzichè l’elemento <em>.

Punto di controllo 7.3 (Priorità 2). Fino a quando i programmi utente non permetteranno agli utenti di bloccare il contenuto in movimento, evitare il movimento nelle pagine

Come per i testi lampeggianti, anche i testi scorrevoli possono creare dei problemi alle tecnologie assistive, in particolare ai lettori di schermo. In presenza di una scritta scorrevole, un utente con disabilità visiva o cognitiva può riscontrare dei problemi di lettura di testi scorrevoli e quindi problemi di fruibilità dei contenuti. Un testo scorrevole inoltre distrae l’attenzione dai contenuti della pagina. Per la stessa motivazione è necessario utilizzare con parsimonia le GIF animate ed in generale qualsiasi tipo di animazione (filmati Macromedia Flash, effetti DHTML, ecc.) in quanto l’uso sconsiderato di animazioni, oltre a distrarre i visitatori del sito, in alcuni casi (vedi Punto di controllo 7.1) può causare problemi di epilessia fotosensibile. L’elemento <marquee> non è presente nelle raccomandazioni W3C (è stato introdotto da Microsoft in Internet Explorer come “risposta” all’elemento <blink> durante il periodo della “guerra dei browser“) e pertanto non deve essere utilizzato se si desidera rispettare la conformità del codice e questo punto di controllo: se si desidera attirare l’attenzione dell’utente su un particolare testo, è possibile farlo utilizzando i fogli di stile con gli elementi di enfasi. Spesso l’effetto di movimento dei testi viene generato da script o applet: in tal caso è necessario fornire un meccanismo all’interno di uno script o applet per permettere agli utenti di bloccare il movimento o gli aggiornamenti. Il fatto di usare i fogli di stile insieme con gli script per creare il movimento consente agli utenti di disabilitare oppure tenere sotto controllo gli effetti con maggiore facilità.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la Barra dell’accessibilità per:

  • verificare la presenza di scritte animate o lampeggianti;
  • verificare la presenza immagini animate (gif) misurandone la frequenza.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Immagini

GIF Flicker Test. Analizza le immagini .gif presenti nella pagina generando un report di conformità al requisito (Punto di controllo 7.1).

Struttura

Visualizza altri elementi. Attiva una micro applicazione in Javascript che identifica le istanze sulla pagina corrente dell’elemento inserito, come ad esempio <blink> (Punto di controllo 7.2) e <marquee> (Punto di controllo 7.3).

Informazioni documento

Informazioni metadata. Visualizza (in una nuova finestra) l’elenco di tutti gli elementi meta ed il relativo contenuto della pagina corrente. (Punto di controllo 7.1).

Identifica Applet / Script. Visualizza l’elenco delle applet e degli script presenti all’interno della pagina. (Punto di controllo 1.1) L’esperto dovrà quindi verificare la presenza di contenuti equivalenti per tali oggetti (Punti di controllo 7.1, 7.2 e 7.3).

Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Requisito 6

Enunciato: Garantire che siano sempre distinguibili il contenuto informativo (foreground) e lo sfondo (background), ricorrendo a un sufficiente contrasto (nel caso del testo) o a differenti livelli sonori (in caso di parlato con sottofondo musicale); evitare di presentare testi in forma di immagini; ove non sia possibile, ricorrere agli stessi criteri di distinguibilità indicati in precedenza.

Riferimenti WCAG 1.0: 2.2

Riferimenti Section 508: non presente

Motivazione

Alcune disabilità visive non consentono una corretta visualizzazione dei colori rendendo quindi di difficile comprensione alcuni accostamenti cromatici.

Ipotizzando di partire da un’immagine originale contenente dei fiori di colore rosa immersi in un insieme di foglie verdi si potranno avere le seguenti variazioni cromatiche:

  • un utente effetto da deutranopia avrà una visione del fiore di colore grigio-azzurrino anziché rosa mentre vedrà le foglie di colore verde oliva anziché il classico colore verde prato.
  • un utente affetto da protanopia avrà una visione del fiore similare all’utente con deutranopia mentre vedrà le foglie di un colore tendente al giallo senape anziché il classico colore verde prato.
  • un utente affetto da tritanopia avrà una visione del fiore di colore rosa chiaro mentre vedrà le foglie di un colore tendente all’azzurro.

Un strumento che consente di simulare le disabilità del colore è un tool prodotto da Fujitsu, ColorDoctor <http://design.fujitsu.com/en/universal/assistance/colordoctor/> (il prodotto è operativo esclusivamente in ambiente Microsoft Windows e richiede il .net Framework 1.1). All’esecuzione del programma, verrà presentato un browser in cui l’utente potrà digitare l’indirizzo della pagina web ed effettuare una visualizzazione di come un utente con disabilità visiva legata al colore interpreta i contenuti di una pagina web.

Figura 4.2 Color Doctor.

Pensiamo quindi al caso in cui si forniscano informazioni basandosi su abbinamenti di colore che alcune categorie di utenti possono confondere tra di loro (ad esempio i soggetti affetti da daltonismo) oppure soggetti che possono non vedere un determinato colore oppure ad utenti che lavorando in condizioni di non ottimale visibilità (ad esempio, con un notebook all’aperto) non riescono a vedere chiaramente alcune tonalità di colore. Il requisito, paradossalmente, è maggiormente dedicato agli utenti normovedenti in quanto utenti con disabilità che richiedono contrasti elevati solitamente utilizzano dei fogli di stile personalizzati per la navigazione dei siti internet.

Il requisito richiede inoltre di garantire lo stesso beneficio per i contenuti audio, ovvero in presenza di dialoghi ed effetti sonori, è necessario garantire la comprensione dei dialoghi.

Implementazione

Il requisito chiede di garantire la fornitura di informazioni che non impediscano ad alcune categorie di utenti di poter fruire dei contenuti della pagina web. Lo sviluppatore dovrà quindi seguire delle semplici raccomandazioni che si ispirano alle WCAG 1.0 al fine di garantire l’accesso ai contenuti alle diverse categorie di utenti. Sarà quindi richiesto di sviluppare testi ed immagini in modo che il colore principale sia distinguibile dallo sfondo secondo un particolare algoritmo pubblicato nel decreto all’interno della metodologia della verifica tecnica (Punto 2 Lettera d). L’algoritmo non è però utilizzabile per la verifica della comprensione del parlato rispetto al sonoro di un contenuto audio/video.

Riferimenti WCAG 1.0

Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al requisito.

Punto di controllo 2.2 (Priorità 2 per le immagini, Priorità 3 per i testi). Garantire che le combinazioni di colori tra il primo piano e lo sfondo forniscano un sufficiente contrasto se osservati da qualcuno con deficit percettivi del colore o quando visualizzati su un monitor in bianco e nero

Questo punto di controllo nelle WCAG 1.0 riguarda la Priorità 2 per le immagini e la Priorità 3 per il testo, e richiede che il contrasto tra il colore di sfondo e il colore in primo piano sia sufficiente a evitare problemi di lettura ai visitatori del sito. Il paradosso che viene sempre rappresentato nei seminari dedicati all’accessibilità è relativo alla priorità 3 per il testo: è possibile creare un sito rispettoso delle priorità 2 e con testi neri su fondo nero per ottenere la conformità al livello “AA”, ma rendendo chiaramente il sito inaccessibile ad un utente normovedente. Per la normativa italiana, invece tale requisito è obbligatorio.

Due colori permettono una buona visibilità se la differenza di luminosità e di colore tra i due è superiore a una determinata serie di valori. Il W3C ha determinato un algoritmo per calcolare il contrasto <http://www.w3.org/TR/AERT#color-contrast> che sarà utilizzato in questa verifica grazie agli strumenti di controllo inseriti nel CD-ROM allegato al libro. L’algoritmo, sviluppato da Chris Ridpath, Jutta Treviranus, Patrice L. (Tamar) Weiss, è ancora in fase di sviluppo ed è possibile che in futuro venga modificato. Ha comunque avuto una serie di valutazioni e test con utenti, come comprovato dalla pagina informativa predisposta da Ridpath <http://checker.atrc.utoronto.ca/docs/WebPageColors.html>.

La seguente formula è suggerita dal World Wide Web Consortium (W3C) e serve a calcolare la luminosità di un colore RGB.

((valore Rosso X 299) + (valore Verde X 587) + (valore Blue X 114)) / 1000

La differenza tra la luminosità dello sfondo e la luminosità del colore principale deve essere maggiore di 125.

La seguente formula del W3C consente invece di calcolare la differenza tra due colori.

(massimo (valore Rosso 1, valore Rosso 2) - minimo (valore Rosso 1, valore Rosso 2)) + (massimo (valore Verde 1, valore Verde 2) - minimo (valore Verde 1, valore Verde 2)) + (massimo (valore Blue 1, valore Blue 2) - minimo (valore Blue 1, valore Blue 2))

La differenza tra colore di sfondo e colore principale deve essere uguale o superiore a 500. Hewlett Packard (HP) fornisce uno strumento di verifica del contrasto fra colori che utilizza gli algoritmi del W3C, ma fissa il livello minimo di differenza di colore a 400, il che aumenta il numero di combinazioni sfondo/primo piano considerate accettabili. È comunque facile immaginare che colori chiari su fondo chiaro o colori scURI su fondo scuro non rappresentano la scelta opportuna, così come va ricordato quanto descritto nell’enunciato precedente, ossia che esistono molte disabilità visive legate ai colori.

A ulteriore supporto inoltre è disponibile una trasposizione della tabella dei 216 colori “sicURI” per alcune delle più diffuse disabilità relative ai colori <http://more.btexact.com/people/rigdence/colours/colours1.htm>. Poiché esistono moltissime varianti delle disabilità legate al colore, risulta impossibile rendere un sito adatto a tutti gli utenti. Per questo motivo si consiglia di definire fogli di stile (CSS) alternativi che permettano all’utente di personalizzare a proprio piacimento o esigenza i colori del sito stesso. Per ottenere questo risultato, si utilizzerà l’elemento <link> nella sezione <head> della pagina per richiamare i fogli di stile. Il foglio di stile principale avrà il valore stylesheet per l’attributo rel, mentre gli altri fogli di stile saranno definiti dal valore alternate stylesheet.

<link href="main.css" rel="stylesheet" type="text/css" title="Standard" />
<link href="1.css" rel="alternate stylesheet" type="text/css" title="Alto contrasto" />
<link href="2.css" rel="alternate stylesheet" type="text/css" title="Tema Sahara" />

Il visitatore del sito potrà selezionare il foglio di stile desiderato nell’elenco che gli verrà proposto, creato utilizzando l’attributo title.

Per i browser che non supportano questa opzione, è possibile utilizzare codice JavaScript. Joe Clark ha predisposto un elenco di esempi pratici <http://joeclark.org/f2f/recommendations.html?GL#SWITCHER-EXAMPLES> per l’utilizzo di tali tecniche con differenti modalità di utilizzo di diversi fogli di stile.

È chiaro che il requisito riguarda non solo i testi, la cui formattazione dovrebbe avvenire tramite fogli di stile, ma anche le immagini.

Verifica del requisito

Il valutatore, al fine di verificare l’applicazione del requisito dovrà utilizzare strumenti di supporto come la barra dell’accessibilità per:

  • verificare il contrasto dei colori nel foglio di stile;
  • verificare il contrasto dei colori per le immagini e gli oggetti presenti nella pagina.

Tramite la Barra dell’accessibilità è possibile utilizzare:

Colori

Colour Contrast Analyzer. Esegue un’applicazione che consente di verificare il rispetto degli algoritmi per qualsiasi contenuto presente nella pagina, immagini comprese. (Punto di controllo 2.2).

Strumenti

Juicy Studio Tools / CSS Accessibility Analyzer. Consente di analizzare gli elementi all’interno di un foglio di stile per verificare il rispetto degli algoritmi (Punto di controllo 2.2).

Simulazioni. Consente di accedere a una serie di funzionalità per emulare la visualizzazione della pagina secondo diverse disabilità visive (Punto di controllo 2.2).

Uno strumento utile per la valutazione del requisito è un’applicazione creata dagli stessi autori della barra dell’accessibilità, Colour Contrast Analyzer <http://www.nils.org.au/ais/web/resources/contrast_analyser/index.html>, disponibile all’interno alla barra dell’accessibilità. L’applicazione consente di effettuare l’analisi della differenza tra contenuto principale e sfondo e della luminosità per testi ed immagini. Per avviare l’analisi basta selezionare l’icona del contagocce, posizionarla sopra il contenuto di cui si desidera acquisire il codice di colore il valore relativo sarà importato nell’applicazione. Con la stessa modalità è necessario selezionare il colore dello sfondo ed automaticamente l’applicazione visualizzerà se i colori sono utilizzabili o meno.

Nel caso siano presenti dei contenuti audio, l’esperto dovrà valutare il grado di comprensione verificando – ove possibile – se l’audio consente l’esclusione delle tracce relative al sonoro rispetto al parlato. Al termine della verifica dei suddetti punti l’esperto potrà quindi dichiarare la conformità al requisito.

Figura 4.3 Color Contrast Analizer.

Potrebbero interessarti anche i seguenti articoli

  • Requisiti 15, 16, 17Requisiti 15, 16, 17 Requisito 15 Enunciato: Garantire che le pagine siano utilizzabili quando script, applet, o altri oggetti di programmazione sono disabilitati oppure non supportati; […]
  • Il colore come informazioneIl colore come informazione I problemi legati alla percezione del colore sono più diffusi di quanto si pensi ed hanno cause ed effetti diversi: si pensi che addirittura una persona su dodici […]
  • Requisito 1 – Riferimento WCAG 1.0 – parte 1Requisito 1 – Riferimento WCAG 1.0 – parte 1 Di seguito sono riportati i riferimenti ai punti di controllo delle WCAG 1.0 al fine di fornire allo sviluppatore le informazioni per implementare contenuti conformi al […]
  • Requisito 1 – Enunciato, motivazione ed implementazioneRequisito 1 – Enunciato, motivazione ed implementazione Enunciato: Realizzare le pagine e gli oggetti al loro interno utilizzando tecnologie definite da grammatiche formali pubblicate nelle versioni più recenti […]
  • Guida ai requisiti tecnici – PremessaGuida ai requisiti tecnici – Premessa Nel decreto per sito INTERNET si intende l'insieme di componenti (pagine, link, funzioni) che risiedono su uno o più computer collegati alla rete Internet e che […]
Condividi:

Informazioni sull'autore

Roberto Castaldo
Roberto Castaldo
Sono nato e vivo a Napoli, ed opero professionalmente nel mondo dell'informatica da più di vent'anni. In realtà l'informatica, insieme alla musica e ad altre poche cose, è stato da sempre un mio chiodo fisso, e la buona sorte mi ha aiutato a trasformarlo in un mestiere. Sin dalle mie primissime esperienze lavorative - insegnavo dattilografia ed i primi rudimenti di informatica in una scuola privata - mi sono trovato a mio agio nel settore della formazione e della divulgazione, certamente aiutato dai miei studi classici. Nel 1987 ho iniziato la mia attività come insegnante d'informatica in un Istituto Professionale Statale - per circa due anni sono stato il più giovane insegnante di ruolo d'Italia. Ho avuto svariate esperienze anche nel settore privato come sviluppatore (TPascal - lo ricordate? - VB, ASP e, più di recente VB.NET ed ASP.NET), ma soprattutto come docente e come divulgatore. Ho effettuato attività di formazione presso le più grandi realtà imprenditoriali italiane (IBM, Omnitel, Telecom Italia, TIM, Unicredito, Ekip, BNL, SSGRR), ma anche all'estero in qualità di docente e/o progettista di percorsi formativi; gli argomenti spaziano dal mondo Office fino al multimedia ed alla programmazione avanzata ASP ed ASP.NET. Ho collaborato con l'Istituto Italiano per gli Studi Filosofici di Napoli, ho redatto articoli/tutorial per un'importante rivista informatica (Win98 Magazine), ed ho partecipato allo sviluppo di CD-Rom Multimediali (IBM, Selfin, BNL) curando personalmente la registrazione dei commenti audio ed il montaggio delle musiche (CoolEdit), l'eventuale connessione a database remoti, l'assemblaggio degli elementi testuali, grafici e multimediali (Director 8) fino alla creazione del master definitivo. Negli anni 1998-2000 ho collaborato con la Gazzetta dello Sport Online curando, in occasione dei più importanti avvenimenti sportivi (Mondiali ed Europei di calcio, Giro d'Italia, Campionato di Serie A) le pagine contenenti la traduzione in inglese e francese degli articoli in italiano. Il mio compito consisteva nell'inviare ai miei traduttori la cronaca in italiano, riceverne la traduzione, creare le pagine inglesi e francesi del sito www.gazzetta.it e pubblicarle sul server, il tutto entro 90 minuti dalla fine dell'evento. Nel frattempo, mi avvicinavo in maniera sempre più approfondita alle problematiche legate all'accessibilità di siti web, progettando percorsi di formazione ad hoc, ed aderendo entusiasticamente al progetto webaccessibile.org. Sono stato per diversi mesi membro del XML Protocol Working Group del W3C, ed attualmente partecipo ai lavoro del WAI Web Content Accessibility Guidelines (WCAG) Working Group e del E&O Education ad Outreach Working Group.

Commenti

È presente 1 commento:

  1. […] citando il requisito 5 della Legge Stanca (fonte: Webaccessibile.org): Enunciato: Evitare oggetti e scritte lampeggianti o in movimento le cui frequenze di […]

Rispondi

Link e informazioni