Il talk sarà incentrato sul tema dell’accessibilità web. Sarà introdotta la tematica sia dal punto di vista generale (cos’è l’accessibilità, quali sono le leggi nazionali in materia), che delle metodologie utilizzate per la verifica dell’accessibilità (le WCAG, gli esperti ed i gruppi di valutazione), che degli strumenti a supporto dello sviluppo di siti accessibili (validatori e contrast checker), con una dimostrazione del loro funzionamento. Infine si discuterà dell’accessibilità in Drupal. di Antonio Giovanni Schiavone

2. DRUPAL DAY 2017
Accessibilità Web
Finalità, metodologie e strumenti
Antonio Giovanni Schiavone
Consiglio Nazionale delle Ricerche
schiavone@isti.cnr.it

3. Antonio Giovanni Schiavone
 Dottore in Informatica
 Dal 2013 Assegnista di Ricerca c/o C.N.R
 ISTI - Istituto di Scienza e Tecnologie dell’Informazione di Pisa
 IASI – Istituto di Analisi dei Sistemi ed Informatica di Roma
Mi occupo di:
 Web Accessibility
 Web Usability
 Data Visualization
 Semantic Web
Chi sono?
http://www.antoniogiovannischiavone.it
@AGSchiavone
schiavone@isti.cnr.it

4. Accessibilità Web:
Finalità

5. “La capacità dei sistemi informatici, nelle forme e nei limiti
consentiti dalle conoscenze tecnologiche, di erogare servizi e
fornire informazioni fruibili, senza discriminazioni, anche da parte di
coloro che a causa di disabilità necessitano
di tecnologie assistive o configurazioni
particolari”
Art. 2, comma a, Legge 4/2004 – nota anche come Legge Stanca
Cosa si intende per Accessibilità?

6. “The power of the Web is in its
universality. Access by
everyone regardless of
disability is an essential
aspect.”
Tim Berners-Lee
Direttore del W3C e inventore del World Wide Web
L’accessibilità Web è essa stessa il Web?

7. Quante sono le persone con disabilità?
Secondo vari studi, fra il 10% e il 20% della popolazione dei vari paesi
del mondo è affetto da qualche tipo di disabilità. In particolare:
 L' U.S. Census Bureau stima che negli USA i
disabili rappresentino circa il 18.7% della
popolazione, ed che il 12.6% soffra di gravi
forme di disabilità.
 L'Eurostat stima che in UE i disabili
rappresentino circa il 12.8% della
popolazione (fascia 16-64).

8. …ed in Italia?
Secondo i dati del Ministero dell’Interno relativi al recente
Referendum costituzionale 2016, in Italia vivono 46.720.943 cittadini
maggiorenni.
Considerando valida la stima Eurostat del 12.8%, le persone con
disabilità in Italia sarebbero:
46.720.943 x 12.8% = 5.980.280 cittadini
Per puro confronto, i cittadini residenti nel Lazio sono 5.893.935.
(Dati Istat Giugno 2016)

9. Eurostat vs Istat ?
Nel biennio 2012-2013 L’Istat ha condotto un’indagine sulle condizioni di salute e il ricorso ai servizi sanitari,
stimando in 3.200.000 il numero delle persone con disabilità (ossia circa il 6,4% della popolazione).
Le due stime potrebbero non essere in contrasto
considerando che:
 Le persone con disabilità lievi possono non far ricorso a
cure specifiche.
 Per alcune disabilità (ad es. il daltonismo) non esistono
cure specifiche.
 Lungaggini burocratiche e disservizi del S.S.N. posso
scoraggiare il ricorso ai servizi sanitari.

