In occasione della Giornata Internazionale sulla Disabilità 2017 Roberto Scano ha scritto questo articolo sull’accessibilità specificandone la sua accezione di “caratteristica del web necessaria a tutti”, e per citare un esempio di non competenza in ambito di sviluppo per il web, parla dell’elemento “label”.

Ha perfettamente ragione quando dice:

“Trovo a volte imbarazzante discutere con “pseudo esperti” in tema di moduli, scoprendo che non sanno a cosa servono le etichette (label)”.

Nelle attività professionali di verifiche di accessibilità o nella guida di team di sviluppo di interfacce utente per il web, ci si trova costantemente a correggere errori di implementazione di tale elemento.  Ma perché Scano cita proprio questo? Andiamo per ordine.

Che cos’è una label

L’elemento “label” è incluso nelle specifiche HTML4.0 pubblicate nell’aprile del 1998 dal W3C.

È un elemento importantissimo perché specifica l’etichetta del campo in cui inserire il contenuto. Un esempio per i non esperti del settore:  la scritta “nome utente” che si trova prima del campo di inserimento del nome utente in un modulo di login.

Per parlare compiutamente di questo argomento si devono prendere in considerazione altre due specifiche del W3C, l’HTML5 (ottobre 2014), e le WAI-ARIA1.0 (marzo 2014). Tutte cose decisamente vecchie e consolidate.

Come si usa

Usare una label è davvero una cosa semplice: ogni campo input ha una sua label. Non ci possono essere ambiguità o fraintendimenti. Si trovano online centinaia di tutorial su questo tema, personalmente preferisco sempre affidarmi ai materiali ufficiali del W3C, li trovate qui.

A cosa serve

Si tratta dell’elemento che specifica l’etichetta associata al relativo campo input. Un campo input senza un elemento label è privo di significato. Nonostante le mirabolanti tecnologie di cui oggi disponiamo, i moduli sono l’elemento primario per l’interazione con gli utenti, e saper gestire correttamente le label è uno degli spetti fondamentali.

Perché è importante

Costruire moduli per il web senza label, o peggio ancora con label errate o implementate in maniera errata, è come costruire una città senza indicazioni stradali né numeri civici, né nomi sui campanelli, sostenendo che tanto, tutto sommato, le persone sanno come è fatta la città e ci si ritrovano. Peccato che non sarebbe possibile costruire navigatori per le automobili, organizzare servizi, fare censimenti, individuare rapidamente percorsi per le auto, ecc. Questo paragone mi sembra prefetto e fa capire bene perché Roberto Scano nel suo articolo cita proprio l’elemento label.

I problemi tecnici che derivano da questi errori sono principalmente i seguenti:

  1. le tecnologie assistive non potranno guidare i non vedenti nella compilazione del modulo
  2. gli utenti non potranno cliccare sull’etichetta per accedere al campo da compilare.
  3. tutte le tecnologie in grado di analizzare le pagine web (i motori di ricerca per esempio) non potranno catalogare bene le pagine in mancanza di valore semantico.

Ma come mai nonostante la facilità di utilizzo e gli innumerevoli esempi molti sviluppatori sbagliano, e tanto. Vediamo qui di seguito una serie di errori in cui si incorre.

Mancanza di label, colpa dell’aspetto visivo

È uno degli errori più comuni. Un campo input non è descritto da una label, perché talvolta gli sviluppatori sono attratti dagli aspetti visivi, non conoscono il codice, e non ne conoscono il valore semantico. Di conseguenza, se un testo scritto in un elemento generico di tipo “div”, rassomiglia esteticamente a una label, va a finire che ci si limita a utilizzare quell’oggetto, proprio perché “ci sta bene” visivamente.

Una label specifica per ogni input

Come già detto, una label può descrivere un solo campo input, e questo lo si fa con l’attributo “for” dell’elemento label. Qui il tutorial.

In pratica l’attributo “for” di label deve assumere il valore dell’attributo “id” del campo input associato. E se è così semplice perché si sbaglia? Principalmente per due motivi:

  1. Un campo input ha normalmente due attributi. “id” e “name”. Alcuni sviluppatori disattenti pensano che l’attributo for di label debba essere associato a “name”, anziché all’attributo “id”.
  2. Spesso in fase di sviluppo si tende a fare copia e incolla di porzioni di codice da tutorial e demo. Porzioni che poi vengono modificate (spesso anche runtime) quando si va in produzione. Se non si fa attenzione gli attributi “for” e “id” possono essere dimenticati e le applicazioni vanno in produzione con i valori di test.

