Siamo nell’era dell’Intelligenza Artificiale, dove si crede che possa sostituire l’essere umano in tutte le attività, in particolare quelle legate al mondo dell’informatica. Un click e via, il problema è identificato e con altro click è risolto! Se tutto funzionasse così, non saremmo qui ad Accessibility Days a parlare della scarsa accessibilità dei prodotti digitali. In questo seminario, da persona che si occupa da oltre 20 anni del tema, cercheremo di capire perché non bisogna affidarsi esclusivamente a strumenti automatizzati per verificare le soluzioni ICT (in particolare siti web e app mobili) nonché capire perché le soluzioni che promettono la conformità normativa con autoriparazione dell’accessibilità non sono idonei alla stessa e spesso hanno una valenza meramente omeopatica.

2. Perchè siamo qui?

3. Accessibilità: un obbligo e un dovere
Oggi la normativa nazionale obbliga a garantire
l’accessibilità di siti web e app mobili le P.A. e le
grandi aziende.
Tra poco più di un anno (dal 28 giugno 2025) sarà
estesa a tutti gli altri soggetti «aziendali».

4. Cosa cambia per il mercato?
Necessità
• prodotti (siti web, applicazioni web, app mobili)
conformi «a ieri»
• competenze (ri)qualificate

5. Cosa si rischia?
• Responsabilità dirigenziali (PA)
• Sanzioni fino al 5% del fatturato (grandi aziende)
• Contenzioso per discriminazione sul lavoro (dlgs.
216/2003)
• Contenzioso per discriminazione (legge 67/2006)
• Sanzioni variabili sino al ritiro prodotto dal
mercato (tutti)

6. E quindi?

9. Dove nasce il problema?

10. Dove nasce il problema
Sembra impossibile, ma i problemi di accessibilità sono
causati per ignoranza in materia da parte di tutti gli attori
coinvolti nella produzione e gestione di un sito web.
Le criticità di accessibilità possono nascere già dalla fase
di prototipazione, addirittura dai cosiddetti “mockup” dove si
possono nascondere criticità che successivamente devono essere
risolte.
Le criticità possono nascere anche da non corrette
implementazioni dei designer o dei developer che per cultura
professionale non hanno affrontato il tema dell’accessibilità.

11. E chi chiamerai?

12. I Web Accessibility Expert!
• La figura è normata dalla norma
tecnica UNI 11621-3, necessaria ora
per aiutare a riparare errori commessi
«prima».
• Attualmente molto richiesta.
• Se ci fosse una minima conoscenza in
materia, il Web Accessibility Expert
potrebbe non essere necessario in
queste fasi “semplici” ed essere
utilizzato in altre fasi.

13. Professionisti web!
• Professionista è chi opera ai sensi
della legge 4/2013
• IWA è la «casa» dei professionisti Web,
come associazione accreditata al
Ministero delle Imprese e del Made in
Italy,
• Anche se non associato, devono essere
figure con conoscenze, abilità e
competenze di accessibilità per il
proprio ambito di lavoro.
https://www.iwa.it

14. Gli utenti!
• Il contatto tra utenti ed aziende
/ PA è essenziale per
indentificare criticità ed avviare
un processo di risoluzione.
• Se non si fornisce un canale di
contatto, l’utente si «arrabbia» e
si rivolge alle autorità
competenti, oltre che al megafono
dei social.

15. Accessibilità:
verifica umana
o
automatizzata?

16. Cosa dicono le WCAG 2
Cosa sono le WCAG 2
Le WCAG 2.2 si basano sulle WCAG 2.0 [WCAG20] e WCAG
2.1 [WCAG21], che a loro volta si basano sulle WCAG
1.0 [WAI-WEBCONTENT] e sono progettate per applicarsi
in modo esteso a diverse tecnologie Web sia adesso
che in futuro, nonché per essere verificabili tramite
una combinazione di test automatici e valutazione
umana.

17. Le parole sono
importanti!

18. Validazione o valutazione?
Nella verifica di siti web non si parla MAI di
strumenti di validazione, ma di strumenti di supporto
alla valutazione o strumenti di verifica.
La validazione si può fare solo per il codice,
rispetto alle grammatiche formali dichiarate.

