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

Uno degli incubi ricorrenti di chi - non vedente - desidera consultare l'orario dei treni via Internet, è l'apposito modulo (o "form", in inglese) sul sito di Trenitalia.com. Sono anni ormai che le associazioni di disabili tentano senza successo di indurre le Ferrovie dello Stato a modificare sito e modulo, affinché possano essere utilizzati anche per mezzo di browser testuali e tecnologie assistive. Ma cos'ha questo modulo (o form) di così terribilmente sbagliato? Niente di particolare... a parte il fatto di essere inserito in un frame privo di descrizione testuale alternativa, all'interno di una pagina gestita per mezzo di tabelle e con codice HTML approssimativo, di essere completamente privo di elementi specifici di ausilio per l'accessibilità (FIELDSET, LEGEND, LABEL) e di essere infine inoltrabile solo per mezzo di un javascript... Non c'è che dire: un bel servizio pubblico!

Ma è inutile insistere sull'inaccessibilità dei moduli di Trenitalia.com: se ne sono già dette e scritte tante in proposito, che continuare a parlarne equivale a sparare sulla Croce Rossa. Vediamo piuttosto quali accorgimenti utilizzare per rendere accessibile al meglio un modulo web che non sia bacato in partenza.

• Usare gli appositi elementi strutturali per i moduli. La stragrande maggioranza dei moduli web è inserita all'interno di tabelle di impaginazione, utilizzate per disporre i vari campi in una griglia che soddisfi le esigenze grafiche dello sviluppatore. Rispetto a questo sistema, un'alternativa più accessibile è costituita dall'utilizzare i CSS per la presentazione visuale. In questo modo è possibile, in molti casi, ottenere un risultato estetico del tutto analogo a quello consentito dall'uso delle tabelle. E' possibile inoltre ottenere un importante vantaggio: nel codice HTML rimangono i soli elementi strutturali del modulo, il che aiuta sicuramente l'interpretazione della pagina da parte di browser testuali e tecnologie assistive. In particolare è consigliabile usare l'elemento FIELDSET come contenitore di gruppi omogenei di campi e l'elemento LEGEND per dare un nome ai gruppi, come nell'esempio seguente:

  <form action="..." method="post">
    <fieldset>
      <legend>Dati anagrafici</legend>
      ... campi in cui inserire i dati anagrafici ...
    </fieldset>
    <fieldset>
      <legend>Informazioni sulla privacy</legend>
      ... campi in cui inserire le info sulla privacy ...
    </fieldset>
    <fieldset>
      <legend>Procedura d'acquisto</legend>
      ... campi in cui inserire i dati per l'acquisto ...
    </fieldset>
  </form>
  

  Un altro elemento strutturale utile per l'accessibilità è OPTGROUP: consente di raggruppare in insiemi omogenei le opzioni inserite per mezzo dell'elemento OPTION all'interno di un elemento SELECT. Tramite OPTGROUP si potrebbero per esempio suddividere, all'interno di un lungo menu a discesa, i nomi delle province italiane in gruppi più brevi ripartiti in base all'appartenenza ad una stessa regione. Un esempio di applicazione di questo elemento è contenuto nel capitolo delle Specifiche HTML 4.01 dedicato ai moduli.

• Usare l'elemento LABEL per etichettare i campi. Una delle regole per rendere più accessibile un modulo è quella di tenere vicini i campi in cui va inserito il testo, e i relativi nomi: bisogna fare in modo, insomma, che l'utente non abbia mai dubbi su quale sia l'etichetta di un campo. Ma la sola vicinanza può non bastare. Per limitare dubbi o errori da parte dell'utente, l'HTML mette a disposizione degli autori l'elemento LABEL, il cui scopo è di associare strutturalmente un'etichetta ad un controllo. L'associazione si può fare in due modi: o tramite l'uso combinato degli attributi "for" e "id", a cui si dà il medesimo valore, come in:

  <label for="nomeutente">Inserisci il tuo nome</label><br />
  <input type="text" size="20" id="nomeutente" name="nomeutente" />
  

  oppure annidando il campo testo all'interno dell'elemento LABEL nel modo seguente:

  <label>Inserisci il tuo nome<br />
    <input type="text" size="20" id="nomeutente" name="nomeutente" />
  </label></li>
  

