Learn web development

Linee guida di accessibilità per CSS e JavaScript

CSS e JavaScript, quando usati propriamente, possono contribuire ad offrire una esperienza accessibile della rete. Se invece vengono usati in maniera incorretta possono causare una drastica riduzione dell'accessibilità. Questo articolo riporta alcune linee guida per l'uso di CSS e JavaScript che devono essere tenute in considerazione per permettere a contenuti anche molto complessi di avere il più alto grado di accessibilità possibile.

Prerequisiti: Conoscimenti basici sull'uso del computer, livello basico di HTML, CSS e JavaScript e una idea chiara di cosa è l'accessibilità.
Obiettivo: Imparare le basi di come usare CSS e JavaScript correttamente per massimizzare l'accessibilità dei propri siti e allo stesso tempo evitare errori che potrebbero ridurla.

CSS e JavaScript sono accessibili?

CSS e JavaScript non hanno il livello di importanza  per l'accessibilità che ha HTML, ma possono comunque arrecare grandi danni se usati impropriamente. Per dirlo in un'altra maniera, è importante che tu apprenda alcune linee guida sull'uso di CSS e JavaScript, per evitare di rovinare l'accessibilità dei tuoi documenti web.

CSS

Cominciamo col dare un'occhiata a CSS.

Semantiche corrette e aspettative dell'utente

È possibile usare CSS per modificare in qualsiasi modo l'aspetto di qualsiasi elemento HTML, ma questo non significa che lo dovresti fare. Come abbiamo detto piìu volte nell'articolo HTML: una buona base per l'accessibilità, dovresti utilizzare l'elemento semantico più appropriato per ogni situazione, ogni volta che è possibile. Se non lo fai, puoi causare confusione e problemi di usabilità a tutti gli utenti, e in particolare a quelli con disabilità. Usare le semantiche corrette significa soprattutto venire incontro alle aspettative degli utenti: gli elementi devono apparire e funzionare secondo certi criteri, a seconda della loro funzione, e gli utenti si aspettano che queste convenzioni siano rispettate. 

Per esempio, un utente che usa lettore di schermo non puì navigare una pagina attraverso gli elementi di heading se lo sviluppatore del sito non ha usato gli heading appropriati per etichettare il contenuto. Allo stesso modo, un heading perde la sua funzione visuale se lo hai modficato fino al punto in cui non appare più come un heading.

La regola generale è che puoi modificare lo stile di un elemento perchè sia congruente con lo stile generale del tuo sito, ma non modificarlo tanto da far si che non appaia o agisca come ci si aspetterebbe. Le sezioni seguenti riassumono i principali elementi HTML da prendere in considerazione.

Struttura del contenuto testuale "standard"

Heading, paragrafi, liste... Il contenuto testuale principale della tua pagina:

<h1>Heading</h1>

<p>Paragrafo</p>

<ul>
  <li>Lista</li>
  <li>Lista di due elementi.</li>
</ul>

Un CSS tipico potrebbe essere il seguente:

h1 {
  font-size: 5rem;
}

p, li {
  line-height: 1.5;
  font-size: 1.6rem;
}

Dovresti:

  • Selezionare dimensioni dei caratteri, altezza delle linee, spazio tra le lettere ecc. con lo scopo di rendere il tuo testo logico, comprensibile e facile da leggere. 
  • Assicurarti che i tuoi headings risaltino rispetto al corpo del testo, tipicamente apparendo in grassetto e con dimensioni del testo maggiori, come è il loro stile di default. Le liste dovrebbero apparire chiaramente come liste.  
  • Il tuo testo abbia un buon contrasto con il colore di fondo.

Vedi gli articoli in inglese Fondamenti di testo in HTML Modificare lo stile del testo per maggiori informazioni.

Testo enfatizzato

L'etichetta <em> conferisce enfasi al testo in cui è contenuta, mostrandolo in corsivo. L'etichetta <strong> ha lo stesso scopo, ma mostra il testo in grassetto:

<p>L'acqua è <em>molto calda</em>.</p>

<p>Le gocce d'acqua che si formano su una suoerficie sono chiamate <strong>condensa</strong>.</p>