19. Il ruolo degli strumenti automatizzati a
supporto della riparazione
Un ruolo importante ce l’hanno gli strumenti di
valutazione automatizzati che supportano l’esperto di
accessibilità, ma anche il designer e lo sviluppatore
o il gestore di contenuti a comprendere dove vi siano
criticità (errori reali), dove potrebbero esserci
(errori potenziali) oppure dove lo strumento non può
arrivare (controlli da effettuarsi manualmente).

20. Cosa deve garantire un buon prodotto di
valutazione siti web
Un buon strumento di supporto alla valutazione deve
essere in grado di analizzare l’intero sito web e
fornire delle indicazioni puntuali sulle criticità
rilevate.

21. Il linguaggio degli strumenti di
verifica
Spesso questi strumenti sono per tecnici
«qualificati» ossia parlano il gergo «WCAG».
In futuro (già presente, per alcuni) è necessario che
vi siano strumenti che «spiegano» le problematiche di
accessibilità riscontrate in modo semplice, chiaro,
comprensibile anche da soggetti che producono
contenuti e non sono developer o designer.

22. La riparazione
automatizzata è
possibile?

23. La domanda da porci
Gli strumenti che dicono di rendere
conforme i siti web alla vigente
normativa, senza modificare il sito web
ma intervenendo in modalità automatizzata
aggiungendo “livelli personalizzati”, ci
possono garantire l’accessibilità o
comunque una conformità alle normative
vigenti?

24. No

25. No! Ho detto no!
Non è possibile identificare automaticamente tutte le
problematiche di accessibilità e pertanto è
necessaria una gestione umana supportata
eventualmente da strumenti informatici idonei
all’analisi.
Un buon strumento di supporto alla verifica di
accessibilità non può coprire oltre il 15-20% dei
criteri di successo delle WCAG 2.1.

26. Cosa non può fare uno strumento automatico
di riparazione? Alcuni esempi
• assegnare una etichetta ad un
campo modulo che non ce l’ha o ce
l’ha errata;
• consentire o meno di effettuare
l’ingrandimento in modo adeguato
dei contenuti;
• consentire la visualizzazione del
contenuto in una larghezza
minima;
• consentire l’identificazione di
tabelle di impaginazione;
• modificare collegamenti ambigui
(clicca qui, approfondisci,
ecc.);
• fornire adeguati testi alle
immagini contenenti testo, quando
necessario;
• garantire un corretto ordine
(focus) nella pagina;
• identificare in modo coerente gli
oggetti “non accessibili” in
tutto il sito web;
• garantire la navigabilità con la
sola tastiera;
• impedire che l’utente resti
bloccato all’interno di oggetti
navigando tramite tastiera;
• garantire l’identificazione di
errori e la loro prevenzione
nella compilazione di moduli;
• garantire una corretta struttura
delle intestazioni (livello di
titolazione e relativo
contenuto);
• correggere automaticamente i link
non funzionanti;
automatico derivante da azioni
dell’utente senza informarlo;
• garantire la correttezza
semantica;
• garantire adeguatezza delle
etichette e informazioni
strutturali aggiuntive per
tecnologie assistive;
• identificare la lingua corretta
per il contenuto;
• garantire la possibilità di
consultare i contenuti ruotando
lo schermo;
• garantire responsive design di
qualità;
• garantire l’accessibilità dei
documenti pubblicati (es: PDF
scansionati).

27. I problemi non risolti: gli
Accessibility overlay

28. In sintesi (spoiler)
Posizionare uno strumento che promette di rimuovere le
barriere digitali senza modificare il sito web ma aggiungendo
caratteristiche (i livelli) disponibili finché il servizio è
attivo, significa:
• non risolvere i problemi di accessibilità sia strutturali
che di contenuti;
• non attuare modifiche tecnico-organizzative per la
predisposizione di contenuti accessibili;
• creare problemi con ulteriori normative;
• non essere comunque conformi alla normativa vigente in
materia di accessibilità in quanto il sito deve essere

29. Servono alla conformità? No.
La Direttiva Europea per l’accessibilità Web e l’European
Accessibility Act:
• Richiedono di essere conformi almeno alla norma europea
armonizzata EN 301 549 v.3.2.1.
• L'Allegato A EN301549 v.3.2.1 funge da presunzione di
conformità.
• Non esistono strumenti che possano garantire test
automatizzati per tutti i criteri di valutazione, quindi è
impossibile fissare tutti i criteri di valutazione
“automagicamente”.
• Gli overlay non rendono il sito web accessibile o conforme