• Usare gli attributi "tabindex" e "accesskey" per favorire la navigazione da tastiera. L'attributo " tabindex" serve per definire l'ordine di selezione di un campo modulo all'interno della pagina, in modo che possa essere selezionato dall'utente per mezzo di pressioni successive del tasto TAB. E' buona norma utilizzare come valori per quest'attributo numeri che aumentano di dieci in dieci, in modo da lasciare la possibilità di inserire in seguito uno o più campi intermedi, senza dover riscrivere tutti i valori di "tabindex" dei campi successivi a quelli aggiunti.

  Gli screen reader più recenti hanno la capacità di attivare direttamente il primo campo modulo presente nella pagina. Ciò renderebbe inutile per i non vedenti la presenza di "tabindex", a meno che l'autore non voglia stabilire un ordine di selezione dei campi differente da quello che è il loro ordine di successione naturale sulla pagina. Tuttavia, è consigliabile che gli sviluppatori usino comunque l'attributo "tabindex", se non altro per consentire una più rapida selezione degli elementi del modulo a chi non può utilizzare il mouse. Ecco un esempio di impostazione di questo attributo:

  <input type="text" size="20" tabindex="10" id="nome" name="nome" />
  .....
  <input type="text" size="20" tabindex="20" id="cognome" name="cognome" />
  .....
  <input type="text" size="20" tabindex="30" id="e-mail" name="e-mail" />
  

  In aggiunta all'attributo "tabindex" si può utilizzare - per esempio per i campi principali di un modulo molto lungo - l'attributo " accesskey", il cui scopo è consentire di selezionare per mezzo di una scorciatoia da tastiera l'elemento in cui è inserito. Nel caso di un modulo complesso, l'utente che naviga tramite tastiera potrebbe così saltare direttamente ad uno dei campi principali, senza essere costretto ad attivare in successione tutti i campi intermedi premendo il tasto TAB innumerevoli volte consecutive. Ecco di seguito un tipico esempio di uso dell'attributo "accesskey" (l'applicazione dell'attributo all'elemento LABEL fa sì che il fuoco della selezione cada sul campo testo ad esso associato):

  <label accesskey="n" for="nome">Inserisci il tuo nome [n]</label><br />
  <input type="text" size="20" id="nome" name="nome" />
  

  Va precisato che l'utilizzo di "accesskey" come ausilio di accessibilità genera alcuni problemi. Innanzitutto non è stata ancora definita una convenzione standard che associ determinati tasti a specifiche funzioni: ciò comporta per gli utenti la necessità di leggere e imparare le associazioni tasto/funzione per ogni sito che utilizza scorciatoie da tastiera.

  In secondo luogo non esiste ancora una convenzione standard su come rendere nota la presenza di queste scorciatoie agli utenti vedenti che visitano il sito o la pagina.

  Una convenzione non universalmente accettata è quella di riportare prima o dopo l'etichetta, tra parentesi quadre, la lettera che consente l'attivazione da tastiera del campo modulo (o del collegamento, nel caso che la scorciatoia sia applicata ad un collegamento ipertestuale). E' il sistema che abbiamo utilizzato nell'esempio precedente.

  Un terzo problema è costituito, infine, dalle procedure di attivazione delle scorciatoie, che cambiano da browser a browser, e rendono dunque impossibile fornire agli utenti istruzioni semplici ed universali per l'uso degli accesskey impostati. Per tali motivi, pur non sconsigliando l'uso di questo attributo, suggeriamo di utilizzare di preferenza "tabindex", utile soprattutto se l'ordine logico di selezione non corrisponde per qualche ragione all'ordine di successione dei campi sulla pagina.

