Diodati.org | Accessibilità e traduzioni dal W3C      Leggi Omega Centauri!

Sponsor ufficiale di Diodati.org: Hosting a partire da 3,33 Euro/mese | Domini a partire da 10,79 euro/anno | Server dedicati a partire da 40 euro/mese, VPS Hosting da 30 euro/mese

Dalle fonti citate nella Introduzione in merito alla verifica soggettiva sono state ricavate le seguenti undici caratteristiche che verranno considerate in modo da stabilire diversi livelli progressivi di accessibilità e fruibilità delle informazioni (es. livello *, livello **, livello ***).

Per ciascuna caratteristica si riportano alcuni esempi di sua applicazione ad un sito web.

1. percezione: le informazioni e i comandi necessari per l’esecuzione dell’attività devono essere sempre disponibili e percettibili (Livello *).

   Esempi:

   • Strutturare l’informazione su più livelli: dalla sintesi al documento completo
   • Stabilire una scala di importanza per le informazioni contenute in una pagina e presentarle in ordine decrescente : prima le più importanti
   • Aumentare la leggibilità dei contenuti utilizzando frasi brevi e facilmente identificabili
   • Evitare pagine troppo lunghe

   Commento al requisito 1

   O c'è qualcosa di clamoroso che mi sfugge oppure tutti gli esempi di questo primo punto sono sbagliati.

   Tutti riguardano, infatti, aspetti che facilitano - o dovrebbero facilitare - la comprensione dei contenuti, non la loro percezione. Usare un adeguato livello di contrasto tra primo piano e sfondo: quello sì che riguarderebbe la percezione. Ma creare un sommario dei contenuti, mettere le informazioni importanti all'inizio, scrivere frasi brevi sono tutte accortezze che influenzano la comprensibilità del contenuto, non la sua percepibilità (si veda anche, in proposito, la spiegazione presente nelle WCAG 1.0 sui due metodi generali su cui le linee guida sono basate: ensuring graceful transformation, and making content understandable and navigable. Il primo metodo riguarda la percepibilità, il secondo la comprensibilità dei contenuti. Gli esempi qui riportati sono tipici del secondo metodo).

   L'ultimo esempio, poi, indipendentemente da se riguardi la percezione o la comprensione, è ambiguo nella formulazione e probabilmente inesatto. Innanzitutto bisognerebbe stabilire cosa si intende per "pagine troppo lunghe": 2.000 caratteri, 3.000 caratteri, 15.000 caratteri? Non è detto, inoltre, che fare pagine brevi sia sempre la miglior soluzione: dipende dall'argomento trattato e dal pubblico a cui ci si rivolge.

