MDN wants to learn about developers like you: https://qsurvey.mozilla.com/s3/MDN-dev-survey

Learn web development

HTML: una buona base per l'accessibilità

Buona parte del contenuto di un sito può essere reso accessibile semplicemente facendo attenzione ad usare sempre nella maniera corretta gli elementi HTML più opportuni per il proprio scopo. Questo articolo analizza in dettaglio come il linguaggio HTML può essere usato per garantire la massima accessibilità.

Prerequisiti: Conoscimenti basici sull'uso del computer, livello basico di HTML e una idea chiara di cosa è l'accessibilità.
Obiettivo: Acquistare familiarità con le caratteristiche dell'HTML che hanno effetti positivi sull'accessibilità, e imparare a usarle correttamente nello sviluppo dei propri siti. 

HTML e accessibilità

Man mano che impari cose nuove sull'HTML (leggendo nuove risorse, analizzando esempi di codice ecc.), ti accorgerai sicuramente di un tema ricorrente: l'importanza di usare HTML semantico (a volte chiamato POSH, Plain Old Semantic HTML). Ciò significa utilizzare il più possibile gli elementi HTML più corretti per il proprio scopo.

Forse ti chiederai perchè è tanto importante. Dopotutto, puoi usare un combinazione di CSS e JavaScript per far sì che qualsiasi elemento HTML si comporti esattamente come tu vuoi. Per esempio, un bottone che controlla la riproduzione di un video sul tuo sito si potrebbe codificare così:

<div>Play video</div>

Ma come vedrai in dettaglio più avanti, ha molto più senso usare un elemento più specifico:

<button>Play video</button>

Non solo l'elemento <button> presenta di default uno stile più appropriato alla sua funzione (anche se probabilmente in seguito modificherai tale stile), ma è anche perfettamente accessibile con la tastiera. Ciò significa che un utente che usa la tastiera per navigare potrà spostarsi da un bottone all'altro del sito usando il tasto TAB, e premere i bottoni usando INVIO.

L'HTML semantico non richiede più tempo per essere scritto del codice non-semantico se lo utilizzi con consistenza sin dal principio del progetto, e inoltre presenta numerosi altri benefici che vanno al di là dell'accessibilità:

  1. Maggior facilità nello sviluppo — come già detto in precedenza, gli elementi HTML semantici hanno già integrate in sè alcune funzionalità aggiuntive. inoltre rendono il codice più facile da leggere e interpretare.
  2. Miglior rendimento su dispositivi mobili — l'HTML semantico è più leggero del non-semantico, e più facile da rendere responsivo.
  3. Utile per il SEO — i motori di ricerca danno maggior importanza alle parole chiave contenute in heading, link, ecc. rispetto a quelle contenute in generici <div> non-semantici, dunque i tuoi siti saranno più facili da trovare. 

Ora andiamo a vedere più in dettaglio come si compone un codice HTML accessibile.

Nota: È una buona idea installare un lettore di schermo sul tuo computer, così che tu possa testare gli esempi mostrati più avanti. Vedi la guida in inglese Guida ai lettori di schermo per maggiori dettagli.

Buone semantiche

Abbiamo già parlato dell'importanza di usare la giusta semantica, e perchè è importante usare i corretti elementi HTML per ogni situazione. Questa pratica non può essere ignorata, visto che è una delle principali situazioni in cui l'accessibilità viene negata se non si agisce propriamente.

Se si analizzano i siti presenti in rete, si noterà che ci sono casi di utilizzo molto poco ortodosso del codice HTML. Alcuni errori sono dovuti a pratiche ormai in disuso che non sono state debitamente aggiornate, altri semplicemente a ignoranza. In ogni caso, dovresti fare il possibile per sistemare codice erroneo ogni volta che lo trovi.

A volte non sei nella posizione di poter correggere del codice mal scritto, per esempio se le tue pagine si basano su un framework esterno su cui non hai controllo, o se hai contenuto di terze parti sul tuo sito (come ad esempio banners pubblicitari) su cui non hai controllo.

