I nostri 22 requisiti hanno in questi anni dimostrato dei limiti, che nella loro nuova definizione occorre superare:

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

L’aspirazione è quindi trovare una soluzione che li riduca, li renda più simili possibili alle wcag 2, li renda più specifici, utilizzando i casi di successo e gli esempi contenuti nelle wcag 2 stesse.

I presupposti sono gli stessi adottati nell’analisi delle WCAG 2, in particolare, vogliamo tentare di individuare delle caratteristiche necessarie e sufficienti a garantire l’accesso.

Nota:

In una nuova loro formulazione si suggerisce comunqe di usare termini più generici ed impositivi, es. piuttosto che “evitare”, meglio “vietato” altrimenti evitare la prescrizione; piuttosto che “garantire che siano sempre distinguibili testo e sfondo” meglio “il testo si deve distinguere dallo sfondo”

Analisi e comparazione dei requisiti

In grassetto sono indicati i criteri wcag 2 a cui si riferisce il requisito.

In alcuni casi, tra parentesi () sono indicati i requisiti che se anche non direttamente collegabili (come da documento di comparazione), estendono comunque il requisito.

Requisito 1

L’unica cosa che si può richiedere è la validità del codice ed il suo uso corretto, anche per questioni di verifica oggettiva

L’obbligo dello STRICT è un limite:

non garantisce l’accessibilità (pagine transitional possono di fatto essere accessibili); limita l’adozione di software internazionali proprietari e non.

Il consiglio di “evitare” l’apertura di nuove finestre è sbagliato, perchè una legge deve essere impositiva. Consigliare, significa ammettere.

Wcag 2: 1.3.1, 1.4.5, 1.4.9, 2.4.10, 4.1.1

Requisito 2

da eliminare

I frame non costituiscono inaccessibilità, e il requisito è stato ammesso per i sistemi di e-learning, non ha quindi senso adottare due diverse posizioni

Wcag 2: 2.4.2 (4.1.2)

Requisito 3

necessario
Si potrebbe anche sintetizzare nel primo periodo, senza specificare oltre, per evitare interpretazioni o casi limite non previsti

Wcag 2: 1.1.1, 1.2.1, 1.2.9, 4.1.2

Requisito 4

necessario

Wcag 2: 1.4.1

Requisito 5

Necessario.

Wcag 2: 2.3.1, 2.3.2

Requisito 6

Il termine “evitare” è inutile, non è prescrittivo

Wcag 2: 1.4.3, 1.4.6

Requisito 7

L’utilizzo delle mappe è poco diffuso, le uniche reperite, in 4 anni di verifiche sono state lato client.

Wcag 2: 1.1.1, 2.1.1

Requisito 8

Ad oggi in 4 anni di verifiche non è mai stata trovata una mappa lato server

Wcag 2: 2.1.1

Requisito 9

La prescrizione risulta comunque poco utile per la maggior parte degli ausili

Wcag 2: 1.3.1 (4.1.2)

Requisito 10

La prescrizione risulta comunque poco utile per la maggior parte degli ausili

Wcag 2: 1.3.1

Requisito 11

Wcag 2: 1.3.1, 1.4.1, 1.4.2, 1.4.4, 1.4.5, 1.4.8, 1.4.9, 2.1.2, 2.2.2, 2.3.1, 2.4.7,

Requisito 12

Ad oggi il requisito si potrebbe ritenere superato viste le nuove capacita di tutti i browser, che zoomano ingrandendo tutto il contenuto

Wcag 2: 1.4.4, 1.4.8

Requisito 13

E’ il 3° requisito sulle tabelle, sarebbe opportuno accorparli

Wcag 2: 1.3.1, 1.3.2

Requisito 14

Forse non fondamentale (viste le verifiche sperimentali) ma opportuno mantenerlo

Wcag 2: 1.1.1, 1.3.1

Requisito 15

Wcag 2: 2.3.1 (superabile se si accettano 4.1.1 e 4.1.2)

Requisito 16

necessario

Wcag 2: 2.1.1, 2.1.3

Requisito 17

Superfluo se si richiede che tutto ciò che è contenuto all’interno di una “pagina” rispetti i requisiti (accesso tramite tastiera, contrasti colori, ecc. ecc. ecc.)