• Evidenziare i campi modulo rispetto allo sfondo. Uno dei problemi principali che incontrano gli ipovedenti è la scarsa visibilità dei campi modulo sulla pagina. Per consentire loro di identificarli con chiarezza, è consigliabile studiare un tipo di impaginazione che ne favorisca la visibilità: per esempio un forte contrasto tra lo sfondo circostante, i campi e i testi delle etichette. Meglio ancora sarebbe creare una netta bordatura intorno ai campi, in modo da renderne ben definito il perimetro. Ciò si può ottenere facilmente, almeno con i browser grafici di ultima generazione, usando apposite definizioni di stile. Per esempio:

  input {border: 3px solid #000}
  

  che crea un bordo nero di tre pixel intorno ai campi definiti dall'elemento INPUT. La necessità di evidenziare l'elemento da compilare rispetto allo sfondo è massima per i componenti più piccoli dei moduli, cioè le caselle di spunta ("checkbox" in inglese) e i radiocomandi ("radiobutton"). Un esempio di evidenziazione tramite CSS di questi elementi è visibile nel modulo di contatto dei forum accessibili di Diodati.org: i due radiocomandi, che sarebbero normalmente poco visibili per un ipovedente, sono bordati di grigio scuro per farli risaltare rispetto al grigio chiaro dello sfondo.

• Consentire all'utente di ingrandire i campi modulo. Una possibilità in più, per permettere agli ipovedenti un'agevole lettura e compilazione dei moduli, consiste nel creare una funzione per ingrandire all'occorrenza i campi ed il loro contenuto. Per chi volesse vedere un'applicazione pratica di ciò, la funzione è stata implementata in tutti i moduli presenti sui forum di Diodati.org: per mezzo di un uso combinato di script lato server e definizioni CSS, si permette all'utente di modificare lo stile dei campi, ingrandendoli o rimpicciolendoli a piacere. Vengono modificati sia lo spazio occupato dal campo sia la dimensione del testo al suo interno.

  L'uso basilare della funzione è il seguente (nell'esempio il linguaggio lato server utilizzato è ASP):

  <style type="text/css">
  ............
  <% if ... then %>
    input,select {
      font-size:180%;
      font-family:arial,helvetica,sans-serif;
      font-weight:bold
    }
    textarea {
      font-size:180%;
      font-family:monospace;
      font-weight:bold
    }
  <% else %>
    input,select {
      font-size:100%;
      font-family:arial,helvetica,sans-serif
    }
    textarea {
      font-size:100%;
      font-family:monospace
    }
  <% end if %>
  ............
  </style>
  

  Il semplice codice di programmazione qui riportato, tradotto in linguaggio discorsivo, significa: se l'utente fa una certa scelta (nel nostro caso quella d'ingrandire, premendo un apposito pulsante sulla pagina), allora applica lo stile ingrandito dei campi modulo, definito da dimensioni al 180% e caratteri in grassetto; viceversa, se l'utente non fa nessuna scelta oppure se ha scelto qualcosa di diverso rispetto a prima - cioè se ha scelto di rimpicciolire invece che di ingrandire -, imposta lo stile normale predefinito, caratterizzato da dimensioni al 100% e niente grassetto.

  Benché alcuni browser di ultima generazione come Opera e Mozilla consentano nativamente di ingrandire a piacere tutta la pagina, moduli compresi, altri browser - come il ben più diffuso Internet Explorer - non possiedono altrettanta versatilità. L'uso della funzione di ingrandimento dei campi modulo sopra descritta, usata in combinazione con il limitato ingrandimento dei caratteri possibile in Internet Explorer, consente anche agli ipovedenti che usano questo browser un'agevole lettura e compilazione dei moduli.

Prima di abbandonare l'argomento, è importante una precisazione. Il punto di controllo 10.4 delle WCAG 1.0, che ha priorità 3, suggerisce agli sviluppatori di inserire dei caratteri segnaposto in ogni campo modulo destinato all'immissione di testo da parte degli utenti. Questa è una norma transitoria: viene cioè raccomandata la sua applicazione, solo finché i programmi utente in uso, tecnologie assistive comprese, non gestiranno correttamente i controlli vuoti.

Ma i programmi utente attualmente utilizzati, dai più datati browser grafici ai sintetizzatori vocali come Jaws, sono in grado di gestire correttamente anche i campi modulo vuoti. Continuare perciò a mettere del testo segnaposto all'interno dei campi, al solo scopo di favorire eventuali antiche tecnologie non conformi allo standard HTML, ci sembra diventato del tutto inutile. Per di più, la presenza di un testo da cancellare all'interno di un campo di immissione conduce ad una palese perdita di usabilità del modulo: molti utenti, infatti, dimenticano di cancellare il testo segnaposto, o lo cancellano parzialmente, e ciò finisce con l'invalidare inevitabilmente i dati che essi inoltrano.

Se lo scopo della presenza di un testo segnaposto è, invece, quella di attirare l'attenzione dell'utente sul campo, il che si rivelerebbe utile per gli ipovedenti, allora il medesimo obiettivo può essere conseguito con un'evidenziazione dei bordi per mezzo dei CSS, ottenibile con i sistemi che sono stati descritti più sopra.

Per tali ragioni, consigliamo agli sviluppatori - discostandoci stavolta dall'aderenza alle WCAG 1.0 - di non inserire del testo segnaposto nei campi di immissione dei loro moduli, a meno che non si tratti di testo che non necessita di essere cancellato dall'utente (per esempio la stringa "http://" in un campo che deve essere completato con l'inserimento di un indirizzo web).