10. La legislazione italiana: La Legge Stanca
La legge 9 gennaio 2004, n. 4 (nota anche come Legge Stanca, dall’ex Ministro per l'Innovazione Lucio
Stanca) promuove il riconoscimento e la tutela del diritto di accesso ai servizi informatici e telematici della
pubblica amministrazione da parte dei disabili, tramite la definizione di requisiti tecnici a garanzia
dell’accessibilità delle informazioni ed i servizi erogati.
In particolare, essa si riferisce a:
 Siti web
 Applicazioni realizzate con tecnologie web
 Documenti resi disponibili sui siti web (ad es. i file PDF!)
A tale è associato un documento tecnico che illustra quali requisiti devono
essere rispettati per poter definire un sito, un’applicazione web oppure un
documento ‘accessibili’.

11. Legge Stanca: vale solo per le P.A.?
L’applicazione delle Legge Stanca non coinvolge solo la pubbliche amministrazioni, ma varie tipologie di
soggetti, sia pubblici che privati.
Difatti i soggetti destinatari della legge sono:
 Enti pubblici economici
 Aziende municipalizzate regionali
 Enti di assistenza e di riabilitazione pubblici
 Aziende di trasporto e di telecomunicazione a prevalente
partecipazione di capitale pubblico
Ma anche:
 Aziende appaltatrici di servizi informatici
 Aziende private concessionarie di servizi pubblici
 Soggetti che usufruiscono di contributi pubblici o
agevolazioni per l’erogazione dei propri servizi tramite sistemi
informativi o internet. (Ad es. i quotidiani!)

12. Accessibilità Web:
Metodologie e Strumenti

13. Web Content Accessibility Guidelines (WCAG)
Le Web Content Accessibility Guidelines (WCAG) sono le più importanti ed internazionalmente riconosciute
linee guida per l’accessibilità dei siti Web: esse sono pubblicate dal Web Accessibility Initiative (WAI), parte
integrante del World Wide Web Consortium (W3C).
Dal 2012, l’ultima versione di tali linee guida (WCAG 2.0) è
anche uno standard ISO (ISO/IEC 40500:2012).
Negli ultimi anni la maggior parte delle legislazioni
europee in tema di accessibilità, inclusa la Legge Stanca,
sono state aggiornate per imporre, come requisito tecnico,
il rispetto delle WCAG 2.0 al livello di conformità AA.

14. Struttura delle (WCAG)
Le WCAG 2.0 rappresentano un documento normativo, contenente insieme di raccomandazioni di tipo astratto
e non sono specifiche per una determinata tecnologia
Ad esse si associano due documenti tecnici:
 Understanding WCAG 2.0: Documento di
approfondimento che fornisce maggiori chiarimenti sui
dettagli e sugli intenti di una linea guida o di un criterio di
successo.
 Techniques for WCAG 2.0: fornisce specifiche indicazioni
per gli sviluppatori su come sviluppare contenuti Web
accessibili, con esempi concreti per alcune tecnologie
(HTML / XHTML, CSS, SMIL, scripting, Flash, Silverlight,
PDF, WAI-ARIA).

15. Techniques for WCAG 2.0 - Un esempio
Come esempio di Techniques, prendiamo in considerazione la H44, relativa all’obbligo di associare delle
etichette significative ai campi che costituiscono un form.
In essa sono illustrate l’ambito di applicabilità, la descrizione del suo obbiettivo, una serie di esempi concreti e,
soprattutto, una procedura per la verifica tecnica del suo soddisfacimento.

16. Le WAI-ARIA
Le WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) è una specifica che fornisce un
metodo per specificare ruoli, stati e proprietà per widget "custom" in modo da renderli riconoscibili e utilizzabili
per gli utenti delle tecnologie di supporto. Lo scopo è aggiungere una semantica o altri metadati al contenuto
HTML, per rendere i controlli lato utente e i contenuti dinamici più accessibili.
Per esempio con WAI-ARIA è possibile:
 Identificare una lista di collegamenti come un menu di navigazione
decidendo se visualizzarlo espanso o contratto.
 Definire che un dato elemento deve essere ignorato dalle tecnologie
assistive (ad es. le icone)
 Definire che un determinata regione è aggiornata da un