Comunque, tieni a mente che l'obiettivo non è "tutto o niente". Ogni piccolo miglioramento che riuscirai a implementare sarà utile alla causa dell'accessibilità.

Contenuto testuale

Uno dei più grandi aiuti per un utente che usa un lettore di schermo è una buona struttura del contenuto, diviso in headings, paragrafi, liste ecc. Un buon esempio può essere il seguente codice:

<h1>My heading</h1>

<p>This is the first section of my document.</p>

<p>I'll add another paragraph here too.</p>

<ol>
  <li>Here is</li>
  <li>a list for</li>
  <li>you to read</li>
</ol>

<h2>My subheading</h2>

<p>This is the first subsection of my document. I'd love people to be able to find this content!</p>

<h2>My 2nd subheading</h2>

<p>This is the second subsection of my content. I think is more interesting than the last one.</p>

Abbiamo preparato un'altra versione più lunga che puoi provare a leggere con un lettore di schermo (vedi: buone-semantiche.html). Se provi a leggere tale pagina, ti renderai conto che è facile da navigare:

  1. Il lettore di schermo legge ogni etichetta man mano che avanza nella lettura del contenuto, facendoti sapere quale è un heading, quale un paragrafo ecc.
  2. Si ferma dopo ogni elemento, permettendoti di procedere al ritmo di lettura che ti è più comodo.
  3. Nella maggior parte dei lettori di schermo, puoi saltare al precedente/prossimo heading.
  4. Molti lettori di schermo inoltre ti forniscono una lista di tutti gli heading presenti, permettendoti di avere un utile indice per trovare contenuti specifici. 

A volte si scrivono headings e paragrafi usando HTML non-semantico e salti di linea, come nel caso seguente:

<font size="7">My heading</font>
<br><br>
This is the first section of my document.
<br><br>
I'll add another paragraph here too.
<br><br>
1. Here is
<br><br>
2. a list for
<br><br>
3. you to read
<br><br>
<font size="5">My subheading</font>
<br><br>
This is the first subsection of my document. I'd love people to be able to find this content!
<br><br>
<font size="5">My 2nd subheading</font>
<br><br>
This is the second subsection of my content. I think is more interesting than the last one.

Se provi a leggere questa versione con un lettore di schermo (vedi cattive-semantiche.html), non avrai una esperienza positiva. Il lettore di schermo non avrà riferimenti che lo guidino, e non potrà fornirti un sommario dei contenuti. L'intera pagina gli apparirà come un blocco unico, e la leggerà tutta in una volta.

Ci sono inoltre altri problemi che vanno al di là dell'accessibilità: per esempio è difficile applicare stile al contenuto usando CSS. o manipolarlo con JavaScript, perchè non ci sono elementi da usare come selettori.

Usare un linguaggio chiaro

Anche il linguaggio che usi può avere un effetto sull'accessibilità. In generale dovresti usare un linguaggio chiaro e non troppo complesso, privo di termini gergali o eccessivamente tecnici. Ciò non è d'aiuto solo alle persone con disabilità cognitive o di altro tipo; è anche utile ad utenti per i quali il testo è scritto in una lingua che non conoscono bene, a utenti di età molto giovane... Di fatto, è utile a tutti! A parte ciò, dovresti anche fare attenzione a non usare termini e caratteri che risultino poco chiari se letti con un lettore di schermo. Per esempio:

  • Non usare trattini se puoi evitarli. Invece di scrivere "5-7", scrivi "da 5 a 7".
  • Espandi le abbreviazioni: invece di "gen", scrivi "gennaio".
  • Cerca di scrivere la forma completa degli acronimi, almeno la prima volta che li usi. Per esempio quando scrivi "HTML" per la prima volta in una pagina, scrivi "Hypertext Markup Language, o HTML".

Layout di pagina

