Dopo aver validato il codice della nostra pagina (o dell’intero nostro sito), siamo pronti per il passo successivo: l’utilizzo di strumenti semiautomatici per la valutazione dell’accessibilità. Stiamo parlando di una folta schiera di software e di servizi disponibili online, spesso ed erroneamente denominati automatici, in grado di effettuare una scansione sul codice della pagina (o di più pagine in contemporanea), per poi generare una sorta di report riassuntivo di tipo testuale e/o grafico in cui vengono evidenziati errori e possibili errori legati all’accessibilità della pagina. Un “motore di ricerca” di questi strumento è disponibile sul sito del W3C [http://www.w3.org/WAI/ER/tools/Overview.html].
Questi strumenti di validazione possono effettivamente contribuire a ridurre il tempo e gli sforzi necessari a valutare l’accessibilità di pagine o interi siti Web, e possono concretamente aiutare gli sviluppatori a prevenire e a limitare barriere virtuali, aumentando il livello di qualità complessivo dell’applicazione. Come già accennato, quello che questi strumenti possono fare è:
- Stabilire la conformità dei siti Web rispetto a quei punti di controllo che possono essere effettivamente controllati automaticamente.
- Aiutare a tener traccia di tutti i controlli manuali che non possono non essere automatizzati, non soltanto sulla validità del codice, ma anche sulla presenza di elementi critici in termini di mancata accessibilità.
Ribadiamo ancora una volta che molti aspetti legati all’accessibilità di una pagina richiedono il giudizio umano e non possono che essere affrontati “manualmente”. Per esempio, dei 65 punti di controllo presenti nelle WCAG 1.0, solo 19 (meno del 30%) possono essere valutati automaticamente e questo ci pare abbastanza per comprendere che, se da una parte gli strumenti semiautomatici possono risultare utili, certamente non possono risolvere il discorso sulla valutazione dell’accessibilità di una pagina. Inoltre, in alcuni casi questi strumenti possono fornirci risultati falsi (falsi positivi o falsi negativi) e quindi quanto meno fuorvianti e certamente pericolosi se non gestiti da operatori esperti, ben consci dei limiti di questi software.
Quindi, questi strumenti non sono in grado di stabilire se una pagina è accessibile, ma sono certamente capaci di evidenziare se una pagina è non accessibile; cioè:
- Se invece esso evidenzia degli errori, allora è chiaro che quell’errore (fatti salvi i falsi negativi) effettivamente è presente sulla pagina.
- Se invece esso non evidenzia errori, questo non vuol certamente dire che la pagina è accessibile, visto che non tutti i possibili errori vengono intercettati, anzi sarà bene controllare anche la correttezza delle conformità evidenziate dal validatore, visto che i falsi positivi sono sempre in agguato.
Ci sembra, a questo punto, molto istruttivo ed utile il lavoro svolto da Gez Lemon di JuicyStudio che ha predisposto una pagina http://juicystudio.com/experiments/invalid.html contenente l’elenco di tutti i punti di controllo di priorità 1 (A) e di priorità 2 (AA) delle WCAG 1.0, e per ciascuno di essi ha predisposto un esempio in cui la regola viene deliberatamente infranta.
Provate voi stessi a validare la pagina con i più diffusi validatori di accessibilità, noi l’abbiamo fatto con Torquemada (l’unico in italiano, sviluppato da Andrea Bernardini, Fondazione Ugo Bordoni), WebXact (il successore del famoso Bobby, ed anch’esso come Bobby oramai non più disponibile online) e Wave di WebAim.org. I risultati sono emblematici:
| Validatore | Errori riscontrati |
Controlli manuali suggeriti |
|---|---|---|
|
Torquemada |
2 |
9 |
|
WebXAct (A e AA) |
0 |
31 |