Potresti aggiungere un colore particolare per il testo in evidenza:

strong, em {
  color: #a60000;
}

Ad ogni modo, raramente avrai bisogno di modificare lo stile di elementi enfatizzatio. Gli stili standard grassetto e corsivo sono molto riconoscibili, e modificarli potrebbe creare confusione. Per maggiori informazionisul'enfasi vedi l'articolo in inglese Enfasi e importanza.

Abbreviazioni

l'etichetta <abbr> indica una abbreviazione o un acronimo, e permette tramite l'attributo title di fornire la versione estesa della frase o parola abbreviata:

<p>Il contenuto di un sito è codificato tramite <abbr title="Hypertext Markup Language">HTML</abbr>.</p>

Anche in questo caso potresti voler apportare qualche semplice modifica allo stile:

abbr {
  color: #a60000;
}

Lo standard riconosciuto per indicare le abbreviazioni è una sottolineatura punteggiata, ed è raccomandabile non modificarlo significativamente. Per maggiori dettagli sulle abbreviazioni, vedi l'articolo in inglese Abbreviazioni.

I link sono il mezzo con cui ti muovi da un punto all'altro della rete:

<p>Visita la <a href="https://www.mozilla.org">homepage di Mozilla</a>.</p>

Qui sotto sono riportate alcune semplici modifiche allo stile dei link:

a {
  color: #ff0000;
}

a:hover, a:visited, a:focus {
  color: #a60000;
  text-decoration: none;
}

a:active {
  color: #000000;
  background-color: #a60000;
}

Lo stile di default per i link è la sottolineatura, inoltre si presentano in diversi colori a seconda del loro stato: blu è il colore nello stato di default, viola nel caso il link sia stato visitato, rosso quando si "attiva" cliccandoci sopra. Oltre a ciò, il puntatore del mouse cambia forma quando lo si passa su un link, e il link viene messo in evidenza quando riceve focus (per esempio tramite tast TAB). Nell'immagine qui sotto possiamo vedere l'evidenziazione di un link in Firefox (cornice punteggiata) e Chrome (cornice azzurra):

 

Puoi modificare lo stile dei link come più ti piace, ma facendo attenzione a fornire agli utenti un feedback quando interagiscono coi link. Quando un link cambia di stato si dovrebbe notare. inoltre, evita di eliminare il cambio di puntatore del mouse o l'evidenziazione quando riceve focus: entrambi i procedimenti sono molto importanti per l'accessibilità degli utenti che usano tastiera.

Formulari

I formulari sono elementi che permettono agli utenti di introdurre dati in un sito web:

<div>
  <label for="nome">Introduci il tuo nome</label>
  <input type="text" id="nome" name="nome">
</div>

Puoi vedere un buon esempio di uso di CSS  in un formulario qui: form-css.html (vedi anche la versione live).

La maggior parte del codice CSS che scriverai per i formulari sarà per modificare le dimensioni degli elementi, allineare label e input e migliorarne l'aspetto esteriore.

Non dovresti comunque modificare troppo il feedback visuale che gli elementi di un formulario mandano quando ricevono focus, che è in pratica lo stesso dei link (vedi sopra). Puoi modificare l'aspetto delle evidenziazioni applicate agli elementi del formulario quando ricevono focus o hover del puntatore del mouse per far si che lo stile del tuo sito sia consistente sui diversi browser, ma evita di rimuoverle. Come già detto, alcuni utenti contano su tali "segnali" per poter interpretare ciò che sta accadendo mentre navigano un sito.

Tabelle

Prendiamo ora in considerazione le tabelle che si usano per presentare dati.

Puoi vedere un buon esempio di tabella costruita con HTML e CSS qui:  table-css.html (vedi anche la versione live).

IL codice CSS applicato alle tabelle serve in genere a uniformarle allo stile generale del sito e a migliorarle esteticamente. Alcune buone pratiche sono ad esempio far si che gli header(intestazioni di file o colonne) della tabella siano in risalto, per esempio usando il grassetto, e far uso di una alternanza di sfondo chiaro e scuro per rendere più facile la distinzione tra le varie file della tabella.