evento esterno in modo asincrono rispetto all’azione
dell’utente

17. La verifica dell’accessibilità dei siti Web
Una volta definite delle linee guida per l’accessibilità Web, si pone il problema di quale metodologie utilizzare
per verificare se un dato sito è conforme a tali norme tecniche (processo di validazione).
Le principali metodologie utilizzate sono 3:
 Verifica da parte di un esperto di accessibilità
 Gruppi di valutazione
 Analisi tramite strumenti automatici (Contrast Checker e
Validatori)

18. Gli esperti di Accessibilità
Gli esperti di accessibilità, sono figure professionali esperte nella verifica
dell’accessibilità dei sistemi informatici. Sebbene possano fare ricorso a
strumenti tecnologici di vario tipo, essi svolgono la validazione di
accessibilità principalmente tramite ispezione manuale.
Vantaggi
 E’ possibile scoprire tutti i problemi di accessibilità
Svantaggi
 Tempi di validazione tendenzialmente lunghi
 Costi tendenzialmente alti.

19. Gruppi di valutazione
Sono gruppi costituiti da persone con varie tipologie di disabilità, i quali hanno il compito di accedere al sito
web in esame, per testarne le funzionalità.
Tali prove possono avvenire sia in contesti usuali (casa, ambiente di lavoro), sia in contesti appositamente
costituiti (ambiente di laboratorio), sia in forma libera (senza compiti specifici), che per obiettivi (con compiti
prestabiliti).
Vantaggi
 Tempi di validazione tendenzialmente di media lunghezza
 Costi non trascurabili
Svantaggi
 Se il ‘mix’ di disabilità rappresentato dal gruppo di valutazione non è
completo, vi è il rischio trascurare la validazione rispetto ad alcune
tipologie di disabilità.

20. Contrast Checker e Validatori
 I Contrast Checker sono degli strumenti che consentono l’analisi di coppie di colori (uno in background e uno in
foreground), al fine di determinare se essi forniscono sufficiente contrasto per essere visualizzati da persone con deficit
nella visione dei colori.
 I Validatori di Accessibilità sono strumenti automatici in grado di verificare la conformità di un sito o di un’applicazione
web rispetto ai criteri stabiliti da linee guida per l’accessibilità: comunemente il loro funzionamento si basa sull’analisi
del codice sorgente dell’applicazione web in esame.
Vantaggi
 Costi contenuti o nulli.
 Tempi di validazione brevissimi.
Svantaggi
 Per alcuni tipi di requisiti, non è possibile automatizzarne la validazione.

21. Un esempio di Validatore: Mauve
Mauve (Multiguideline Accessibility and Usability Validation Enviroment) è un validatore di accessibilità
sviluppato all’interno dell’HIIS Laboratory del Consiglio Nazionale delle Ricerche di Pisa.
 E’ in grado di validare siti web rispetto alle WCAG 2.0
(livelli di conformità A, AA e AAA), alle linee guida
associate alla Legge Stanca e ad un set di linee guida
specifiche per persone ipovedenti e non vedenti.
 E’ possibile sottoporre la pagina da validare attraverso tre
diverse modalità di inserimento: fornendo la URL della
pagina da validare, facendone l’upload dal proprio disco
oppure incollando il codice html direttamente all’interno
di un apposito box di testo.
 Permette inoltre di selezionare attraverso quale tipo di
dispositivo (computer, smartphone, tablet, console o
SmartTv) simulare l’accesso in fase di recupero della
pagine web.

22. Accessibilità e Drupal

23. Drupal 7: l’Accessibilità entra in scena
Già a partire dalla versione 7, il team di sviluppo di Drupal ha iniziato a dare ampio spazio al tema
dell'accessibilità, riservando un'apposita area delle documentazione all'evidenziazione di tool e best practices
per l'accessibilità , nonché alla segnalazione di problemi di accessibilità all'interno dei moduli.