Può sembrare banale, ma è una cosa talmente ricorrente che la maggioranza degli errori di progettazione dei moduli online presenta questo tipo di errore, anche quando il modulo è composto da un solo campo, per esempio gli input di ricerca.

Mancanza di label per scelta consapevole

In molti moduli moderni, sempre più sviluppatori amano omettere la label, perché magari credono che sia banale dover specificare un’etichetta per un campo di ricerca se a fianco c’è il pulsante “cerca”. E invece no. La label non può essere omessa, neanche se il pulsante lì vicino ha come valore “cerca” oppure “vai”. Tuttavia può può essere nascosta o sostituita con altri metodi validi:

  1. nascosta con i foglio di stile
  2. sostituita dall’attributo “title” dell’input
  3. sostituita con l’attributo “aria-labelledby” associato all’elemento “id” del relativo pulsante.

Qui tutti gli esempi https://www.w3.org/WAI/tutorials/forms/labels/#hiding-the-label-element

Il placeholder, bello quanto poco utile.

Con l’HTML5 i campi input si sono arricchiti del nuovo attributo “placeholder”. In pratica quel testo guida che si vede nei campi input prima di cliccarci dentro (es. nei moduli di ricerca: “inserisci qui le parole da cercare”).

C’è una cosa fondamentale da sapere: il placeholder non è un sostituto della label. Lo dice la specifica del W3C “The placeholder attribute should not be used as a replacement for a label.

Eppure è un must. Se ne vedono a decine. E questo è un errore che riguarda tutti gli utenti: il placeholder ha la proprietà di scomparire appena si clicca sul campo input col mouse (focus) lasciando alla memoria dell’utente l’onere di ricordare cosa ci fosse scritto.

Una label che simula un placeholder

C’è poi questa tecnica che è davvero piena di insidie: mettere una label che simula un placeholder in modo da evitare una presunta antiestetica label. Infatti molti designer hanno una specie di repulsione per le label, una cosa davvero incomprensibile.

Qui trovate un esempio nel modulo di ricerca iniziale e un articolo in merito.

A molti questa tecnica sembra un uovo di colombo ma si rivela spesso fonte di innumerevoli errori di implementazione.

Innanzi tutto ci si dovrebbe fare una domanda: perché simulare un oggetto quando ce n’è uno che fa esattamente la stessa cosa e la fa in modalità semanticamente corretta? Insomma, se esiste il placeholder, perché si dovrebbe costringere una label a farne le veci?

Infatti non c’è un motivo reale, la tecnica corretta potrebbe essere quella di usare il placeholder e usare una delle tecniche per nascondere la label, come descritto precedentemente.

Ma attenzione, come già detto, il placeholder non è fisso, scompare appena si da il focus al campo input. Se il modulo è composto da più campi l’utente potrebbe trovarsi nella condizione di non sapere più in quale campo aver cliccato, visto che, appunto, la label è scomparsa come il placeholder.

Ai placeholder spesso vengono associati colori troppo tenui da renderli quasi invisibili. Quando si crea una label al posto del placeholder spesso si fa la stessa cosa, rendendo di fatto la label non visibile (inaccessibile).

Infine, siccome per realizzare questa tecnica serve, un codice HTML appropriato, con il relativo CSS e il necessario JavaScript, succede spesso che sviluppatori disattenti effettuino inconsapevoli copia e incolla da tutorial vari, che dopo i necessari adattamenti finiscono per contenere gli stessi errori indicati nei paragrafi precedenti.

Conclusione

Insomma, le label e le relative tecniche di utilizzo, sono una base essenziale per lo sviluppo di moduli web accessibili.

Come giustamente dice anche Roberto Scano non può chiamarsi professionista chi non conosce questi elementi, proprio perché sono la base.

Lo sviluppatore che non sa usare le label è come un salumiere che non sa usare il coltello e affetta sempre il prosciutto con l’affettatrice, perché lo fanno tutti, perché è più comodo e perché fondamentalmente pensa che sia la stessa cosa. Ma non è così, ve lo dice uno che ama i prosciutti 🙂