2. uso: le informazioni e i comandi necessari per l’esecuzione delle attività devono essere facili da capire e da usare (Livello *).

   Esempi:

   • Evidenziare la struttura dei contenuti della pagina con intestazioni, liste, ecc…
   • Utilizzare un linguaggio comprensibile alla grande maggioranza dei destinatari
   • Rendere riconoscibile ai programmi utente, ivi comprese le tecnologie assistive, la lingua principale della pagina e i cambiamenti di lingua interni, almeno per grandi blocchi di testo
   • Prevedere un glossario dei termini tecnici
   • Rendere riconoscibile ai programmi utente, ivi comprese le tecnologie assistive, la lingua principale della pagina e i cambiamenti di lingua interni, almeno per grandi blocchi di testo
   • Fornire versioni stampabili dei documenti, con indicazione esplicita dell’ URL da cui il documento è stampato
   • Ridurre al minimo possibile le operazioni necessarie al raggiungimento di un obiettivo
   • Permettere all’utente di saltare sequenze di link (soprattutto se poste all’inizio della pagina e comuni a tutte le pagine) per arrivare velocemente al contenuto specifico

   Commento al requisito 2

   Anche in questo caso troviamo esempi che generano non pochi problemi.

   Il primo punto dell'elenco sembra sovrapporsi all'esame tecnico, richiesto alla pagina precedente, che dice: Verifica dell’esperto sull’uso degli elementi e degli attributi secondo le specifiche del linguaggio. Ad esempio in HTML: gli elementi Header sono stati utilizzati per strutturare il contenuto e non per ottenere effetti grafici. [...] Ciò dimostra bene, se ce ne fosse bisogno, che è difficile separare in modo chiaro e univoco ciò che riguarda l'analisi tecnica del codice e ciò che riguarda, invece, gli aspetti semantici del contenuto.

   Il secondo punto, veramente fondamentale per l'accessibilità, meriterebbe un capitolo a sé: la semplificazione del linguaggio usato nei documenti pubblicati sul Web costituisce da solo un problema formidabile per l'accessibilità dei siti delle Pubbliche Amministrazioni. Non è pensabile di ridurre una materia così complessa ad un semplice accenno, come abbiamo in questo studio. Rimando per un approfondimento del problema ad alcuni capitoli della mia guida all'accessibilità: http://www.diodati.org/scritti/2004/guida/index.asp#sezione2-3.

   Il terzo punto, quello relativo ai cambi di lingua, risulta duplicato dal quinto, evidentemente riprodotto uguale per errore. La limitazione almeno per grandi blocchi di testo sembra rendere lecito non segnalare i cambi di lingua per singole parole. Dato l'attuale scarso supporto delle tecnologie assistive ai cambi di lingua al volo, mancare di segnalare dei cambi di lingua in una pagina web non cambia le cose all'atto pratico. Il consiglio migliore per raggiungere una buona accessibilità è, in realtà, quello di ricorrere solo in caso di vera necessità all'uso di parole straniere all'interno di un testo in italiano.

   Il sesto punto va in conflitto con la richiesta di usare i linguaggi di marcatura esistenti in modo conforme alle specifiche W3C. Per i fogli di stile disponiamo infatti già del media type print, che ci permette di utilizzare un foglio di stile specifico per la stampa, senza la necessità di ricorrere ad una versione alternativa in (X)HTML della pagina corrente, creata ad hoc per la stampa.

   Il settimo punto non può essere sempre considerato una priorità: in siti molto complessi, allungare di una o due unità la serie delle operazioni per raggiungere un obiettivo può consentire di sfoltire la quantità - spesso enorme - dei menu di navigazione e dei collegamenti presenti in una singola pagina, rendendo più agevole per l'utente la comprensione della struttura generale dei contenuti.

   L'ottavo ed ultimo punto si sovrappone a quanto stabilito dal requisito 19 delle verifiche tecniche.

   In generale, il fatto che le verifiche soggettive ricontrollino in certi casi aspetti già esaminati da chi ha effettuato le verifiche tecniche, mi sembra una fonte di problemi non indifferente. Se le verifiche tecniche devono stabilire la presenza o l'assenza di requisiti oggettivi, allora non serve un successivo esame soggettivo. Viceversa, se non si tratta di requisiti veramente oggettivi, allora non dovrebbero comparire nell'elenco delle verifiche tecniche.

3. consistenza: stessi simboli, messaggi e azioni devono avere gli stessi significati in tutto l’ambiente (Livello *).

   Esempi:

   • Presentare informazioni e funzioni simili in maniera consistente in tutto il sito: loghi, titoli delle pagine, elementi di navigazione, ecc.
   • Rendere coerente l’impostazione grafica delle pagine in tutto il sito
   • Rendere consistenti i titoli delle pagine con il testo dei link che le indirizzano
   • Mantenere un aspetto grafico coerente per tutti i collegamenti presenti nel sito rispettando il più possibile le convenzioni Web
   • Utilizzare lo stesso tipo di carattere utilizzato per la presentazione di un oggetto in tutte le sue occorrenze nel sito

   Commento al requisito 3

   La cosa da cambiare d'urgenza è il nome del requisito: "consistenza" in italiano significa "solidità, resistenza". E' stata usata questa parola, evidentemente, come traduzione "a orecchio" dell'inglese "consistency" (termine appartenente alla categoria dei cosiddetti "falsi amici"). La parola da utilizzare in italiano è invece "coerenza". Allo stesso modo, vanno eliminate le occorrenze dell'aggettivo "consistente" nei vari esempi riportati, sostituendolo con l'aggettivo "coerente".

   Venendo al contenuto degli esempi, non mi è chiaro che cosa si intenda per "oggetto" nell'ultimo della serie.

   Modificherei anche il testo del terzo esempio nel modo seguente: Rendere coerenti i titoli delle pagine con il testo dei link che le referenziano.

4. salvaguardia della salute (safety): capacità dell’ambiente di salvaguardare e promuovere il benessere psicofisico dell’utente (Livello *).

   Esempi:

   • Assicurarsi che il movimento degli oggetti, se presente, non provochi disturbi da epilessia fotosensibile
   • Assicurasi che la gestione degli elementi grafici e del contrasto testo/sfondo siano tali da non disturbare la vista
   • Scrivere testi in modo tale da non stancare la vista