Colore e contrasto

Quando scegli uno schema di colori per il tuo sito, assicurati che il testo abbia un colore che contrasta bene con lo sfondo. Un basso contrasto dei colori può produrre un effetto interessante dal punto di vista estetico, ma renderà molto difficile poter leggere il tuo contenuto alle persone con problemi visivi come il daltonismo.

C'è un modo molto facile per verificare se il contrasto che hai scelto è abbastanza alto da non causare problemi. Ci sono numerosi siti che ti permettono di introdurre il colore del testo e quello dello sfondo, per verificarli. Per esempio il sito Color Contrast Checker è facile da usare, e fornisce una spiegazione (in inglese) dei criteri WCAG (Linee guida per l'accessibilità dei contenuti Web) sul contrasto dei colori.

Nota: un contrasto alto sarà d'aiuto per poter leggere con maggiore facilità anche a chi si connette tramite telefono o tablet in ambienti con molta luce, come un parco o una piazza. 

Un altro consiglio è di non fare affidamento solo sul colore per fornire un certo tipo di informazioni/segnali, in quanto tali informazioni non potranno essere interpretate da chi non vede i colori. Per esempio, invece di limitarti a marcare in rosso i campi di un formulario che sono da compilare obbligatoriamente, marcali anche con un asterisco.

Nascondere elementi

Ci sono molte situazioni nelle quali è necessario che non tutto il contenuto sia mostrato allo stesso tempo. Per esempio nel nostro info box a schede (vedi codice sorgente) abbiamo tre schede con informazioni posizionate una sopra l'altra, e ci sono tre bottoni cliccabili per passare da una scheda all'altra (il box è accessibile anche da tastiera, usando il tasto TAB per spostarsi e INVIO per selezionare una scheda).

Gli utenti che usano lettori di schermo non avranno problemi a leggere tute le schede, l'importante è che l'ordine del contenuto sia sensato. Usare position : absolute (come nel nostro esempio) è in generale considerato come uno dei migliori metodi per nascondere contenuto, perchè non impedisce ai lettori di schermo di leggerlo.

D'altro canto, non dovresti usare visibility:hiddendisplay:none, perchè nascondono il contenuto ai lettori di schermo. A meno che, ovviamente, ci sia una buona ragione per nascondere questo contenuto ai lettori di schermo.

Nota: l'articolo in inglese Contenuto visibile solo ai lettori di schermo fornisce molti più dettagli su questo argomento.

È possibile che gli utenti modifichino lo stile dei tuoi elementi

A volte gli utenti alterano gli stili che hai impostato sostituendoli con stili personalizzati, per esempio:

Gli utenti modificano il CSS per differenti ragioni: un utente con problemi di vista può voler ingrandire automaticamente il testo su tutti i siti che visita, un utente con daltonismo può voler aumentare il contrasto dei colori per facilitare la lettura. Qualunque sia la ragione, dovresti tenere in considerazione questa possibilità, e usare un disegno del tuo sito che sia sufficientemente flessibile per poter gestire tali cambi. Per esempio, dovresti assicurarti che l'area dove è situato il tuo contenuto principale può supportare un ingrandimento del testo mantenendone il formato base e senza farne scomparire parti.

JavaScript

Anche JavaScript può causare problemi di accessibilità, dipendendo da come si utilizza.

JavaScript è un linguaggio molto potente, e possiamo usarlo per compiere un'infinità di funzioni, da semplici aggiornamenti del contenuto o della IU a giochi completi in 2D o 3D. Nessuna regola dice che tutto il contenuto deve essere accessibile al 100% a tutti, devi fare il possibile, e cercare di rendere le tue applicazioni il più accessibili possibile.

Il contenuto e gli elementi funzionali semplici sono relativamente facili da rendere accessibili: per esempio testo, immagini, tabelle, formulari e bottoni. Come abbiamo visto nell'articolo HTML: una buona base per l'accessibilità, le considerazioni chiave sono:

  • Buone semantiche: usare l'elemento più appropriato per ogni funzione specifica. Per esempio, assicurarsi di usare heading e paragrafi, ed elementi <button> e<a>.
  • Assicurarsi che il contenuto sia disponibile in forma testuale, o direttamente o tramite alternative testuali, come per esempio il testo alternativo per le immagini.