Molto tempo fa, era pratica abituale creare layout di pagina usando tabelle HTML, usando celle di tabella per contenere header, footer, barra laterale, la colonna del contenuto principale ecc. Questa non è una buona pratica, visto che un lettore di schermo molto probabilmente darà una lettura confusa delle celle, soprattutto se il layout è complesso è presenta sottotabelle secondarie.

Prova questo esempio: table-layout.html, che corrisponde al seguente codice.

<table width="1200">
      <!-- main heading row -->
      <tr id="heading">
        <td colspan="6">

          <h1 align="center">Header</h1>

        </td>
      </tr>
      <!-- nav menu row  -->
      <tr id="nav" bgcolor="#ffffff">
        <td width="200">
          <a href="#" align="center">Home</a>
        </td>
        <td width="200">
          <a href="#" align="center">Our team</a>
        </td>
        <td width="200">
          <a href="#" align="center">Projects</a>
        </td>
        <td width="200">
          <a href="#" align="center">Contact</a>
        </td>
        <td width="300">
          <form width="300">
            <input type="search" name="q" placeholder="Search query" width="300">
          </form>
        </td>
        <td width="100">
          <button width="100">Go!</button>
        </td>
      </tr>
      <!-- spacer row -->
      <tr id="spacer" height="10">
        <td>

        </td>
      </tr>
      <!-- main content and aside row -->
      <tr id="main">
        <td id="content" colspan="4" bgcolor="#ffffff">

          <!-- main content goes here -->
        </td>
        <td id="aside" colspan="2" bgcolor="#ff80ff" valign="top">
          <h2>Related</h2>

          <!-- aside content goes here -->

        </td>
      </tr>
      <!-- spacer row -->
      <tr id="spacer" height="10">
        <td>

        </td>
      </tr>
      <!-- footer row -->
      <tr id="footer" bgcolor="#ffffff">
        <td colspan="6">
          <p>©Copyright 2050 by nobody. All rights reversed.</p>
        </td>
      </tr>
    </table>

Se provi a navigare la pagina con un lettore di schermo, probabilmente ti dirà che c'è una tabella (anche se alcuni lettori di schermo riescono a differenziare i layout a tabella dalle tabelle di dati). Poi dovrai (a seconda del lettore di schermo che stai usando) esplorare la tabella cella per cella, e infine uscirne per poter navigare il contenuto.

I layout a tabella son una reliquia del passato, avevano senso in un'epoca in cui non tutti i browser supportavano CSS, ma creano confusione per gli utenti che usano lettori di schermo, e inoltre sono una cattiva pratica per molte altre ragioni (per esempio richiedono una quantità maggiore di codice e rendono il disegno meno flessibile). Non usarli!

Puoi verificare queste affermazioni comparando le tue esperienze precedenti con un esempio di struttura del sito più moderna, che corrisponde al seguente codice:

<header>
  <h1>Header</h1>
</header>

<nav>
  <!-- main navigation in here -->
</nav>

<!-- Here is our page's main content -->
<main>

  <!-- It contains an article -->
  <article>
    <h2>Article heading</h2>

    <!-- article content in here -->
  </article>

  <aside>
    <h2>Related</h2>

    <!-- aside content in here -->
  </aside>

</main>

<!-- And here is our main footer that is used across all the pages of our website -->

<footer>
  <!-- footer content in here -->
</footer>

Se provi questa nuova versione del sito con un lettore di schermo, vedrai che il layout del codice non è più un ostacolo alla lettura del contenuto. Inoltre puoi notare come sia molto più agile e leggero in termini di quantità di codice, cosa che implica una maggior facilità di gestione e mantenimento, e minor utilizzo di banda da parte dell'utente (molto utile per chi ha una connessione lenta).