Wcag 2: 2.1.2, 2.2.2, 2.3.1, 1.4.2

Requisito 18

È consigliabile usare solo la prescrizione minima

Wcag 2: 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7

Requisito 19

Utile ma non pregiudica l’accesso

Wcag 2: 1.3.1, 2.4.1, 2.4.4, 2.4.9

Requisito 20

necessario

Wcag 2: 2.2.1, 2.2.4, (2.2.3)

Requisito 21

Le misure minime non sono utili, non sono facilmente verificabili, sono del tutto originali rispetto ai requisiti internazionali, sarebbe opportuno toglierle.

Wcag 2: (Il requisito in parte è incluso 2.1.3 accesso da tastiera)

Requisito 22

Non è prescrittivo, e a 4 anni dalla uscita del DM la prima applicazione è ormai già stata fatta, in una nuova formulazione sarebbe opportuno dare solo prescrizioni

Wcag 2: (nessuna corrispondenza)

Segue la proposta di revisione degli attuali requisiti a partire dalla nuove WCAG 2.0

L’analisi della WCAG, vuole raggiungere l’obiettivo di identificare linee guida necessarie all’accessibilità ed alla selezione dei soli criteri di successo che:

• se non rispettati costituiscano vere barriere di accesso,
  il principio alla base della legge è “garantire l’accesso” non “rendere migliore l’accesso o le competenze di chi sviluppa”
• siano i più chiari ed oggettivamente verificabili,
  per evitare “aggiramenti” o differenti interpretazioni
• siano realizzabili senza oneri eccessivi
  poiché se onerosi, non verranno certamente applicati

I 4 principi della WCAG 2 sono dati per accettati in toto, ogni principio è necessario:

• Percepibile
• Utilizzabile
• Comprensibile
• Robusto

Le linee guida da scartare

Ognuno di questi principi si declina in Linee guida:

1.1 Alternative testuali

1.2 Media temporizzati

1.3 Adattabile

1.4 Distinguibile

2.1 Accessibile da tastiera

2.2 Adeguata disponibilità di tempo

2.3 Convulsioni

2.4 Navigabile

3.1 Leggibile

3.2 Prevedibile

3.3 Assistenza nell’inserimento

4.1 Compatibile

Dalle 12 linee guida  scartiamo:

2.4 Navigabile

3.1 Leggibile

3.3 Assistenza nell’inserimento

Queste qualità sono state scartate poiché indicano principi di usabilità, che non rappresentano vere barriere d’accesso, ma più in generale forniscono criteri di qualità del prodotto: tutti i criteri di successo, confermano quanto affermiamo.

Secondo i presupposti, se per ciascun criterio di successo, a cominciare da quelli di livello A, è possibile obiettare che siano necessari ad una agevole fruizione del contenuto, la NON agevole fruizione non può venire considerata inaccessibilità.

Per fornire dei requisiti, non ci si può fermare a livello di linee guida, ma si deve scendere al livello dei criteri di successo. Restano 9 Linee Guida, tra cui scegliere i criteri di successo necessari all’accessibilità. Si è cercato di scegliere innanzitutto i criteri individuati di livello A perchè già nelle WCAG sono individuati come i criteri fondamentali a garantire l’accesso. Ove essi erano più chiari da realizzare o verificare (anche se più restrittivi) si è scelto un livello AA o AAA.

I criteri di successo da scartare

1 Percepibile

1.1  Alternative testuali

1.1.1   Contenuti non testuali

il requisito è necessario, unico e quindi insostituibile a chi non vede, e la sua genericità copre tutte le esigenze

1.2 Media temporizzati

1.2.1   Solo audio e solo video (preregistrati)
Poichè è scontato che audio e video non saranno mai l’alternativa ad un testo, ma il contrario, la richiesta minima, in quanto meno onerosa e fattibile, è un testo alternativo di spiegazione del contenuto.
Per l’adattamento alla normativa italiana si potrebbe omettere la parola “preregistrato”

1.2.2   Sottotitoli (preregistrati)

1.2.3   Descrizione audio o media alternativo (preregistrato)

1.2.4   Sottotitoli (in tempo reale)

1.2.5   Descrizione audio (preregistrata)

1.2.6   Lingua dei segni (preregistrato)