24. Drupal 8: Nuove funzioni per l’accessibilità(1)
A partire dalla versione 8, l'attenzione per l'accessibilità si è ulteriormente rafforzata, con ripercussioni dirette
nel core del CMS.
 Più Semantica: E’ stato incrementato sia l'uso degli elementi semantici
dell'HTML5 (header, nav, section, hgroup) che delle WAI-ARIA
(landmarks, live regions, roles & properties).
 Avvisi Vocali: E' stata inclusa nel Core il metodo Drupal.announce(),
che nel caso di accesso tramite tecnologie assistive, permette di
sostituire animazioni e aggiornamenti della UI con degli avvisi vocali.
 Gestione dell'ordine dei Tab: Introdotto il TabbingManager, un
meccanismo per guidare gli utenti non-vedenti ad accedere agli
elementi salienti della pagina in un ordine logico.
 Fieldsets: All'interno del Form API è stato introdotto l'uso del tag
fieldsets per raggruppare elementi di un form che sono logicamente
correlati, come richiesto dalle WCAG.

25. Drupal 8: Nuove funzioni per l’accessibilità(2)
A partire dalla versione 8, l'attenzione per l'accessibilità si è ulteriormente rafforzata, con ripercussioni dirette
nel core del CMS.
 Testi alternativi: Di default è obbligatorio l'inserimento di un testo
alternativo per ogni immagine inserita nel CMS.
 Bartik: La nuova versione del tema Bartik sottolinea i link al fine di
semplificarne l'identificazione.E' stato inoltre migliorato il contrasto
dei colori.
 Inline Form Errors: All'interno del Core sono stati inclusi gli Inline
Form Errors, in modo da semplificare l'identificazione di eventuali
errori durante l'inserimento di dati all'interno di un form.
 Accessibilità dei contenuti (in fase di integrazione): E' in corso
l'integrazione nel Core di un plugin per l'editor CKEditor, il quale
svolgerà alcune funzioni di verifica dell'accessibilità dei contenuti
creati.

26. L’impegno dà i suoi frutti
Nell’Aprile del 2016 un gruppo di ricercatori1 portoghesi ha svolto un’indagine per analizzare l’ impatto di
varie tecnologie di sviluppo web sull'accessibilità delle pagine web risultanti.
I ricercatori hanno analizzato circa 1700 pagine web di altrettanti domini, associando ad un ognuno di esse un
punteggio di accessibilità, e categorizzando tale insieme di siti in base alle tecnologie utilizzate per il loro
sviluppo (Html puro, vari CMS, vari framework Javascript, etc. ).
Da tale lavoro è risultato che, in media, i siti sviluppati con Drupal
avevano un punteggio di accessibilità migliore di quelli sviluppati
con altri CMS, e fra i migliori di tutte le tecnologie di sviluppo
prese in considerazione.
1) Development Technologies Impact in Web Accessibility (Carlos Duarte, Inês
Matos, João Vicente, Ana Salvado, Carlos M. Duarte, Luís Carriço)

27. Non si vive di solo Core
In Drupal, oltre al Core, vi sono altri elementi che concorrono alla generazione della pagine web (moduli,
temi, settaggi di configurazione, contenuti inseriti dagli editor). Quindi, ognuno di questi elementi, se non
correttamente sviluppato e/o settato, può compromettere l’accessibilità di un sito.
Al fine di garantire l’accessibilità di un sito, è opportuno:
 Verificare che i contenuti inseriti all’interno del sito siano
conformi alla linee guida per l’accessibilità.
 Nella scelta dei moduli e/o temi da includere in una
installazione Drupal, considerare anche la loro compatibilità
con le linee guida per l’accessibilità.
 Nello sviluppo di nuovi moduli e/o temi, tenere in
considerazione le indicazioni per gli sviluppatori associate alle
linee guida per l’accessibilità.
 Verificare l’accessibilità finale del sito generato, attraverso una
delle metodologie precedentemente illustrate.

28. Grazie