Un'altra considerazione quando si creano layout è di usare HTML5 semantico, come visto nell'esempio precedente (vedi il compendio in inglese sezioni del contenuto). Potresti creare un layout usando solo elementi annidati <div>, ma è molto meglio usare elementi specifici appropriati per distinguere le varie sezioni della pagina, come la sezione con gli elementi di navigazione (<nav>), il footer (<footer>), unità di contenuto che si ripetono (<article>), ecc. Questi elementi forniscono un ulteriore contenuto semantico per i lettori di schermo (e per altri strumenti) per dare agli utenti indicazioni extra riguardo il contenuto che stanno navigando (vedi l'articolo in inglese Supporto dei nuovi elementi HTML5 di sezione nei lettori di schermo per farti un'idea dello stato del supporto nei lettori di schermo).

Nota: oltre ad una buona semantica ed un layout esteticamente apprezzabile, il tuo contenuto dovrebbe essere organizzato in un ordine logico. Puoi sempre muoverlo in seguito utilizzando il CSS, ma il codice sorgente dovrebbe essere nel giusto ordine, di modo che gli utenti che usano lettori di schermo lo possano interpretare correttamente. 

Controlli di Interfaccia Utente

Con il termine controlli IU intendiamo le principali parti di un sito con cui gli utenti interagiscono. Le più comuni sono bottoni, link e formulari. In questa sezione analizzeremo gli aspetti basici da tenere in considerazione quando si creano tali elementi. Più avanti gli articoli su WAI-ARIA e multimedia prenderanno in considerazione altri aspetti dell'accessibilità IU.

Un aspetto chiave dell'accessibilità dei controlli IU è che di default i browser permettono di interagire con essi tramite tastiera. Puoi fare una prova usando il nostro esempio accessibilità-tastiera-nativa.html (vedi il codice sorgente): apri la pagina in una nuova scheda e prova a premere il bottone TAB; dopo averlo premuto qualche volta, dovresti vedere il focus muoversi da un elemento all'altro della pagina. Gli elementi con focus hanno un sistema di evidenziazione per rendere chiaro quale elemento è selezionato al momento. Questo sistema varia leggermente da browser a browser.