1.2.7   Descrizione audio estesa (preregistrata)

1.2.8   Media alternativo (preregistrato)

1.2.9   Solo audio (in tempo reale)

tutti i requisiti diversi dal primo risultano onerosi, si può auspicare il loro rispetto, ma non lo si può imporre per legge. Si sarebbe potuto anche mantenere requisiti 1.2.8 e 1.2.9 invece dell’1.2.1 ma si è scelto, in questo caso, di preferire criteri di livello A perchè necessario e sufficiente

1.3 Adattabile

1.3.1   Informazioni e correlazioni
in questo requisito sono inclusi tutti quelli che riguardano la buona strutturazione ed uso del codice, è necessario per molti ausili, non si può eliminare

1.3.2   Sequenza significativa
un corretto uso del codice e la correlazione degli elementi rende questo requisito solo un inutile verifica in più.

1.3.3   Caratteristiche sensoriali
il requisito è piuttosto generico, e forse di interpretazione dubbia e soggettiva quando si verifica un contenuto, ma impone delle alternative a tutto ciò che viene utilizzato, è quindi una corretta indicazione dalla quale non si può prescindere

1.4 Distinguibile

1.4.1 Uso del colore
Poiché il colore è escluso dal requisito precedente, è necessario lasciare questo riferimento

1.4.2 Controllo del sonoro
Il sonoro all’interno di una pagina è controllabile dall’applet o plugin, o disabilitando applet e plugin. Chi utilizza screen reader deve sapere come disabilitare tali oggetti, e non è necessario lasciare l’onere su chi sviluppa. Ad oggi, sulle pagine delle PA da noi verificate, non è mai stato trovato alcun contenuto di questo genere.

1.4.3 Contrasto (minimo)
necessario a chi ha problemi di ipovisione, non eliminabile

1.4.4 Ridimensionamento del testo
eliminato poichè a carico dei browser, già in grado di soddisfarlo

1.4.5 Immagini di testo
in sostanza è incluso nell’1.1.1

1.4.6 Contrasto (avanzato)
in quanto di livello AAA è eliminato

1.4.7 Sottofondo sonoro basso o non presente
di livello AAA e di difficile misurazione

1.4.8 Presentazione visiva
di livello AAA e legato alla leggibilità dei contenuti, ossia a criteri di usabilità

1.4.9 Immagini di testo (senza eccezioni)
di livello AAA e troppo impositiva

2. Utilizzabile

2.1. Accessibile da tastiera

2.1.1. Tastiera
il criterio è di difficile interpretazione e incluso nel 2.1.3

2.1.2. Nessun impedimento all’uso della tastiera
il criterio è incluso nel 2.1.3

2.1.3. Tastiera (nessuna eccezione)
sono stati scartati i due precedenti perchè questo requisito risulta più chiaro e comprensibile.

2.2. Adeguata disponibilità di tempo

2.2.1. Regolazione tempi di esecuzione
troppo vago esteso e incluso nel 2.2.3

2.2.2. Pausa, stop, nascondi
tutti i plugin hanno queste funzionalità o si possono disabilitare

2.2.3. Nessun tempo di esecuzione
anche se in parte il requisito è già soddisfatto dal punto 2.1.3, il tempo è una componente fondamentale a cui pensare per chi usa degli ausili o ha difficoltà a comprendere. Secondo la nostra esperienza si potrebbe eliminare, ma come per il criterio 1.3.3. non è conveniente eliminare il criterio

2.2.4. Interruzioni
oneroso, ci si aspetta che si interrompa l’utente solo se strettamente necessrio (usabilità)

2.2.5. Reautenticazione
ci si aspettano prodotti di qualità, e incluso nel 2.2.3: tutti gli utenti devono poter completare un’attività senza limiti di tempo

2.3. Convulsioni

2.3.1. Tre lampeggiamenti o inferiore alla soglia
incluso nel 2.3.2

2.3.2. Tre lampeggiamenti
necessario e non eliminabile

4. Robusto

4.1. Compatibile

4.1.1. Analisi sintattica (parsing)
mantenuto perchè di facile verifica e garanzia di una qualità minima dei prodotti

4.1.2. Name, Role, Value
necessario per il futuro del Web e degli ausili