Abbiamo inoltre visto un esempio di uso di JavaScript per migliorare l'accessibilità aggiungendo una funzionalità che mancava (vedi Implementare l'accessibilità da tastiera in un secondo tempo). Questo procedimento non è ideale, visto che si dovrebbe usare l'elemento più appropriato per ogni funzione sin dall'inizio, ma dimostra che è possibile intervenire sul codice in situazioni in cui è necessario modificarlo dopo la sua creazione. Un altro modo per migliorare l'accessibilità degli elementi che usano JavaScript non semantico è usare la tecnologia WAI-ARIA per fornire semantica extra per gli utenti che usano lettori di schermo. Il prossimo articolo spiegherà in dettaglio come farlo.

Funzionalità complesse come i giochi in 3D non sono tanto facili da rendere accessibili. Un gioco 3D creato usando WebGL si svilupperà su un elemento <canvas> , che al momento non permette di fornire alternative testuali o altre informazioni utili per persone con disabilità visiva. Si può ragionevolmente obbiettare che un tale tipo di gioco non ha nel suo target di utenza persone non vedenti, e in effetti sarebbe esagerato pretendere di renderlo accessibile al 100%. Ma ad ogni modo è consigliabile implementare elementi di accessibilità come i controlli da tastiera, che permettano di usarlo anche a utenti senza mouse, e assicurarsi che lo schema dei colori abbia un contrasto sufficientemente alto per essere usabile da persone con daltonismo.

Il problema  di usare troppo JavaScript

Spesso gli sviluppatori di siti fanno un uso eccessivo di JavaScript. A volte si trovano siti in cui tutto è stato fatto con JavaScript, perfino HTML e CSS sono stati generati con JavaScript. Questo tipo di siti presentano grossi problemi di accessibilità e non solo, ed è sconsigliato sviluppare siti in questo modo.

Così come devi usare il giusto elemento per ogni funzione, assicurati anche di star usando la giusta tecnologia! Pensa bene se vale davvero la pena ricorrere a JavaScript per creare un pannello informazioni in 3D, mentre un semplice pannello testuale potrebbe essere sufficiente. Chiediti se hai bisogno di un formulario basato su un widget super complesso, quando magari un semplice campo di input testuale andrebbe bene. E non generare tutto il tuo contenuto HTML con JavaScript.  

Mantieni un uso non intrusivo di JavaScript

Dovresti usare JavaScript con discrezione quando crei il tuo contenuto. L'idea base è che JavaScript dovrebbe essere usato  quando possibile per migliorare una funzionalità, ma non per costruirla. Le funzioni più basiche del sito dovrebbero essere indipendenti da JavaScript, anche se a volte ciò non è possibile. Una buona pratica è usare funzionalità già presenti nei browser quando è possibile.

Buoni esempi di uso non intrusivo di JavaScript sono:

  • Eseguire la validazione dei formulari dal lato cliente, che avvisa istantaneamente l'utente di errori o problemi nei campi che ha riempito, senza dover aspettare che il server controlli i dati e invii una risposta. Senza validazione dal lato cliente, il formulario funzionerà comunque, ma con maggiore lentezza. 
  • Fornire controlli personalizzati per i <video> HTML5 perchè siano accessibili agli utenti che navigano tramite tastiera, insieme a un link diretto al video che si può usare se JavaScript non è disponibile (nella maggior parte dei browser i controlli <video> di default non sono accessibili tramite tastiera).

Per fare un esempio abbiamo creato un semplice formulario con validazione dal lato cliente, vedi: form-validation.html (vedi anche la versione live). Nella pagina vedrai un formulario, e quando provi a inviarlo lasciando uno o entrambi i campi vuoti apparirà un messaggio di errore per spiegarti qual è il problema.