Puoi premere INVIO per aprire un link o premere un bottone che è evidenziato con focus (nell'esempio i bottoni producono un messaggio di allerta), oppure puoi scrivere in un campo del formulario o selezionare un elemento dal menu a tendina usando i tasti freccia della tastiera.

Nota: i vari browser possono presentare differenti opzioni di controllo da tastiera. Vedi l'articolo in inglese Accessibilità con la tastiera per maggiori dettagli.

In ogni caso tutti  i browser sono già preconfigurati per la navigazione con tastiera, l'unica cosa di cui devi preoccuparti è usare gli elementi HTML correttamente. per esempio:

<h1>Links</h1>

<p>This is a link to <a href="https://www.mozilla.org">Mozilla</a>.</p>

<p>Another link, to the <a href="https://developer.mozilla.org">Mozilla Developer Network</a>.</p>

<h2>Buttons</h2>

<p>
  <button data-message="This is from the first button">Click me!</button>
  <button data-message="This is from the second button">Click me too!</button>
  <button data-message="This is from the third button">And me!</button>
</p>

<h2>Form</h2>

<form>
  <div>
    <label for="name">Fill in your name:</label>
    <input type="text" id="name" name="name">
  </div>
  <div>
    <label for="age">Enter your age:</label>
    <input type="text" id="age" name="age">
  </div>
  <div>
    <label for="mood">Choose your mood:</label>
    <select id="mood" name="mood">
      <option>Happy</option>
      <option>Sad</option>
      <option>Angry</option>
      <option>Worried</option>
    </select>
  </div>
</form>

Questo significa usare link, bottoni, elementi del formulario ed etichette appropriatamente (includendo l'elemento <label> nei campi del formulario).

Purtroppo a volte queste buone pratiche non sono rispettate. Ad esempio, a volte si trovano bottoni codificati usando elementi <div>:

<div data-message="This is from the first button">Click me!</div>
<div data-message="This is from the second button">Click me too!</div>
<div data-message="This is from the third button">And me!</div>

Questa maniera di scrivere codice è altamente sconsigliata: non solo perdi l'accessibilità da tastiera che avresti avuto automaticamente usando l'etichetta <button>, ma perdi anche gli stili CSS di default che l'etichetta <button> contiene.

Implementare l'accessibilità da tastiera in un secondo tempo

Risolvere problemi di accessibilità da tastiera in un sito già creato può richiedere un certo sforzo (per un esempio vedi la pagina  fake-div-buttons.html e il suo  codice sorgente). In questo esempio abbiamo dato ad alcuni bottoni erroneamente creati con una etichetta <div> la possibilità di ricevere focus (anche via tasto TAB), fornendo a ognuno l'attributo tabindex="0":

<div data-message="This is from the first button" tabindex="0">Click me!</div>
<div data-message="This is from the second button" tabindex="0">Click me too!</div>
<div data-message="This is from the third button" tabindex="0">And me!</div>

L'attributo tabindex è stato creato per dare agli elementi selezionabili tramite tasto TAB un ordine di focus personalizzato (specificato con numeri positivi in ordine crescente), differente dall'ordine standard con cui sono stati creati. In generale questa non è una buona pratica, e può causare confusione nell'utente. Sarebbe da usare solo in casi particolari, per esempio se il layout mostra gli elementi in una forma molto diversa dal codice sorgente. Ma ci sono due altri utilizzi di tabindex che sono utili per l'accessibilità:

  • tabindex="0" — come mostrato nell'esempio sopra, attribuire un valore di tabindex="0" a un elemento HTML lo rende "tabbabile", ossia da la possibilità di selezionarlo tramite tasto TAB.  Questo è l'utilizzo più utile di tabindex.
  • tabindex="-1" — questo valore, di per sè nullo, da la possibilità di far sì che un elemento riceva focus programmaticamente, per esempio tramite JavaScript o come destinazione di un link. 

L'uso di tabindex rende i bottoni selezionabili tramite tasto TAB, ma non ci permette di cliccarli usando INVIO. Per renderli cliccabili, dobbiamo ricorrere a Javascript:  

document.onkeydown = function(e) {
  if(e.keyCode === 13) { // The Enter/Return key
    document.activeElement.onclick(e);
  }
};

Spiegazione del codice: abbiamo aggiunto un listener al documento, di modo che il codice rileva ogni volta che un tasto della tastiera viene premuto. Tramite la proprietà KeyCode il codice individua quale tasto è stato premuto. Se il codice del tasto corrisponde a quello del tasto INVIO, la funzione legata all'onclick del bottone attualmente selezionato viene eseguita. usando document.activeElement.onclick(). activeElement serve proprio a rilevare l'elemento che attualmente sta ricevendo focus nella pagina, in questo caso il bottone che abbiamo selezionato tramite tasto TAB. 

Nota: Tieni presente che questa tecnica funzionerà solo se usi onclick. Usare addEventListener non funzionerà.

Come vedi, implementare l'uso della tastiera in un secondo momento non è un lavoro semplice né veloce, e inoltre può causare malfunzionamenti del sito. È molto meglio utilizzare l'elemento più appropriato per ogni funzionalità del sito sin dal principio.

Usare testi con significato

Una interfaccia utente con nomenclatura chiara ed esplicativa è utile a tutti, ma avere testi ed etichette curati nei dettagli è particolarmente importante per gli utenti con disabilità.

Assicurati che i tuoi bottoni e i tuoi link presentino testi facilmente comprensibili e che distinguano bene un elemento dall'altro. Non usare frasi come "Clicca qui", perchè gli utenti che usano lettori di schermo possono avere difficoltà a distinguere la funzione o destinazione del bottone o link, soprattutto se ce ne sono molti nella pagina. La seguente immagine mostra alcuni campi di un formulario così come sono letti da VoiceOver.

Assicurati che i nomi che assegni agli elementi abbiano senso anche fuori dal loro contesto, letti separatamente, allo stesso modo in cui hanno senso nel contesto del paragrafo in cui sono contenuti. Il seguente esempio mostra un uso corretto del testo in un link:

<p>Le balene sono creature davvero straordinarie. <a href="balene.html">Scopri di più sulle balene</a>.</p>

mentre questo è un esempio di cattivo uso:

<p>Le balene sono creature davvero straordinarie. Per saperne di più sulle balene, <a href="balene.html">clicca qui</a>.</p>

Nota: Puoi saperne di più sulle migliori pratiche di implementazione di link nel nostro articolo (in inglese) Creazione di link. Puoi inoltre vedere esempi di buona costruzione di link nella pagina buoni-link.html ed esempi di link mal costruiti nella pagina cattivi-link.html.

Un altro elemento importante sono le etichette <label> dei formulari, che forniscono una indicazione su cosa l'utente deve inserire nel campo del formulario. Il seguente esempio può sembrare una maniera corretta di implementare un campo di formulario:

Scrivi il tuo nome: <input type="text" id="nome" name="nome">

Tutavia, questo campo non sarebbe utile a utenti con disabilità visiva. Non c'è nessuna indicazione non visuale che associ chiaramente il campo di input con il testo "Scrivi il tuo nome:". Se navighi questo elemento con un lettore di schermo, potresti ricevere una descrizione generica tipo "scrivi testo qui".

Il seguente è un esempio molto migliore:

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

Con questo codice, il testo sarà chiaramente associato al campo di input; il lettore pronuncerà una frase come: "Scrivi il tuo nome: scrivi testo qui". 

Inoltre, nella maggior parte dei browser associare un testo a un campo di input tramite etichetta <etichetta> permette di selezionare/attivare il campo input cliccando anche sul testo oltre che sul campo stesso. Ciò rende molto più facile selezionare il campo in cui scrivere.

Nota: Puoi vedere esempi positivi di form nella pagina esempi-di-buoni-form.html ed esempi negativi nella pagina esempi-di-cattivi-form.html.

Tabelle dati accessibili

Una tabella dati basica si può scrivere in modo molto semplice, come per esempio:

<table>
  <tr>
    <td>Name</td>
    <td>Age</td>
    <td>Gender</td>
  </tr>
  <tr>
    <td>Gabriel</td>
    <td>13</td>
    <td>Male</td>
  </tr>
  <tr>
    <td>Elva</td>
    <td>8</td>
    <td>Female</td>
  </tr>
  <tr>
    <td>Freida</td>
    <td>5</td>
    <td>Female</td>
  </tr>
</table>

Ma questo codice può dare problemi: non da agli utenti che usano lettori di schermo la possibilità di associare file e colonne in gruppi di dati relazionati tra loro. Per rendere ciò possibile devi sapere quali elementi della tabella sono header di file o colonne. Nel caso della tabella qui sopra ciò è possibile solo visualizzandola (vedi tabella-incorretta.html).

Ora invece considera l'esempio tabella gruppi punk. Puoi notare alcune aggiunte nel codice che migliorano l'accessibilità:

  • Gli header della tabella sono stati definiti usando elementi <th>. Inoltre è stato specificato se sono header di file o colonne, tramite l'uso dell'attributo scope. Questo procedimento permette al lettore di schermo di rilevare gruppi di dati separati e leggerli come contenuto specifico di una fila o colonna.
  • L'elemento <caption> e l'attributo <table> summary hanno funzioni simili, si possono definire un testo alternativo per tabelle, come l'alt text delle immagini, utile per fornire all'utente che usa lettore di schermo un sommario del contenuto della tabella. In genere è preferibile usare <caption>, perchè è utilizzabile anche da utenti che non navigano con lettore di schermo. Ad ogni modo non è necessario usare entrambi. 

Nota: vedi l'articolo in inglese Caratteristiche avanzate delle tabelle HTML e accessibilità per maggiori dettagli sull'accessibilità delle tabelle dati.

Alternative testuali

Mentre il contenuto testuale è per natura accessibile, non si può dire lo stesso per il contenuto multimediale: immagini e video non possono essere visualizzati da persone con disabilità visiva, e il contenuto audio non può essere ascoltato da persone con disabilità auditiva. Ci occuperemo del contenuto video e audio in un altro articolo, qui vogliamo trattare il tema dell'accessibilità per gli elementi  <img>.

Proponiamo qui un semplice esempio, immagine-accessibile.html, nel quale possiamo vedere 4 copie della stessa immagine.

Riportiamo qui sotto il relativo codice HTML tradotto all'italiano (nella pagina del link sarà in inglese):

<img src="dinosauro.png">

<img src="dinosauro.png"
     alt="Un Tirannosauro Rex: un dinosauro bipede che sta in piedi come un umano, con braccia piccole e una grande testa con denti aguzzi.">

<img src="dinosauro.png"
     alt="Un Tirannosauro Rex: un dinosauro bipede che sta in piedi come un umano, con braccia piccole e una grande testa con denti aguzzi."
     title="Il dinosauro rosso di Mozilla">


<img src="dinosauro.png" aria-labelledby="dino-label">

<p id="dino-label">Il Tirannosauro Rex rosso di Mozilla: un dinosauro bipede che sta in piedi come un umano, con braccia piccole e una grande testa con denti aguzzi.</p>

La prima immagine, se si usa un lettore di schermo, non è molto d'aiuto all'utente. Per esempio VoiceOver leggerebbe il nome del file "dinosauro.png, immagine". L'utente saprebbe almeno che nell'immagine è rappresentato un dinosauro di qualche tipo. Ma spesso le immagini che si trovano in internet non hanno neanche un titolo minimamente descrittivo, ma codici o nomi generati automaticamente (per esempio da una macchina fotografica), che non forniscono alcun tipo di contesto riguardo il contenuto dell'immagine.

Nota: non dovresti mai includere contenuto testuale in una immagine. I lettori di schermo non lo possono leggere. Ci sono inoltre altri svantaggi, per esempio non è possibile selezionarlo e copiarlo. Non farlo! 

Nel caso della seconda immagine, un lettore di schermo leggerà tutto l'attributo alt: "Un Tirannosauro Rex: un dinosauro bipede che sta in piedi come un umano, con braccia piccole e una grande testa con denti aguzzi.".

Dunque è importante fornire alle immagini nomi descrittivi, e anche assicurarsi di fornire testo alternativo ogni volta che è possibile. Fai attenzione a fornire nell'attributo alt un testo che sia una rappresentazione il più possible diretta del contenuto dell'immagine. Evita di includere informazioni extra che non riguardano direttamente l'immagine.

Un altro aspetto da considerare è se un'immagine ha un significato importante nel contesto del tuo contenuto, o se si tratta solo di un'immagine decorativa. Se sono solo immagini decorative, è meglio includerle nella pagina con la proprietà background-image di CSS.

Nota: Leggi Immagini in HTML e Immagini reattive per saperne di più sulle pratiche ottimali per l'implementazione delle immagini.

Se desideri fornire informazioni contestuali extra, dovresti metterle nel testo vicino all'immagine, o dentro un attributo title, come mostrato nel codice della terza immagine. La maggior parte dei lettori di schermo leggerà il testo alternativo, il testo dell'attributo title, e il nome del file. Inoltre, i browser mostreranno il testo del title quando un utente passa sopra l'immagine con il puntatore del mouse.

Diamo ora un'occhiata al codice della quarta immagine:

<img src="dinosauro.png" aria-labelledby="dino-label"> <p id="dino-label">Il Tirannosauro...</p>

In questo caso non stiamo usando l'attributo alt. Invece, abbiamo presentato la descrizione dell'immagine come un normale paragrafo, le abbiamo assegnato un id, e poi abbiamo usato l'atributo aria-labelledby  associandolo all' id. In questo modoi lettori di schermo useranno il paragrafo come testo alternativo per l'immagine. Questo viene utile nel caso in cui tu voglia usare lo stesso testo alternativo per multiple, cosa che è sconsigliabile fare usando alt.

Nota: aria-labelledby è parte della specificazione WAI-ARIA, che permette agli sviluppatori di aggiungere valore semantico extra al loro codice e migliorare l'accessiblità per i lettori di schermo, Per saperne di più su come funziona, leggi l'articolo in inglese basi di WAI-ARIA.

Altri metodi di testo alternativo

Ci sono anche altri metodi per associare alle immagini un testo che le descriva. Per esempio, c'è un attributo chiamato longdesc che permette di richiamare descrizioni dettagliate delle immagini presenti in una pagina da un documento HTML esterno. Per esempio:

<img src="dinosauro.png" longdesc="dino-info.html">

Questa può sembrare una soluzione ottimale, soprattutto per immagini con grandi contenuti informativi come grafici che rappresentano statistiche o risultati. Ma purtroppo, l'attributo longdesc  non è supportato con consistenza dai lettori di schermo, e inoltre il suo contenuto è totalemten inaccessibile agli utenti che non usano lettori di schermo. Si raccomanda dunque di includere la descrizione testuale nella stessa pagina in cui si trova l'immagine, o rimandare alla descrizione con un link standard.

In HTML5 sono inclusi inoltre altri due elementi, <figure> e <figcaption>, che servono ad associare un elemento figura (non necessariamente un'immagine) con una didascalia: 

<figure>
  <img src="dinosauro.png" alt="Il Tirannosauro di Mozilla">
  <figcaption>Un Tirannosauro Rex: un dinosauro bipede che sta in piedi come un umano, con braccia piccole e una grande testa con denti aguzzi.</figcaption>
</figure>

Purtroppo anche in questo caso la maggior parte dei lettori di schermo non è ancora in grado di interpretare correttamente gli elementi <figure> e <figcaption>, ma l'uso di questi elementi può essere comunque utile per effettuare modifiche allo stile tramite CSS, inoltre danno la possibilità di collocare la descrizione di una immagine nello stesso punto in cui l'immagine è inserita nel codice.

Attributi alt vuoti

<h3>
  <img src="icona-articolo.png" alt="">
  Tirannosauro Rex: il re dei dinosauti 
</h3>

In alcuni casi un'immagine viene incliusa in una pagina con uno scopo puramente decorativo. Come puoi notare nel codice qui sopra, l'attributo alt dell'immagine è lasciato vuoto. Questo procedimento permette ai lettori di schermo di riconoscere la presenza di un'immagine, evitando però di fornirne una descrizione (pronuncerebbero solo una frase come "immagine").

La ragione per cui è buona pratica usare un attributo alt vuoto invece di non includerlo del tutto è perchè molti lettori di schermo, nel caso in cui non incontrino nessun attributo alt associato a un'immagine, leggono al suo posto l'URL dell'immagine. Nell'esempio qui sopra, l'immagine ha una funzione decorativa dell'heading a cui è associata. In casi come questo, e in tutti i casi in cui un'immagine ha funzione decorativa e nessun valore di contenuto, dovresti associarle un attributo alt vuoto (alt=""). Un'alternativa è usare l'attributo ARIA role (con forma: role="presentation"), che indica ai lettori di schermo di non leggere il testo alternativo.

Nota: se possibile è meglio usare CSS per mostrare immagini con funzione puramente decorativa.

Riassunto

Dopo aver letto questo articolo dovresti avere una idea piuttosto chiara di come scrivere HTML accessibile nella maggior parte delle situazioni. Il nostro articolo su WAI-ARIA ti darà informazioni più approfondite, ma con quanto hai già letto e imparato sei in possesso di una buona base. Nei prossimi articoli esploreremo CSS e JavaScript, e come l'accessibilità è influenzata dal loro corretto o incorretto utilizzo.

Tag del documento e collaboratori

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