usabilità e accessibilità - diunito · unificate nel testo di legge approvato nel dicembre 2003....

Usabilità e Accessibilità

• ISO 9241-11:1998: l’usabilità è “l’efficacia, l’efficienza e la soddisfazione con cui specifici utenti raggiungono specifici obiettivi in particolari ambienti”.

• ISO TS 16071: L’accessibilità è “l’usabilità di un prodotto, servizio, ambiente o strumento, per persone col più ampio raggio di capacità”. � Fruibile da chiunque

2019/2020

Usabilità e Accessibilità

• Un sito web è usabile quando soddisfa i bisogni informativi dell'utente che lo sta visitando, fornendogli facilità di accesso e navigabilità e consentendo un adeguato livello di comprensione dei contenuti…

2019/2020

Accessibilità: una definizione•Un sito web è accessibile quando la sua interfaccia è fruibile indipendentemente da:

–Browser (browser grafici, testuali, vocali…); –Periferiche di input / output (tastiera, schermo, mouse, barre braille ecc. –Canale sensoriale utilizzato per l’interazione (vista, udito, tatto); –Abilità psico-motorie dell’utente; –Abilità percettive dell’utente; –Connettività (LAN, Modem, GPRS ecc.); –Hardware e software (Palmari, Desktop, WebTV ecc.);

2019/2020

Usabilità e Accessibilità• L’usabilità non può essere progettata a prescindere dagli utenti

che utilizzano effettivamente il sito, dagli obiettivi che questi cercano di raggiungere, dall’ambiente in cui ciò avviene.

• L’accessibilità deve essere progettata tenendo bene in mente le esigenze dell’ampio numero di persone disabili, o che hanno tecnologie obsolete, o che si collegano al web con dispositivi diversi dal computer.

2019/2020

Cosa hanno in comune l’usabilità e l’accessibilità?

L’utente

• Un progetto di usabilità pone gli utenti al centro. • Un progetto di accessibilità pone al centro gli utenti disabili o con

problemi di accesso alla rete. • Progettare un sito usabile e accessibile è un processo user-centered.

2019/2020

Utenti diversamente abili• Disabilità della vista --> browser vocali

• Disabilità dell’udito --> sottotitolazione dei

video

• Disabilità motorie � emulatori di mouse,

testiera, ingrandimento di oggetti

• Disabilità cognitive � evitare immagini in

movimento veloce

2019/2020

La Web Accessibility Initiative• Nel 1996 è stato creato il WAI allo scopo di stendere un insieme

di linee guida da applicare agli strumenti informatici legati al WWW (http://www.w3.org/WAI/ )

• Sono così nate: – WCAG:Web Content Accessibility Guidelines (le pagine web); – UAAG: User Agent Accessibility Guidelines (gli strumenti di

navigazione); – ATAG: Authoring Tool Accessibility Guidelines (editor, CMS

ecc.); – XAG: XML Accessibility Guidelines (linee guida che i

linguaggi basati su XML devono seguire, es. SMIL, RSS ecc);

2019/2020

Il quadro normativo di riferimento • USA:

– Section 508 (1998) •emendamento del Rehabilitation Act che richiede la conformità ad un insieme di punti di controllo per la realizzazione di servizi digitali offerti / per la pubblica amministrazione; •http://www.access-board.gov/sec508/508standards.htm

• Unione Europea: – Piano d’azione eEurope 2002

•Reclama la necessità di adottare l’accessibilità come requisito fondamentale dei servizi informatici; •Indica le linee guida dettate dal W3C come punto di riferimento;

– Risoluzione della Commissione Europea del 3 gennaio 2003;

2019/2020

Il quadro normativo di riferimento• Italia:

– Circolare AIPA (6 settembre 2001): il consiglio dei ministri aveva aderito al W3C

•Indica le linee guida del W3C come modello cui uniformarsi progettazione universale; •Non viene indicato alcun obbligo ma solo una richiesta di conformità; •2003 anno europeo dei disabili

– Libro bianco di Lucio Stanca (Ministro per l’innovazione e le tecnologie):

•Analisi esaustiva della tematica; •Detta l’orientamento che le successive deliberazioni dovranno possedere;

2019/2020

Il quadro normativo di riferimento

– Dicembre 2003 Approvazione della Legge Stanca "Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici".

•Ad esso seguono numerose altre iniziative legislative, alla fine unificate nel testo di legge approvato nel dicembre 2003.

– Legge Stanca del 2004 (legge 4 del 2004)lavoro di sintesi •Sancito il diritto di ciascun individuo ad accedere a tutte le fonti informative e rende obbligatorio che tale accesso sia garantito dalla pubblica amministrazione e dagli enti di pubblica utilità (es. scuole e biblioteche)

• La legge si applica alle pubbliche amministrazioni di cui al comma 2 dell’articolo 1 del decreto legislativo 30 marzo 2001, n. 165, e successive modificazioni,

• Il medesimo obbligo è in carico, come specificato nell'art. 2 della legge, a

pubbliche amministrazioni enti pubblici economici aziende private concessionarie di servizi pubblici enti di assistenza e di riabilitazione pubblici aziende di trasporto e di telecomunicazione a prevalente partecipazione di capitale pubblico aziende municipalizzate regionali aziende appaltatrici di servizi informatici.

2019/2020

corep 2017/2018

La legge 4/2004Questi i punti salienti della legge 4/2004:

la legge pone incentivi ai privati e impone obblighi alla Pubblica Amministrazione (intesa in senso molto lato ) con la previsione di sanzioni; in particolare è previsto che i contratti stipulati dalla PA per la realizzazione di siti Web siano nulli qualora i requisiti di accessibilità non siano soddisfatti; si prevede, inoltre, che l’inosservanza della legge comporti responsabilità dirigenziale e responsabilità disciplinare da parte del funzionario pubblico;

http://www.usabile.it/leggestanca.htm http://www.pubbliaccesso.gov.it/normative/legge_20040109_n4.htm http://lau.csi.it/laboratorio/progetti/risorse/IMPA_PA_accessibile_01.pdf

corep 2017/2018

La legge 4/2004Questi i punti salienti della legge 4/2004:

in caso di acquisto di beni o di fornitura di servizi informatici, le Pubbliche Amministrazioni devono preferire le offerte che prevedano il soddisfacimento dei requisiti di accessibilità fissati da un decreto ministeriale previsto dalla legge e che verrà emanato centoventi giorni dopo la pubblicazione della legge stessa;

sono subordinati alla rispondenza a tali requisiti di accessibilità anche i contributi pubblici a soggetti privati per l'acquisto di beni e servizi informatici destinati ad un utilizzo da parte di soggetti disabili o pubblico;

corep 2017/2018

La legge 4/2004

Questi i punti salienti della legge 4/2004:

i datori di lavoro pubblici e privati devono mettere a disposizione dei propri dipendenti disabili le opportune tecnologie assistive, adeguate alla specifica disabilità e alle mansioni svolte.

corep 2017/2018

La legge 4/2004


Dal punto di vista formativo, la legge prevede che le attività di formazione informatica dei dipendenti pubblici contemplino come materie di studio fondamentali le problematiche relative all'accessibilità e alle tecnologie assistive. La legge fissa, in sintesi, una serie di confini entro i quali dovrà attuarsi la "pratica dell'accessibilità" dei siti Web pubblici.

corep 2017/2018

La legge 4/2004

I soggetti destinatari di tale legge, come specificato nell'art. 3 della legge, sono:

Le pubbliche amministrazioni; Gli enti pubblici economici; Le aziende private concessionarie di servizi pubblici; Gli enti di assistenza e di riabilitazione pubblici; Le aziende di trasporto e di telecomunicazione a prevalente

partecipazione di capitale pubblico; Le aziende municipalizzate regionali; Le aziende appaltatrici di servizi informatici.

corep 2017/2018

La legge 4/2004


1.la legge pone incentivi ai privati (sembra non sia vero..) e impone obblighi alla Pubblica Amministrazione con la previsione di sanzioni;

– in particolare è previsto che i contratti stipulati dalla PA per la realizzazione di siti Web siano nulli qualora i requisiti di accessibilità non siano soddisfatti;

– si prevede, inoltre, che l’inosservanza della legge comporti responsabilità dirigenziale e responsabilità disciplinare da parte del funzionario pubblico;

http://www.pubbliaccesso.gov.it/normative/legge_20040109_n4.htm

corep 2017/2018

La legge 4/2004

La legge fissa, in sintesi, una serie di confini entro i quali dovrà attuarsi la “pratica dell’accessibilità” dei servizi digitali pubblici.

La legge contiene solamente un’indicazione di massima circa il contenuto di questi ulteriori provvedimenti, emanati in via definitiva nel corso dell’anno 2005

Spetta tuttavia ad altre due disposizioni indicare come le Pubbliche Amministrazioni dovranno comportarsi operativamente.

corep 2017/2018

La legge 4/2004

Le PA sono sempre obbligate ad adeguare i propri siti esistenti? No. La legge dice chiaramente che si applica a contratti nuovi o a aggiornamenti di contratti vecchi. Se quindi il contratto nuovo o il suo aggiornamento non prevede la modifica di pagine esistenti, quelle pagine non sembrano essere tenute ad un adeguamento. Inoltre quando il sito è frutto di lavoro interno (di un ufficio preposto), quando dunque manca un contratto, non è soggetto alla legge Stanca. Si vedano in merito le considerazioni sull'articolo 56 del codice dell'amministrazione digitale su questa pagina

Read more: http://www.usabile.it/leggestanca.htm#ixzz1meRsOREl

2019/2020

11 settembre 2018: aggiornamento legge Stanca

•11 settembre 2018: aggiornamento legge Stanca: •https://www.webaccessibile.org/normative/aggiornata-la-legge-4-2004-legge-stanca/

Il decreto è entrato in vigore il 26 settembre 2018 e recepisce la direttiva europea che prevede l’obbligo di accessibilità per i siti Web e le app mobile nonché ulteriori obblighi tra cui la pubblicazione della dichiarazione di accessibilità. Sparisce inoltre il bollino di accessibilità così come il DPR 75/2005 e il DM 8 luglio 2005 (con i relativi allegati), una volta emanate le linee guida a cura di AGID.

• Aggiornamento delle definizioni e dello stesso titolo della legge (ora “Disposizioni per favorire e semplificare l’accesso degli utenti e, in particolare, delle persone con disabilità agli strumenti informatici”), e • all’estensione degli obblighi di accessibilità agli organismi di diritto

pubblico • e rispetto alle app, sempre più diffuse e usate, si accompagnano

novità sostanziali non tanto e non solo sul fronte dei principi generali (nuovo articolo 3-bis) –

• siti e app accessibili se “percepibili, utilizzabili, comprensibili e solidi”; contenuti accessibili e fruibili se anche usabili, cioè facili, semplici, efficienti, efficaci e soddisfacenti da utilizzare -, quanto nelle tutele.

2019/2020

https://www.cittadiniditwitter.it/news/accessibilita-ecco-la-nuova-legge-stanca-pubblicato-il-decreto-che-consolida-i-principi-e-potenzia-le-tutele/

aggiornamento legge Stanca

• Non più bollini e pagine infarcite di link e riferimenti a volte incomprensibili per l’utente medio eventualmente anche con disabilità, ma una dichiarazione di accessibilità (nuovo articolo 3-quater) completa e dettagliata, che i soggetti erogatori devono pubblicare on line e aggiornare, la quale documenti la conformità del sito o della app ai principi e requisiti di accessibilità e indichi le parti di contenuto non accessibili per “onere sproporzionato” (articolo 3-ter).

• Il meccanismo di salvaguardia dell’ente introdotto dalla direttiva e recepito dal decreto fa salvi infatti i casi in cui l’applicazione delle prescrizioni comporti per l’ente “un onere organizzativo o finanziario eccessivo per i soggetti erogatori ovvero un onere che pregiudica la capacità degli stessi di adempiere allo scopo prefissato…”.

2019/2020


• Nel contenuto della dichiarazione di accessibilità deve essere compreso, e veniamo alle tutele, il meccanismo di feedback (nuovo articolo 3-quater, comma 2, lettera b) che deve essere attivato per consentire a chiunque di notificare al soggetto erogatore del servizio eventuali difformità del sito o dell’app rispetto ai principi/requisiti di accessibilità.

• Per questo deve essere linkato nella dichiarazione, quindi direttamente raggiungibile da questa, così come la procedura di attuazione (nuovo articolo 3-quinquies), che consente di rivolgersi al difensore civico digitale in caso di contestazioni sulla dichiarazione di accessibilità o sul monitoraggio periodico affidato all’Agenzia per l’Italia digitale (Agid).

2019/2020


• All’Agid spetta anche il compito centrale di emanare le Linee guida (LG) previste dal rinnovato articolo 11 della legge Stanca, quelle che dovranno indicare i requisiti tecnici di accessibilità degli strumenti informatici (quindi siti e app) e le metodologie tecniche per la verifica di accessibilità, rapportati ai principi generali.

• Requisiti e metodologie che sostituiranno quelli finora indicati dal decreto ministeriale 8 luglio 2005 e relativi allegati, “pacchetto” di riferimento destinato ad essere abrogato con la pubblicazione delle Linee guida

https://www.webaccessibile.org/normative/i-nuovi-requisiti-dopo-le-wcag-2-1-il-possibile-scenario/

2019/2020


25

Linee guida sull'accessibilità degli strumenti informatici Agid 09/01/2020

https://www.agid.gov.it/it/agenzia/stampa-e-comunicazione/notizie/2020/01/09/linee-guida-laccessibilita-novita-pa Le Linee Guida (PDF) sull’accessibilità degli strumenti informatici (pdf)Allegato 1 - Modello di Dichiarazione di Accessibilità.pdfAllegato 2 - Modello di autovalutazione (pdf) Allegato 3 - Prodotti per la classe 22 della UNI EU ISO 9999-2017.pdf

26

L’Italia ha recepito la Direttiva UE 2016/2102 con il Decreto legislativo n. 106 del 10 agosto 2018, che ha aggiornato e modificato la Legge 4/2004, introducendo nuovi adempimenti a carico delle amministrazioni e nuovi compiti per l’Agenzia per l’Italia Digitale.

Obiettivo della Direttiva UE 2016/2102 è quello di migliorare l’accessibilità dei siti web e delle applicazioni mobili delle amministrazioni pubbliche degli Stati Membri, armonizzando le varie disposizioni nazionali sul tema.

Linee guida sull'accessibilità degli strumenti informatici

https://www.agid.gov.it/index.php/it/design-servizi/accessibilita-siti-web/linee-guida-accessibilita-strumenti-informatici

27

Tra i temi trattati vi sono alcune novità, come l’estensione degli obblighi di accessibilità anche alle app mobili e il riferimento alla nuova Norma Tecnica, la UNI_EN_301549, che elenca i requisiti tecnici dei siti web e delle app mobili, in conformità alle WCAG 2.1.

AGID emana le Linee Guida sull’ accessibilità degli strumenti informatici, così come disposto dall’ art. 11 della L. 4/2004, che hanno lo scopo di definire:

• i requisiti tecnici per l’accessibilità degli strumenti informatici, ivi inclusi i siti web e le applicazioni mobili;

• le metodologie tecniche per la verifica dell’accessibilità degli strumenti informatici;

• il modello della dichiarazione di accessibilità; • la metodologia di monitoraggio e valutazione della conformità degli strumenti

informatici alle prescrizioni in materia di accessibilità; • le circostanze in presenza delle quali si determina un onere sproporzionato.



28

Le Linee Guida si applicano come segue: per i «nuovi» siti web (pubblicati dopo il 23 settembre 2018) a decorrere dal 23

settembre 2019; per i «vecchi» siti web (pubblicati prima del 23 settembre 2018) a decorrere dal

23 settembre 2020; per le applicazioni mobili a decorrere dal 23 giugno 2021.



29

Secondo le nuove disposizioni le PA dovranno: • effettuare le verifiche dell’accessibilità degli strumenti informatici (siti web

e app), al fine di valutarne lo stato di conformità; • compilare e pubblicare una «Dichiarazione di Accessibilità» (sotto la

responsabilità del Responsabile per la transizione digitale – RTD) in cui potranno essere previste eventuali deroghe all’accessibilità (ricorso all’ “Onere sproporzionato”);

• predisporre un «Meccanismo di Feedback» per consentire ai cittadini di inviare una segnalazione (prima istanza)

• L’Agenzia effettuerà il monitoraggio dei siti web e delle app su un campione rappresentativo, relazionando ogni 3 anni alla Commissione europea sui risultati del monitoraggio.



30

Con riferimento al Decreto Legge n. 179/2012, l’Agenzia per l’Italia Digitale ha emanato la Circolare n. 1/2016 (in sostituzione e aggiornamento della Circolare 61/2013) che definisce le modalità di pubblicazione degli Obiettivi di accessibilità che le pubbliche amministrazioni sono tenute annualmente a pubblicare sul proprio sito web.

La Circolare 1/2016: sostituisce il modello B della precedente Circolare 61/2013 con l’applicazione

web “Obiettivi di accessibilità” che facilita la redazione e la pubblicazione o degli Obiettivi e consente ad AgID di effettuare il monitoraggio dello stato di attuazione degli Obiettivi

prescrive l’obbligo di pubblicare sul sito web istituzionale gli obiettivi annuali di accessibilità nella sezione “Amministrazione trasparente – Altri contenuti – Accessibilità e Catalogo di dati, metadati e banche dati”. Gli obiettivi possono inoltre risultare anche nella pagina “Accessibilità” o in altre pagine esplicative dedicate

Obiettivi di accessibilità

https://www.agid.gov.it/index.php/it/design-servizi/accessibilita-siti-web/obiettivi-accessibilita

31

La procedura di segnalazione dei cittadini sui casi di inaccessibilità dei siti web o delle app è stata modificata, così come disposto dall’ art. 2, comma 3 del D.lgs 106/2018 e dalle Linee Guida sull’accessibilità degli strumenti informatici.

Le segnalazioni dovranno pervenire direttamente alle Amministrazioni responsabili dei siti o delle app mobili, utilizzando il "meccanismo di feedback", una procedura indicata nelle “Dichiarazioni di Accessibilità” pubblicate negli stessi siti o app.

Esclusivamente nel caso di mancata o insoddisfacente risposta da parte dell’Amministrazione responsabile, il soggetto segnalante può rivolgersi al Difensore civico per il digitale tramite la "procedura di attuazione" presente sempre nella Dichiarazione di Accessibilità.

Segnalazione siti inaccessibili

https://www.agid.gov.it/it/design-servizi/accessibilita-siti-web/segnalazione-siti-inaccessibili

32

Con l'entrata in vigore delle Linee guida sull'accessibilità degli strumenti informatici, come riportato dall’ art. 2, comma 2 del D.lgs 106/2018, l'elenco dei valutatori di accessibilità è stato abrogato.

Elenco valutatori

https://www.agid.gov.it/it/design-servizi/accessibilita-siti-web/elenco-valutatori-accessibilita

33

Dall'entrata in vigore delle Linee Guida di AGID sull’accessibilità degli strumenti informatici, il rilascio del logo è abrogato ai sensi dell art. 2, comma 2 del decreto legislativo n. 106 del 10 agosto 2018

Procedura rilascio logo di accessibilità

https://www.agid.gov.it/it/design-servizi/accessibilita-siti-web/procedura-rilascio-logo-accessibilita

34

Il 9 gennaio 2020 AgID ha comunicato la pubblicazione definitiva delle linee guida per l’accessibilità degli strumenti informatici.

Il documento aggiorna, in sintesi, tutta la parte regolamentare in materia di accessibilità dalla prima emanazione della Legge Stanca (legge n. 4/2004), recependo anche i dettami della Direttiva Europea n. 2016/2102 in materia di accessibilità dei sit web e le applicazioni mobili.

Cosa cambia?

Nuove linee guida Agid 2020

https://www.webaccessibile.org/normative/linee-guida-per-laccessibilita-ict-cosa-cambia-per-le-pa/

35

Una delle novità dell’aggiornamento della legge 4/2004, infatti, è l’accessibilità “by default” negli acquisti delle PA.

I requisiti di accessibilità non sono più “titolo preferenziale” ma sono “essenziali”, salvo casi particolari definiti dalla legge.

In questo modo la PA acquisisce prodotti predisposti per l’accessibilità, potendoli quindi far utilizzare in qualsiasi momento anche da persone con disabilità, senza doverli modificare e/o riprogettare.



36

I requisiti tecnici hanno origine dalla norma tecnica europea armonizzata EN 301549 v. 2.1.2, disponibile in lingua italiana come UNI EN 301549:2018.

La norma tecnica specifica i requisiti di accessibilità funzionali applicabili ai prodotti e ai servizi ICT nonché una descrizione delle procedure di prova e della metodologia di valutazione per ogni requisito di accessibilità in una forma adatta a essere utilizzata negli appalti pubblici in Europa (utili anche per il settore privato).

I contenuti della norma prevedono indicazioni in ambito ICT per prestazioni funzionali, requisiti generici, ICT con comunicazione vocale bidirezionale, con funzionalità video, hardware, web, documenti non web, software e servizi di supporto.



37

Per quanto riguarda il mondo web, il riferimento è la specifica WCAG 2.1, disponibile anche la traduzione ufficiale WCAG 2.1 in lingua italiana. https://www.w3.org/Translations/WCAG21-it/

Questo nuovo riferimento, rispetto alle WCAG 2.0 (riferimento per le PA italiane dal settembre 2013), consente di rendere maggiormente accessibili i siti web alle periferiche mobili.

Tra i nuovi requisiti, infatti, compare il riferimento 1.4.10 “Ricalcolo del flusso” delle WCAG 2.1 che – in sintesi – obbliga a sviluppare web (siti e applicazioni) secondo i principi del “responsive design”. https://www.w3.org/Translations/WCAG21-it/#reflow



38

Le metodologie tecniche per la verifica dell’accessibilità Per ogni capitolo della norma tecnica UNI EN 301549:2018, l’appendice C della medesima norma tecnica rende disponibile una serie di verifiche tecniche da svolgersi con modalità ispettiva (verifica diretta, verifica con strumenti automatizzati, ecc.).

In ambito web e applicazioni mobili, la norma tecnica contiene due prospetti (A.1 e A.2) che riportano l’elenco dei requisiti oggetto di verifica per poter dichiarare la conformità.

Anche in questo caso, come per le precedenti regole tecniche in materia di accessibilità, va ricordato che una verifica tecnica non può essere totalmente automatizzata ma richiede di effettuare analisi in modalità manuale.

Parimenti, nel mondo mobile – ad oggi – esistono scarse soluzioni per la valutazione dell’accessibilità e pertanto i test vanno effettuati in modo manuale.



39

WCAG: 2.0 o 2.1? La domanda che sorge spesso è la seguente: per i siti esistenti alla data di pubblicazione delle linee guida, sviluppati secondo le precedenti regole tecniche (WCAG 2.0 livello “AA”), è necessario adeguarsi subito alle WCAG 2.1 livello “AA”? E per le gare in atto?

Le Linee Guida forniscono la risposta: la conformità alle WCAG 2.0 deve essere rispettata come requisito minimo per i siti web le cui procedure di sviluppo e/o aggiornamento sono state avviate prima della data di entrata in vigore delle Linee Guida.

La conformità alle WCAG 2.1 deve essere rispettata come requisito minimo per i siti web le cui procedure negoziali di sviluppo e/o aggiornamento sono state avviate dopo la data di entrata in vigore delle Linee Guida.

A partire dal 23 settembre 2020, tale conformità dovrà essere rispettata anche per tutti gli altri siti web sviluppati in precedenza.



40

Novità: verifica soggettiva (usabilità) Una delle novità inserite dall’aggiornamento della legge Stanca è la verifica della fruibilità. Tale novità deriva dalla legge di recepimento della Direttiva Europea e ha obbligato pertanto l’inserimento di test di usabilità per l’ICT, compresi siti web e applicazioni mobili.

La procedura è descritta dettagliatamente nel paragrafo 3.3.2.1 delle Linee Guida, ed è richiesta per tutte le forniture sopra soglia comunitaria.

Per le forniture sotto soglia comunitaria, fermo restando la possibilità di utilizzare comunque la procedura di cui al paragrafo 3.2.2.1., è richiesto di utilizzare almeno una metodologia semplificata per la realizzazione di test di usabilità, ad esempio quella definita dal Protocollo eGLU o con altre modalità, ad esempio: con analisi basate su euristiche, svolte anche da parte di funzionari del medesimo soggetto erogatore opportunamente formati, con il coinvolgimento di persone con disabilità.



41

Dichiarazione di accessibilità La Direttiva Europea, e quindi la Legge Stanca, inserisce l’obbligo di pubblicare – per ogni sito web e applicazione mobile afferente all’amministrazione – la dichiarazione di accessibilità.

Tale attività sarà possibile tramite una procedura on line resa disponibile da AGID e sarà compito degli RTD (Responsabili per la Transizione al Digitale) effettuare la dichiarazione a seguito della valutazione (autovalutazione o con l’ausilio di terzi), pubblicando un link alla stessa nel footer di ogni pagina del sito afferente.



42

Se trovo problemi di accessibilità, che devo fare?

Dall’entrata in vigore delle Linee Guida, è necessario contattare preventivamente la PA responsabile del sito web o dell’applicazione mobile e richiedere un intervento tempestivo per la risoluzione del problema. La PA deve rendere disponibile un “meccanismo di feedback” (il cui riferimento è presente anche nella dichiarazione di accessibilità), ossia una modalità accessibile per poter segnalare le problematiche.

Se la PA non risolve il problema in modo adeguato entro 30 giorni dalla segnalazione, l’utente si può rivolgere al Difensore Civico per il Digitale, che attiverà specifica istruttoria e inviterà la PA a porre eventuali rimedi necessari a rimuovere la problematica di accessibilità.

Chi controlla i siti e le applicazioni mobili?

Per legge, AgID ha il compito di effettuare il monitoraggio con la procedura prevista dagli atti esecutivi della Direttiva Europea, descritta all’interno delle Linee Guida. Le verifiche si baseranno su un campione ben definito, aggiornato a scadenze specifiche. In caso di anomalie di conformità, AgID ai sensi di legge dovrà inoltrare nota al Difensore Civico per il Digitale che si attiverà in merito.



43

La normativa ora espone il responsabile (RTD) ad effettuare delle dichiarazioni di conformità per i siti web e le applicazioni mobili. Ciò significa che l’amministrazione deve garantire che:

• gli acquisti siano esclusivamente (tranne rari casi) limitati a prodotti dichiarati accessibili;

• i contenuti prodotti e pubblicati nei siti istituzionali e diffusi tramite applicazioni mobili siano accessibili;

• vi sia costante attività di monitoraggio dell’accessibilità dei siti web e applicazioni mobili.

A tali responsabilità, va ricordato che è necessario acquisire e/o produrre anche ICT accessibile: hardware, software, documenti non web.

La Legge Stanca (art. 8 comma 3) prevede che i dipendenti delle amministrazioni siano formati sui temi afferenti all’accessibilità: occasione per riqualificazione del personale in materia di gestione di contenuti, compreso lo sviluppo di documenti – troppo spesso pubblicati on line e/o archiviati come scansioni di documenti cartacei (e pertanto non accessibili, nonché non



2019/2020

WCAG 2.0

http://www.w3.org/TR/WCAG20/ http://www.w3.org/Translations/WCAG20-it/

2019/2020

WCAG 2.0

1. Le WCAG 2.0 sono in vigore dall’11 Dicembre 2008 e definiscono il nuovo standard da considerare in fatto di accessibilità.

2. Per soddisfare le diverse esigenze di un pubblico eterogeneo, viene offerta una strutturazione dei contenuti che comprende principi globali, linee guida generali, criteri di successo verificabili e una ricca raccolta di tecniche sufficienti e tecniche consigliate, oltre che documentazione sugli errori più comuni con esempi, collegamenti a risorse e codice.

2019/2020

WCAG 2.0La nuova stesura prevede una suddivisione delle linee guida secondo quattro principi fondamentali; un sito deve essere: 1. Percepibile —> le informazioni e i componenti dell'interfaccia utente

devono essere presentati in modo che possano essere fruiti attraverso differenti canali sensoriali.

2. Utilizzabile —> i componenti dell’interfaccia utente e i comandi in essa contenuti devono essere utilizzabili senza ingiustificati disagi o vincoli per l’utente.

3. Comprensibile —> gli utenti devono poter comprendere le modalità di funzionamento dell’interfaccia e le azioni in essa contenute necessarie per ottenere servizi e informazioni

4. Robusto —> il contenuto deve essere abbastanza robusto da poter essere interpretato in modo affidabile da una vasta gamma di programmi utilizzati dall’utente, comprese le tecnologie assistive.

2019/2020

WCAG 2.0

1. Nello specifico i quattro principi sono suddivisi in linee guida, in maniera simile rispetto alla versione 1.0 delle WCAG, ma ridefinendo i concetti in modo più chiaro e conciso.

2019/2020

WCAG 2.0: percepibile1.Percepibile: * 1.1 Fornire alternative testuali per qualsiasi contenuto non di testo in modo che lo stesso possa essere trasformato in altre forme fruibili secondo le necessità degli utenti come stampa a grandi caratteri, Braille, sintesi vocale, simboli o linguaggio più semplice. * 1.2 Fornire alternative per i tipi di media temporizzati.

2019/2020

WCAG 2.0: percepibile

* 1.3 Creare contenuti che possano essere rappresentati in modalità differenti (per esempio, con layout più semplici), senza perdite di informazioni o di struttura. * 1.4 Rendere semplice per gli utenti la visione e l'ascolto dei contenuti, separando i livelli di primo piano e di sfondo.

2019/2020

WCAG 2.0: utilizzabile

2. Utilizzabile * 2.1 Rendere disponibili tutte le funzionalità anche tramite tastiera. * 2.2 Fornire agli utenti tempo sufficiente per leggere ed utilizzare i contenuti. * 2.3 Non sviluppare contenuti che possano causare attacchi epilettici. * 2.4 Fornire all'utente funzionalità di supporto per navigare, trovare contenuti e determinare la propria posizione.

2019/2020

WCAG 2.0: comprensibile

3. Comprensibile * 3.1 Rendere il testo leggibile e comprensibile. * 3.2 Creare pagine Web che appaiano e funzionino in modo prevedibile. * 3.3 Aiutare gli utenti ad evitare gli errori ed agevolarli nella eventuale correzione.

2019/2020

WCAG 2.0: robusto

4. Robusto:

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

Advisory Techniques for Guideline 4.1 Avoiding deprecated features of W3C technologies (future link) Not displaying content that relies on technologies that are not accessibility-supported when the technology is turned off or not supported.

2019/2020

WCAG 2.0

1. Come per la WCAG 1.0, viene poi la parte più normativa che richiede di specificare per ogni pagina o complessivamente al sito Web, la conformità alle linee appena descritte.

2. Ogni linea rispettata determina direttamente il livello, tralasciando il meccanismo precedente che prevedeva delle priorità, nello specifico vi sono tre livelli

2019/2020

WCAG 2.0

1.Livello A: tutti i requisiti di livello A soddisfatti

1.Livello AA: tutti i requisiti di livello A e AA soddisfatti 1.Livello AAA: tutti i requisiti di livello A, AA e AAA soddisfatti

Le Web Accessibility Guidelines

Altro passo fondamentale in questo lungo processo di normazione è stato la pubblicazione definitiva, il 5 giugno 2018, delle nuove raccomandazioni del W3C in tema di accessibilità web e mobile con la versione 2.1 delle Web Content Accessibility Guidelines (WCAG), referenziate dalla norma tecnica EN 301 549 denominata “Requisiti di Accessibilità per i prodotti e i servizi” (versione 2.1.2 dell’agosto 2018) ed estensione delle precedenti WCAG 2.0 che avevano sostituto a loro volta le WCAG 1.0 del 1999.

Il W3C definisce le WCAG 2 come: “specifiche tecniche per rendere i contenuti Web più accessibili alle persone con disabilità. L'accessibilità riguarda una grande varietà di disabilità, tra cui quelle visive, uditive, fisiche, vocali, cognitive, di linguaggio, di apprendimento e neurologiche. Sebbene queste linee guida prendano in considerazione molti problemi, non sono in grado di soddisfare i bisogni delle persone con tutti i tipi, gradi e combinazioni di disabilità. Queste linee guida rendono anche i contenuti Web più utilizzabili da persone anziane con cambiamenti delle abilità dovute all'invecchiamento e spesso migliorano in generale l'usabilità per tutti gli utenti”128.

55

56

I seguenti criteri di successo sono nuovi e disponibili nelle WCAG 2.1. Per garantire il mantenimento del riferimento ai vecchi criteri delle WCAG 2.0, i nuovi criteri di successo sono stati aggiunti successivamente a quelli preesistenti, indipendentemente quindi dal livello di conformità: 1.3.4 Orientamento (Livello “AA”) 1.3.5. Identificare lo scopo comune (Livello “AA”) 1.3.6 Identificare lo scopo (Livello “AAA”) 1.4.10 Riscorrimento (Livello “AA”) 1.4.11 Contrasto per contenuti non testuali (Livello “AA”) 1.4.12 Spaziatura del testo (Livello “AA”) 1.4.13 Contenuto su Hover o Focus (Livello “AA”) 2.2.6 Timeout (Livello “AAA”) 2.3.3. Animazione da interazioni (Livello “AAA”) 2.5.1 Movimenti del puntatore (Livello “A”) 2.5.2 Annullamento del puntatore (Livello “A”) 2.5.3. Tasti di scelta rapida (Livello “A”) 2.5.4 Etichetta nel nome (Livello “A”) 2.5.5 Dimensione obiettivo (Livello “AAA”) 2.5.6 Meccanismi di input simultanei (Livello “AAA”) 2.5.7 Attuazione del movimento (Livello “A”) 4.1.3 Messaggi di stato (Livello “AA”)

Nuove criteri di successo secondo le WCAG 2.1


57

Principio 1. Percepibile Le informazioni e i componenti dell’interfaccia utente devono essere presentati agli utenti in modi in cui essi possano percepirli.

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

Criterio di successo 1.3.4. Orientamento (Livello AA) La visualizzazione e il funzionamento di un contenuto non dipendono dall’orientamento dello schermo, ad esempio verticale o orizzontale, a meno che questo non sia essenziale.

NOTA. Esempi in cui un particolare orientamento del display può essere essenziale sono un assegno bancario, un’applicazione per pianoforte, delle diapositive per un proiettore o un televisore o un contenuto di realtà virtuale in cui un cambio di orientamento dello schermo non è applicabile.



58

Criterio di successo 1.3.5. Identificare lo scopo degli input (Livello AA)

Lo scopo di ciascun campo di input per le informazioni sull’utente può essere determinato programmaticamente quando:

• Il campo di input ha uno scopo noto, identificato nella sezione scopo dell’input per i componenti dell’interfaccia utente; e

• Il contenuto è implementato utilizzando tecnologie che supportino l’identificazione del significato atteso dei dati inseriti del modulo.

Lo scopo di questo criterio di successo è quello di aiutare le persone a riconoscere e comprendere lo scopo dei campi di immissione dei moduli.

Quando le persone compilano un modulo Web, di solito si prevede che forniscano informazioni su se stessi in vari campi. Esempi sono nome, cognome, indirizzo stradale, codice postale, nome utente o dettagli della carta di credito.

È necessario quindi specificare quale tipo di dati è previsto in un particolare campo rende più facile la compilazione di moduli, in particolare per le persone con disabilità cognitive.



59

Linea guida 1.4. Distinguibile

Rendere più semplice agli utenti la visione e l’ascolto dei contenuti, separando i contenuti in primo piano dallo sfondo.

Criterio di successo 1.4.10. Ricalcolo del flusso (Livello AA)

Il contenuto può essere ripresentato senza perdita di informazioni o funzionalità e senza richiedere lo scorrimento in due dimensioni per:

• Contenuto a scorrimento verticale con una larghezza equivalente a 320 CSS pixel; • Contenuto a scorrimento orizzontale ad un’altezza equivalente a 256 CSS pixel.

Tranne per le parti del contenuto che richiedono layout bidimensionale per l’utilizzo o per comprenderne il senso.



60

NOTA. 320 CSS pixel equivalgono a una finestra iniziale di larghezza 1280 CSS pixel al 400% di ingrandimento. Per i contenuti Web progettati per lo scorrimento orizzontale (ad esempio con testo verticale), i 256 CSS pixel equivalgono a una finestra iniziale di altezza 1024 pixel al 400% di ingrandimento.

NOTA. Esempi di contenuti che richiedono un layout bidimensionale sono immagini, mappe, diagrammi, video, giochi, presentazioni, tabelle di dati e interfacce in cui è necessario tenere in vista le barre degli strumenti mentre si gestisce il contenuto.

Finalità criterio di successo 1.4.10 Lo scopo di questo criterio di successo è di supportare le persone con problemi di vista che hanno bisogno di ingrandire il testo e leggerlo in una singola colonna.

Quando lo zoom del browser viene utilizzato per ridimensionare il contenuto al 400%, esso si riposiziona, ovvero viene presentato in una colonna in modo che lo scorrimento in più di una direzione non sia necessario.



61

Finalità criterio di successo 1.4.11

Lo scopo di questo criterio di successo è garantire che i componenti dell’interfaccia utente attiva (ovvero i controlli) e la grafica significativa siano distinguibili dalle persone con una visione moderatamente bassa.

I requisiti e le motivazioni sono simili a quelli per il testo di grandi dimensioni in 1.4.3 Contrasto (minimo).

I controlli a basso contrasto sono più difficili da percepire e possono essere completamente ignorati dalle persone con disabilità visive.

Allo stesso modo, se è necessario un contenuto grafico per comprendere il contenuto o la funzionalità della pagina Web, dovrebbe essere percepibile da persone con problemi di vista o altri problemi senza la necessità di tecnologie assistive che migliorano il contrasto



62

Criterio di successo 1.4.12. Spaziatura del testo (Livello AA) Nei contenuti implementati utilizzando linguaggi di markup che supportano le seguenti proprietà di stile per il testo, non si verifica alcuna perdita di contenuto o funzionalità impostando quanto segue senza modificare altre proprietà di stile:

• Altezza della linea (interlinea) di almeno 1,5 volte la dimensione del carattere; • Spaziatura dopo i paragrafi di almeno 2 volte la dimensione del carattere; • Spaziatura tra le lettere di almeno 0,12 volte la dimensione del carattere; • Spaziatura tra le parole di almeno 0,16 volte la dimensione del carattere.

Eccezione: le lingue e le scritture che non utilizzano una o più di queste proprietà nel testo scritto sono conformi quando si può applicare il criterio alle sole proprietà esistenti per quella combinazione di lingua e scrittura.

Finalità criterio di successo 1.4.12 Lo scopo di questo criterio di successo è di garantire che le persone possano ignorare la spaziatura del testo per migliorare la loro esperienza di lettura.

Esempio: Ove il testo non consenta le opzioni previste dal criterio di successo, con gli ingrandimenti vi possono essere casi di sovrapposizione tra testi rendendo illeggibile il contenuto.



63

Criterio di successo 1.4.13. Contenuto con Hover o Focus (Livello AA) Nel caso in cui il passaggio del puntatore del mouse (hover) o il focus della tastiera rendono visibili e nascosti dei contenuti, sono soddisfatte le seguenti condizioni:

• Congedabile. È disponibile un meccanismo per eliminare il contenuto aggiuntivo senza spostare il puntatore del mouse o il focus della tastiera, a meno che il contenuto aggiuntivo non comunichi un errore di immissione dei dati o non oscuri o sostituisca altri contenuti;

• Passabile. Se il passaggio del puntatore del mouse sul contenuto può attivare il contenuto aggiuntivo, il puntatore può essere spostato sul contenuto aggiuntivo senza che questo scompaia;

• Persistente. Il contenuto aggiuntivo rimane visibile fino a quando l’evento hover o focus non viene rimosso, l’utente lo elimina o le sue informazioni non sono più valide.

Lo scopo di questo criterio di successo è di garantire che il contenuto aggiuntivo non interferisca con la visualizzazione o il funzionamento del contenuto originale della pagina.

Il contenuto aggiuntivo che appare e scompare in coordinamento con il focus della tastiera o il puntatore del mouse spesso porta a problemi di accessibilità.



64

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.

Criterio di successo 2.1.4. Tasti di scelta rapida (Livello A) Se nel contenuto viene implementata una scorciatoia da tastiera utilizzando sole lettere (maiuscole e minuscole), segni di punteggiatura, numeri o simboli, allora è vera almeno una delle seguenti condizioni:

• Disattivazione. È disponibile un meccanismo per disattivare la scorciatoia; • Rimappatura. È disponibile un meccanismo per rimappare la scorciatoia in

modo che usi uno o più caratteri non stampabili della tastiera (ad esempio Ctrl, Alt, ecc.);

• Attivazione solo al focus. La scorciatoia da tastiera per un componente dell’interfaccia utente è attiva solo quando questo è attivo.



65

Linea guida 2.5. Modalità di input (novità WCAG 2.1) Rendere più facile agli utenti l’utilizzo di funzionalità attraverso input diversi dalla tastiera.

Criterio di successo 2.5.1. Movimenti del puntatore (Livello A) Tutte le funzionalità che per il loro utilizzo richiedono gesti multi punto o basati su percorsi possono essere gestite con un puntatore singolo senza gesti basati sul percorso, a meno che questi non siano essenziali.

NOTA. Questo requisito si applica al contenuto Web che interpreta le azioni del puntatore (ovvero non si applica alle azioni necessarie per il funzionamento del programma utente o della tecnologia assistiva).



66

Criterio di successo 2.5.2. Cancellazione delle azioni del puntatore (Livello A) Per le funzionalità che possono essere gestite utilizzando un singolo puntatore, si verifica almeno una delle seguenti condizioni:

• Nessun evento di selezione (down-event). L’evento di selezione (down-event) del puntatore non è usato per eseguire alcuna parte della funzione;

• Interruzione o annullamento. La funzione viene portata a termine sull’evento di rilascio (up-event) ed è disponibile un meccanismo per interrompere la funzione prima del completamento o per annullarla dopo il completamento;

• Inversione. L’evento di rilascio (up-event) inverte qualsiasi risultato dell’evento di selezione (down-event) precedente;

• Essenziale. È essenziale completare la funzione sull’evento di selezione (down-event).

NOTA. Le funzioni che emulano una tastiera o una tastiera numerica sono considerate essenziali.

NOTA. Questo requisito si applica al contenuto Web che interpreta le azioni del puntatore: non si applica alle azioni necessarie per il funzionamento del programma utente o della tecnologia assistiva.



67

Criterio di successo 2.5.3. Etichetta nel nome (Livello A)

Per i componenti dell’interfaccia utente con etichette che includono testo o immagini di testo, il nome contiene il testo che viene presentato visivamente.

NOTA. Una buona pratica è quella di avere il testo dell’etichetta all’inizio del nome.

Finalità criterio di successo 2.5.3 Lo scopo di questo criterio di successo è quello di contribuire a garantire che le persone con disabilità che fanno affidamento su etichette visive possano utilizzare tali etichette anche a livello di programmazione.

I controlli sono spesso etichettati con testo visibile. I controlli hanno anche un’etichetta programmatica, conosciuta come Accessibile Name and Description.

Gli utenti hanno un’esperienza altamente migliore se le etichette di testo visibili dei controlli corrispondono ai loro nomi accessibili. Inoltre, quando il nome accessibile è diverso dall’etichetta visibile, diventa essenzialmente un comando nascosto sconosciuto per gli utenti di input vocali che possono essere attivati accidentalmente senza che l’utente sappia cosa è successo.

Esempio. Il nome accessibile inizia con un’etichetta visibile: il nome accessibile di un pulsante «compra ora» inizia con lo stesso testo dell’etichetta visibile.



68

Criterio di successo 2.5.4. Azionamento da movimento (Livello A) Le funzionalità che possono essere azionate dal movimento del dispositivo o dell’utente possono anche essere attivate dai componenti dell’interfaccia utente e la risposta al movimento può essere disabilitata per impedire l’attivazione accidentale, tranne quando:

• Interfaccia supportata. Il movimento viene utilizzato per attivare la funzionalità attraverso un’interfaccia compatibile con l’accessibilità;

• Essenziale. Il movimento è essenziale per la funzione e non farlo invaliderebbe l’attività.

Lo scopo di questo criterio di successo è quello di garantire che le funzioni attivate dallo spostamento di un dispositivo (ad esempio, scuotimento o inclinazione) o gesticolando verso il dispositivo (in modo che i sensori come una fotocamera possano rilevare e interpretare il gesto), possano essere gestiti anche da componenti di interfaccia utente più convenzionali, a meno che il movimento sia essenziale per la funzione o il mancato utilizzo di movimenti o gesti invaliderebbe l’attività.

Esempio. Un utente può spostare o girare un dispositivo per cambiare la vista in una foto interattiva. È disponibile anche un controllo per eseguire queste stesse funzioni.



69

Principio 4. Robusto

Il contenuto deve essere abbastanza robusto per essere interpretato in maniera affidabile da una grande varietà 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.

Criterio di successo 4.1.3. Messaggi di stato (Livello AA) Nei contenuti implementati utilizzando i linguaggi di marcatura, i messaggi di stato possono essere determinati programmaticamente tramite ruolo o proprietà in modo tale che possano essere presentati all’utente mediante tecnologie assistive senza ricevere il focus.

Esempio. Dopo che un utente attiva un processo, sullo schermo appare un’icona che indica “occupato”. Lo screen reader annuncia “applicazione occupata”.



2019/2020

Link utilihttp://www.pubbliaccesso.gov.it/normative/legge_20040109_n4.htm

http://www.leggestanca.it/

http://kendo.eustema.it/ (validatore legge stanca) https://www.webaccessibile.org/articoli/contrast-analyser-versione-22/ (color contrast analyzer)

http://achecker.ca/checker/index.php (validatore legge stanca)

http://www.funzionepubblica.gov.it/media/668413/linee%20guida%20siti%20web%20pa_2010.pdf (linee guida per i siti delle PA) ocumenti qui presenti http://www.funzionepubblica.gov.it/lazione-del-ministro/linee-guida-siti-web-pa/presentazione.aspx (altri doc importanti per i siti delle PA)

Accessibilità dei siti web della PA Roberto Scano Apogeo

Libri

Principali problemi segnalati dagli utenti • Captcha • Il contenuto o parte del contenuto cambia repentinamente

senza opportuni avvisi • Gran parte dei siti web non soddisfa le basi dell’accessibilità:

accesso da tastiera, testi alternativi alle immagini, titoli, tabelle

• Le parti che compongono una pagina (header, contenuto, footer) non sono opportunamente segnalate alla tecnologia assistiva

• il 33% degli utenti adotta una barra braille insieme ad uno screen reader;

• il 41% afferma di usare una tastiera esterna insieme a un dispositivo mobile.

continua…

usabilità e accessibilità - diunito · unificate nel testo di legge approvato nel dicembre 2003....

Documents