Questo tipo di validazione di un formulario è non intrusiva, puoi usare il formulario anche con JavaScript disabilitato, e il formulario avrà comunque attiva anche la validazione dal lato server, perchè sarebbe troppo facile per un utente con cattive intenzioni bypassare la validazione dal lato cliente (per esempio disattivando JavaScript nel browser). La validazione dal lato cliente è utile per segnalare errori istantaneamente all'utente, senza dover attendere la risposta del server, migliorando quiandi l'usabilità del formulario.

Nota: nel nostro esempio la validazione dal lato server non è stata implementata. 

Abbiamo inoltre reso la validazione di questo formulario accessibile, usando l'elemento <label> per assicurarci che ogni campo di input abbia associata una etichetta senza alcuna ambiguità, di modo che i lettori di schermo possano leggere il blocco input+etichetta come una sola unità:  

<label for="nome">Inserisci il tuo nome:</label>
<input type="text" name="nome" id="nome">

La validazione avviene solo al momento dell'invio del formulario. In questo modo la IU non viene aggiornata troppo spesso potendo causare confusione negli utenti che usano lettori di schermo (e anche in quelli che non li usano):

form.onsubmit = validate;

function validate(e) {
  errorList.innerHTML = '';
  for(var i = 0; i < formItems.length; i++) {
    var testItem = formItems[i];
    if(testItem.input.value === '') {
      errorField.style.left = '360px';
      createLink(testItem);
    }
  }

  if(errorList.innerHTML !== '') {
    e.preventDefault();
  }
}

Nota: in questo esempio stiamo nascondendo e mostrando il messaggio di errore usando position: absolute invece che un altro metodo come visibility: hidden o display: none, perchè iquesto modo il lettore di schermo potrà leggerlo senza problemi.  

Una validazione reale sarebbe molto più complessa, dovremmo controllare che il nome introdotto sembri effettivamente un nome, che l'età sia un numero e che sia realistica (per esempio non può essere un numero negativo, o di 4 cifre). Nell'esempio abbiamo implementato un sistema di verifica che controlli se i campi sono stati riempiti o no (if(testItem.input.value === '')).

Quando la validazione ha terminato con esito positivo, il formulario è inviato. Se ci sono errori (if(errorList.innerHTML !== '')) l'invio viene bloccato (usando preventDefault()), e si mostra il messaggio di errore (vedi sotto). Con questo meccanismo gli errori saranno mostrati solo se ci saranno effettivamente errori, migliorando l'usabilità. 

Per ogni campo del formulario che è vuoto al momento dell'invio creiamo un item con un link e lo inseriamo nella lista errori (errorList).

function createLink(testItem) {
  var listItem = document.createElement('li');
  var anchor = document.createElement('a');
  anchor.textContent = testItem.input.name + ' field is empty: fill in your ' + testItem.input.name + '.';
  anchor.href = '#' + testItem.input.name;
  anchor.onclick = function() {
    testItem.input.focus();
  };
  listItem.appendChild(anchor);
  errorList.appendChild(listItem);
}

Ogni link ha una doppia funzionalità: segnala il tipo di errore e inoltre cliccandoci sopra sposta il focus automaticamente sul campo vuoto da riempire.

Nota: il metodo focus() dell'esempio può creare confusione. Chrome e Edge (e le ultime versioni di IE) sposteranno il focus al campo relativo quando il si clicca sul link, senza bisogno della funzione onclick/focus(). Safari si limiterà a evidenziare il campo, ma ha bisogno di onclick/focus() per spostare effettivamente il focus su di esso. Firefox al momento non è in grado di spostare il focus su un campo specifico, quindi il metodo non funzionerà su Firefox. Il problema dovrebbe essere risolto in futuro.

Inoltre, il messaggio di errore è stato posto in cima nel codice HTML (anche se poi è riposizionato in un altro punto tramite CSS), di modo che l'utente può sapere che errore c'è nel suo formulario e andare al campo in questione tornando in cima alla pagina.

Come annotazione finale, abbiamo usato alcuni attributi WAI-ARIA nel nostro esempio, per aiutare a risolvere problemi di accessibilità causati da aree del contenuto che si aggiornano costantemente senza che la pagina si ricarichi (di default i lettori di schermo non segnaleranno ciò agli utenti):