30. E chi lo dice?
Molti…
https://www.webaccessibile.org/approfondimenti/e-
opportuno-utilizzare-un-overlay-per-laccessibilita/
Tra cui:
• Associazione Internazionale dei professionisti di
accessibilità
• Federazione Europea delle persone con disabilità
• Commissione Europea come guida ai dipendenti

31. Ma lo dice (dal 2024) anche chi vende gli
accessibility overlay

32. Accessibility overlay: cosa fanno e cosa
non fanno
• non risolvono tutti i problemi di accessibilità – peggio ancora, ne
creano di nuovi.
• possono correggere “automagicamente” solo alcuni criteri di successo
(meno del 10%)
• possono interferire con le tecnologie assistive e la personalizzazione
dell'interfaccia utente.
• possono creare falsi positivi o falsi negativi.
• potrebbe avere un impatto sulle prestazioni del sito web.
• possono essere difficili da utilizzare per le persone che non sono
specialisti dell’accessibilità digitale, inclusi utenti, sviluppatori,
designer e proprietari di siti web che acquistano tecnologia
• può essere difficile capire cosa possono e non possono offrire, e le
limitazioni e i potenziali rischi di qualsiasi nuova tecnologia.

33. Accessibility overlay: possibili
problematiche
Può generare problemi per diverse esigenze degli utenti:
• Motorie: non garantisce la possibilità di utilizzare la tastiera per accedere
a tutti i contenuti (es. menu, pulsanti, ecc.).
• Cognitive: non può cambiare la lingua dei contenuti, cambiare la struttura
delle informazioni e delle correlazioni (ad es. uso mancato di titoli,
etichette, ecc.).
• Visive: non può garantire un testo alternativo adeguato con rischi per le
interazioni dell'utente (ad esempio la scelta di prodotti alimentari sbagliati
che può creare problemi).
• Uditive: non può garantire l'aggiunta di sottotitoli nei video pubblicati
internamente o in repository di terze parti (ad esempio video che non
supportano i sottotitoli in modo nativo).
Alcuni overlay rilevano automaticamente quando una tecnologia assistiva è in

34. Alcuni
esempi

35. (se vendete accessibility
overlay)

36. Difficile o impossibile da attivare

37. I profili di contrasto creano problemi

38. L’ingrandimento crea problemi

39. Ma anche scegliere navigazione da tastiera
(motoria)

40. Attenti ai biscotti!
In parecchi siti con Accessibility Overlay, l’oggetto scompare
sotto l’informativa, che non è il primo oggetto di navigazione,
diventando inutilizzabile.

41. Impostare contrasto elevato e diventare
«fuorilegge» per il GDPR? Certo, in
moltissimi siti con accessibility overlay

42. E poi torniamo indietro… nel passato!
Non devono esserci dei “livelli differenti”
azionabili dagli utenti altrimenti si ritorna al
concetto del sito parallelo. L’utente è l’unico
soggetto che deve poter personalizzare con i suoi
strumenti la visualizzazione, non deve cercare nella
pagina delle opzioni per personalizzare il sito,
navigando contenuti non accessibili sino al
raggiungimento della personalizzazione.

43. E quindi che dovremmo fare?

44. Accessibility by default, by design
• accessibilità by default (linee guida interne,
requisiti di appalto, ecc.)
• valutazioni (periodiche)
• pianificazione interventi (periodicamente)
• educazione e sensibilizzazione (per sempre)
• testare con il coinvolgimento di utenti con
disabilità (per sempre).

45. E dove mettiamo
l’IA?

46. Sperimentare, poi implementare!
L’intelligenza artificiale e altre tecnologie
emergenti hanno un grande potenziale per migliorare
l’accessibilità e le tecnologie assistive.
Tuttavia, ad oggi nessuna di queste tecnologie è in
grado di riparare istantaneamente un sito web
inaccessibile.
Non aggiungere mai qualcosa che rischi di danneggiare
gli utenti, testa sempre con gli utenti, non credere
in cose che sembrano troppo belle per essere vere.

47. Domande?

48. E-Mail: mail@robertoscano.info
Web site: https://robertoscano.info
SlideShare:
https://www.slideshare.net/rscano
Twitter: https://twitter.com/rscano
https://www.facebook.com/roberto.scano
Instagram:
https://www.instagram.com/rscano/
LinkedIn:
https://www.linkedin.com/in/robertosca
no/