Ci sono alcune considerazioni da fare. Perseguire l’accessibilità è un obiettivo importante, che tutti i siti dovrebbero porsi, non solo quelli pubblici, che peraltro già raramente se lo pongono. Tuttavia, da questi esempi emerge che:

1. Seguire alla lettera le wcag1.0, ovvero le raccomandazioni del w3c per l’accessibilità dei contenuti web, non è sempre così facile, a causa di ambiguità e limiti delle linee guida stesse, ma anche di inadeguato supporto da parte degli user agent
2. seguirle non garantisce comunque l’usabilità delle vostre pagine. Se non vi ponete anche ulteriori problemi legati alla qualità dell’esperienza dell’utente sul vostro sito, o meglio ancora, se non testate le pagine con degli utenti reali, potreste produrre pagine valide e accessibili formalmente, ma che creano significativi ostacoli ad una corretta navigazione anche ad utenti normodotati.

Aggiungiamo, ad onor del vero, che le WCAG 1.0 prevedono fra le linee guida che la navigazione del sito debba essere semplice e intuitiva, e che il linguaggio debba essere comprensibile. Sfortunatamente, queste linee guida assomigliano di più a delle euristiche che a vere e proprie linee guida controllabili. A quali condizioni la navigazione è intuitiva e semplice? Quando il linguaggio si può considerare comprensibile? E chi deve preoccuparsi di verificarlo – e come? A queste domande le WCAG 1.0 non rispondono, e richiamano ad un semplice controllo umano, cioè non basato sul codice. Ecco perché i validatori automatici dell’accessibilità, pur essendo strumenti utili e addirittura indispensabili per sgravare lo sviluppatore da compiti altrimenti tediosissimi, non possono dar conto della qualità dell’esperienza dell’utente, e difficilmente possiamo immaginare dei valutatori automatici dell’usabilità. Proprio perché essa dipende spesso da scelte semantiche, logiche, scarsamente operazionalizzabili e variabili a seconda del contesto e del tipo di pubblico.

Questo ci riporta ad un limite tutto interno all’accessibilità, per come è attualmente normata dal WAI: quello di non prevedere per il momento forme di verifica sul campo del lavoro svolto, a differenza dell’usabilità che fa invece dei test con gli utenti l’arma migliore per la scelta di soluzioni di efficacia pratica e non solo teorica.