<div class="errors" role="alert" aria-relevant="all">
  <ul>
  </ul>
</div>

Torneremo a occuparci più dettagliatamente di questo tipo di attributi nel prossimo articolo sulla tecnologia WAI-ARIA (in inglese).

Nota: forse starai pensando che HTML5 include già alcuni meccanismi di validazione come gli attributi required, min/minlength, e max/maxlength. Non abbiamo fatto uso di tali attributi nell'esempio, perchè non presentano ancora un livello accettabile di compatibilità nei differenti browser (per esempio Safari non li supporta, Internet Explorer solo dalla versione 10 in su).

Nota: l'articolo in inglese Forme usabili ed accessibili di validazione di formulari e risoluzione di errori fornisce ulteriori utili informazioni su come creare un processo di validazione acessibile.

Altri problemi di accessibilità con JavaScript

Ci sono altri aspetti relativi all'accessibilità da tenere in conto quando si usa JavaScript. Ne aggiungeremo altri all'articolo in futuro.

Eventi specifici del mouse

Come forse già saprai, le interazioni dell'utente con il sito tramite mouse sono gestite in JavaScript usando i gestori di eventi (event handlers), che ci permettono di eseguire funzioni in risposta a determinati eventi. Alcuni esempi di eventi specificamente relativi al mouse sono mouseover, mouseout, dblclick, ecc. Le funzionalità associate a tali eventi non sono accessibili usando altri dispositivi, come per esempio la tastiera.  

Per attenuare i problemi che ne derivano, dovresti associare a tali eventi altri eventi simili ma che sono attivati in altra maniera (i cosiddetti gestori di eventi indipendenti dal dispositivo). Per esempio focusblur forniscono accessibilità per gli utenti che navigano con la tastiera.

Vediamo ora un esempio che dimostra questo tipo di situazione. Supponiamo che in una nostra pagina ci sia una immagine in miniatura che si espande quando ci si passa il puntatore del mouse sopra o quando riceve focus (per esempio nel catalogo di un sito di e-commerce).

Abbiamo creato un esempio molto semplice, che puoi trovare qui: mouse-and-keyboard-events.html (vedi anche il codice sorgente). Il codice ha due funzionalità che mostrano e nascondono l'immagine ingrandita; qui sotto vediamo il codice dei gestori degli eventi:

imgThumb.onmouseover = showImg;
imgThumb.onmouseout = hideImg;

imgThumb.onfocus = showImg;
imgThumb.onblur = hideImg;

Le prime due linee riguardano il mouse: la prima funzione si attiva al passare il puntatore del mouse sulla miniatura, mentre la seconda si attiva al togliere il puntatore dall'area della miniatura. Questo codice però non permette di vedere l'immagine ingrandita tramite tastiera. Per poterlo fare, abbiamo aggiunto le atre due linee di codice, che attivano le stesse funzioni quando la miniatura riceve focus o lo perde. Si può spostare il focus sulla miniatura usando il tasto TAB, perchè al codice HTML dell'elemento abbiamo incluso l'attributo tabindex="0".

L'evento click è interessante, a prima vista potrebbe sembrare un evento esclusivamente relativo  al mouse, ma nella maggior parte dei browser il gestore di eventi onclick si attiverà anche premendo il tasto INVIO su un link o un elemento di formulario con focus, o quando si clicca sull'elemento con il dito se si usa un dispositivo con touchscreen.

Tieni presente comunque che questo non funziona nel caso in cui usi tabindex per dare il focus a un elemento che di default non lo potrebbe avere. In casi come questo devi rilevare quando il tasto specifico è premuto (vedi Implementare l'accessibilità da tastiera in un secondo tempo).

Riassunto

Speriamo che questo articolo ti sia servito a capire meglio i problemi di accessibilità relativi all'uso di CSS e JavaScript sui tuoi siti.

E ora, WAI-ARIA!

Tag del documento e collaboratori

 Hanno collaborato alla realizzazione di questa pagina: mipo
 Ultima modifica di: mipo,