5. sicurezza: capacità dell’ambiente di fornire transazioni e dati affidabili, gestiti con adeguati livelli di sicurezza e riservatezza (Livello *).

   Esempi:

   • Dichiarare in modo esplicito le politiche adottate per la sicurezza delle transazioni
   • Dichiarare in modo esplicito le politiche adottate per la tutela della privacy delle informazioni
   • Avvisare l’utente sulle modalità di gestione e di comportamento di eventuali cookies inviati

   Commento al requisito 5

   Sia il requisito sia gli esempi allegati mi sembrano del tutto indifferenti ed indipendenti rispetto agli scopi dell'accessibilità.

6. trasparenza: l’ambiente deve comunicare il suo stato e gli effetti delle azioni compiute. All’utente devono essere comunicate le necessarie informazioni per la corretta valutazione della dinamica dell’ambiente (Livello **).

   Esempi:

   • Fornire agli utenti informazioni (feedback) su: dove si trovano, cosa possono fare, dove possono andare
   • Evitare caratteristiche e funzionalità dipendenti da dispositivo
   • Specificare i collegamenti a siti esterni
   • Riportare alla fine d ogni pagina la sua URL, affinché ne sia chiara la provenienza anche quando la pagina stessa sia consultata fuori linea.

   Commento al requisito 6

   A parte l'esempio che dice di evitare caratteristiche e funzionalità dipendenti da dispositivo, gli altri esempi mi sembrano degni di un terzo livello (Livello ***, secondo la simbologia usata in questo studio) piuttosto che di un secondo: mi sembrano infatti precauzioni più vicine agli scopi propri dell'usabilità che a quelli dell'accessibilità in senso stretto.

7. apprendibilità: capacità dell’ambiente di consentire l’apprendimento del suo utilizzo da parte dell’utente in tempi brevi e con minimo sforzo. (Livello **).

   Esempi:

   • Creare ambienti che riducano al minimo possibile la necessità di apprendimento
   • Fornire modalità semplici di ricerca nel sito

8. aiuto e documentazione: fornire funzioni di aiuto come guide in linea e documentazione relativi al funzionamento dell’ambiente. Le informazioni di aiuto devono essere facili da trovare e focalizzate sul compito dell’utente (Livello **).

   Esempi:

   • Fornire agli utenti informazioni su dove si trovano, cosa possono fare, dove possono andare
   • Mettere a disposizione una mappa del sito
   • Prevedere che la documentazione e l’help, quando presenti, siano facilmente raggiungibili da ogni pagina e scritti in modo conciso

   Commento al requisito 8

   Il primo esempio è uguale al primo esempio del requisito 6: errore o sovrapposizione voluta?

   Quanto all'oggetto del requisito, non mi è ben chiaro quando si richiede che siano presenti aiuti e documentazione sull'uso dell'interfaccia. Nel caso di siti dotati di funzionalità e servizi particolarmente complessi, avere degli aiuti specifici è certamente utile, se non addirittura indispensabile. Ma in molti altri casi, l'impaginazione prescelta dovrebbe essere autoesplicativa per quanto riguarda l'uso dei contenuti. Anzi, la presenza di documentazione di aiuto su come consultare un sito può essere vista come una sorta di fallimento dei criteri di comunicazione adottati dagli autori.

9. tolleranza agli errori: l’ambiente deve prevenire gli errori e, qualora questi accadano, devono essere fornite le modalità per recuperare in modo semplice eventuali errori di interazione e devono essere forniti appropriati messaggi che indichino chiaramente il problema e le azioni necessarie per recuperarlo (Livello **).

   Esempi:

   • Guidare l’utente passo passo nelle operazioni complesse
   • Prevedere un sistema di gestione dell’errore di collegamento a pagina inesistente che consenta all’utente di riprendere in percorso

10. gradevolezza: capacità dell’ambiente di favorire e mantenere l’interesse dell’utente (Livello ***).

    Esempi:

    • Presentare la pagina in modo gradevole e con contenuti leggibili a diverse risoluzioni dello schermo e/o tramite periferiche di output (es. stampa della pagina)

11. flessibilità: l’ambiente deve tener conto delle preferenze individuali e dei contesti (Livello ***).

    Esempi:

    • Utilizzare dimensioni leggibili dei font e consentire il loro dimensionamento agli utenti
    • Consentire la personalizzazione della presentazione, anche attraverso gli appositi controlli dei browser

    Commento al requisito 11

    La leggibilità dei caratteri e la loro ridimensionabilità sono aspetti importantissimi dell'accessibilità di una pagina web. Considerare tale requisito come un terzo livello (***) nella valutazione dell'accessibilità mi sembra veramente un errore. Propongo che la flessibilità dell'interfaccia, cioè la sua adattabilità alle scelte di personalizzazione degli utenti, sia riclassificata come primo livello nella scala di valutazione dell'accessibilità di un sito o di un'applicazione web.