From 95aca4b4d8fa62815d4bd412fff1a364f842814a Mon Sep 17 00:00:00 2001 From: Ryan Johnson Date: Thu, 29 Apr 2021 16:16:42 -0700 Subject: remove retired locales (#699) --- .../learn/accessibility/wai-aria_basics/index.html | 423 --------------------- 1 file changed, 423 deletions(-) delete mode 100644 files/it/learn/accessibility/wai-aria_basics/index.html (limited to 'files/it/learn/accessibility/wai-aria_basics') diff --git a/files/it/learn/accessibility/wai-aria_basics/index.html b/files/it/learn/accessibility/wai-aria_basics/index.html deleted file mode 100644 index 05a7ea4b5f..0000000000 --- a/files/it/learn/accessibility/wai-aria_basics/index.html +++ /dev/null @@ -1,423 +0,0 @@ ---- -title: Basi della tecnologia WAI-ARIA -slug: Learn/Accessibility/WAI-ARIA_basics -tags: - - ARIA - - Accessibilità - - Articolo - - Guida - - HTML - - HTML semantico - - JavaScript - - Principiante - - WAI-ARIA -translation_of: Learn/Accessibility/WAI-ARIA_basics -original_slug: Learn/Accessibilità/WAI-ARIA_basics ---- -
{{LearnSidebar}}
- -
{{PreviousMenuNext("Learn/Accessibilità/CSS_e_JavaScript_accessibilità","Learn/Accessibilità/Multimedia", "Learn/Accessibilità")}}
- -

Proseguendo i temi trattati nell'articolo precedente, può risultare complicato creare elementi di interfaccia utente accessibili quando gli stessi si basano su HTML non semantico e presentano contenuto aggiornato dinamicamente tramite JavaScript. La tecnologia WAI-ARIA può essere d'aiuto aggiungendo valore semantico addizionale, che i browser e le tecnologie assistive possono riconoscere e utilizzare per permettere agli utenti di decifrare più chiaramente il contesto e ciò che sta accadendo durante la navigazione del sito. In questo articolo vedremo come usare questa tecnologia a un livello basico per migliorare l'accessibilità.

- - - - - - - - - - - - -
Prerequisiti:Conoscimenti basici sull'uso del computer, livello basico di HTML, CSS e JavaScript, aver letto i precedenti articoli del corso.
Obiettivo:Acquisire familiarità con la tecnologia WAI-ARIA e imparare a usarla dove necessario per fornire valore semantico addizionale che migliori l'accessibilità.
- -

Cosa è WAI-ARIA?

- -

Cominciamo col dare un'occhiata a cosa è WAI-ARIA, e in che modo ci può essere utile.

- -

Un nuovo set di problemi

- -

Man mano che le applicazioni web cominciarono ad essere sempre più complesse e dinamiche, nuovi problemi di accessibilità iniziarono a manifestarsi.

- -

Per esempio, HTML5 ha introdotto alcuni elementi semantici per definire componenti di uso comune nelle pagine ({{htmlelement("nav")}}, {{htmlelement("footer")}}, ecc.). Prima dell'arrivo di questi elementi, gli sviluppatori si limitavano a usare {{htmlelement("div")}} con ID o classi, per esempio <div class="nav">. Ma questi elementi erano problematici, perchè non fornivano un sistema standard per individuare programmaticamente i componenti di una pagina, dunque i lettori di schermo non potevano distinguere chiaramente le varie sezioni da cui la pagina era composta. 

- -

La soluzione inizialmente consisteva nell’aggiungere uno o più link nascosti nella parte alta della pagina. Tali link reindirizzavano alle varie sezioni della pagina, come per esempio la barra di navigazione:

- -
<a href="#hidden" class="hidden">Vai alla barra di navigazione</a>
- -

 

- -

Ma questo sistema non è molto preciso, e può essere usato solo quando il lettore di schermo comincia a leggere dalla parte alta della pagina.

- -

Per fare un altro esempio, ad un certo punto le applicazioni cominciarono a includere controlli complessi come selezionatori di data o slider per selezionare valori. HTML5 mette a disposizione alcuni tipi speciali di input nativi, specifici per tali controlli:

- -
<input type="date">
-<input type="range">
- -

Ma questi elementi non sono supportati da tutti i browser, ed inoltre sono molto difficili da personalizzare, rendendoli complicati da integrare nel disegno di un sito. Di conseguenza, gli sviluppatori spesso fanno uso di librerie JavaScript e creano tali controlli come una serie di {{htmlelement("div")}} annidati o elementi di una tabella a cui assegnano classi, e in seguito li personalizzano con CSS e li controllano con funzioni di JavaScript.

- -

Il problema di questo metodo è che i lettori di schermo non riescono ad interpretare di cosa si tratta, e riportano solo la presenza di una serie di elementi dei quali non possono descrivere la funzione.

- -

E arrivò WAI-ARIA

- -

WAI-ARIA è una specifica, cioè una raccolta di indicazioni, prodotta dal W3C, che definisce una serie di attributi HTML addizionali che possono essere applicati agli elementi per fornire maggior valore semantico e migliorare l'accessibilità dovunque sia necessario. Ci sono tre caratteristiche principali definite nella raccolta:  

- - - -

Un punto importante da tenere in considerazione riguardo gli attributi WAI-ARIA è che non influiscono in alcun modo sulla pagina, eccetto che sulle informazioni fornite dalla API di accessibilità del browser (dalla quale i lettori di schermo prendono le informazioni). WAI-ARIA non cambia la struttura della pagina, il DOM o altro, anche se i suoi attributi possono essere utili per selezionare gli elementi in CSS.

- -
-

Nota: puoi trovare una utile lista di tutti i ruoli ARIA e i loro usi, con link a informazioni più approfondite, nella specifica WAI-ARIA: vedi Definizione di Ruoli (in inglese).

- -

La specifica contiene anche una lista delle proprietà e degli stati, con link ad ulteriori informazioni. Vedi  Definizioni di Stati e Proprietà (in inglese).

-
- -

Dove è supportata WAI-ARIA?

- -

A questa domanda non è facile rispondere. È difficile trovare  una risorsa che indichi in maniera completa quali funzionalità di WAI-ARIA sono supportate e dove, perchè:

- -
    -
  1. Ci sono molte funzionalità nella specifica WAI-ARIA.
    2. -
  2. Ci sono moltissime combinazioni possibili di sistemi operativi, browser e lettori di schermo.
    3. -
- -

L'ultimo punto è fondamentale: per poter usare un lettore di schermo il tuo sistema operativo deve avere installato almeno un browser con la necessaria API di accessibilità, che fornisca ai lettori di schermo le informazioni necessarie perchè funzionino. La maggior parte dei sistemi operativi ha di serie uno o due browser che funzionano con i lettori di schermo. Sul sito di Paciello Group si può trovare una guida aggiornata costantemente che fornisce dati sul supporto dei lettori di schermo nei vari sistemi operativi. Vedi l'articolo (in inglese) Guida: browser, sistemi operativi e supporto per i lettori di schermo.

- -

Il seguente passo è assicurarsi che i browser usati supportino la tecnologia ARIA e la trasmettano tramite le loro API, ma anche che i lettori di schermo riconoscano le informazioni che ricevono e le presentino agli utenti in una forma ottimale.

- -
    -
  1. Il supporto dei browser in generale è molto buono. Al momento della stesura di questo articolo, il sito caniuse.com riporta un livello globale di supporto di WAI-ARIA nei vari browser di circa l'88%.
    2. -
  2. Il supporto di ARIA nei lettori di schermo non è al momento a un livello comparabile, ma i lettori di schermo più popolari stanno facendo grandi sforzi per migliorare la compatibilità con WAI-ARIA.  Puoi farti un'idea del livello di supporto leggendo l'articolo (in inglese) Compatibilità dei lettori di schermo con WAI-ARIA .
    3. -
- -

In questo articolo non spiegheremo tutte le funzionalità di WAI-ARIA e i dettagli sul supporto che hanno. Cercheremo invece di presentare le funzionalità più importanti e utili agli sviluppatori web; in generale se non facciamo riferimento al livello di supporto di una funzionalità, puoi considerare che il supporto è ragionevolmente buono. In caso di eccezioni lo indicheremo esplicitamente.

- -
-

Nota: alcune librerie JavaScript supportano WAI-ARIA. Ciò significa che quando generano elementi IU, come per esempio formulari complessi, aggiungono automaticamente attributi ARIA per migliorarne l'accessibilità. Se stai valutando l'utilizzo di una libreria Javascript per sviluppare elementi IU più rapidamente, dovresti tenere in conto il livello di accessibilità della libreria quando scegli quale usare. Buoni esempi sono jQuery UI (vedi l'articolo in inglese jQuery UI: supporto all'accessibilità), ExtJS, e Dojo/Dijit.

-
- -

Quando dovresti usare WAI-ARIA?

- -

Abbiamo già discusso di alcuni dei problemi che hanno spinto alla creazione di WAI-ARIA, dovuti soprattutto alla crescente complessità delle moderne applicazioni web. Essenzialmente ci sono 4 grandi aree in cui WAI-ARIA è utile: 

- -
    -
  1. Indicatori/riferimenti: gli attributi role possono funzionare come descrizioni che fanno riferimento a elementi HTML5 replicandone il valore semantico (per esempio {{htmlelement("nav")}}), oppure possono andare oltre HTML5, e funzionare come indicatori che descrivono differenti aree funzionali, per esempio search, tabgroup, tab, listbox, ecc.
    2. -
  2. Aggiornamento dinamico del contenuto: i lettori di schermo in generale hanno difficoltà a indicare quando il contenuto subisce cambiamenti; con ARIA possiamo usare aria-live per indicare agli utenti che usano lettori di schermo quando un' area del contenuto viene aggiornata, per esempio tramite XMLHttpRequest, o DOM APIs .
    3. -
  3. Migliorare l'accessibilità da tastiera: ci sono elementi HTML che hanno accessibilità da tastiera nativa; quando però invece di usare tali elementi se ne usano altri che li "simulano" in combinazione con JavaScript, l'accessibilità da tastiera e la qualità di lettura dei lettori di schermo ne risentono. In questi casi possiamo usare WAI-ARIA per dare focus a tali elementi  (usando tabindex).
    4. -
  4. Accessibilità dei controlli non semantici: quando si usano una serie di <div> annidati in combinazione con CSS e JavaScript per creare una funzionalità IU particolarmente complessa, oppure quando un controllo nativo viene notevolmente modificato tramite JavaScript, l'accessibilità può risultare danneggiata. Gli utenti che usano lettori di schermo troveranno difficile capire come funzionano tali elementi se non ci sono indicazioni semantiche che lo spieghino. In situazioni come queste la tecnologia ARIA può aiutare a fornire le indicazioni necessarie tramite una combinazione di ruoli come button, listbox, o tabgroup, e proprietà come aria-required o aria-posinset.
    5. -
- -

Ricorda: dovresti ricorrere a WAI-ARIA solo quando è necessario! Idealmente, dovresti usare sempre funzionalità HTML native per fornire le indicazioni semantiche necessarie ai lettori di schermo per interpretare correttamente il contesto. A volte però ciò non è possibile, forse perchè non hai pieno controllo sul codice, o perchè stai creando qualcosa di particolarmente complesso, che non puoi implementare con un elemento HTML standard. In tali casi, WAI-ARIA può essere un utile strumento di miglioramento dell'accessibilità. 

- -

Ma ricorda, usala solo quando è necessario!

- -
-

Nota: cerca di testare il tuo sito con la maggior varietà possibile di utenti reali: persone non disabili, persone che usano lettori di schermo, persone che navigano con la tastiera, ecc. Queste persone sapranno indicarti cosa funziona e cosa no in maniera molto più accurata di ciò che può emergere se ti limiti ad effettuare test di utilizzo in prima persona.

-
- -

Esempi di uso pratico di WAI-ARIA 

- -

Nella prossima sezione analizzeremo le 4 aree di utilizzo di WAI-ARIA più dettagliatamente, e forniremo alcuni esempi pratici. Prima di continuare però, dovresti attivare un lettore di schermo, per poter testare alcuni degli esempi.

- -

Vedi la sezione (in inglese) sul testing con lettori di schermo per maggiori informazioni.

- -

Indicatori/riferimenti

- -

WAI-ARIA trasmette ai browser l'attributo role, che permette di aggiungere valore semantico extra agli elementi del tuo sito dovunque sia necessario. La principale utilità di questo attributo è che permette agli utenti che usano lettori di schermo di individuare più facilmente gli elementi più comuni delle pagine. Vediamo un esempio:  il nostro sito senza attributi role (vedi la versione live) ha la seguente struttura:

- -
<header>
-  <h1>...</h1>
-  <nav>
-    <ul>...</ul>
-    <form>
-      <!-- search form  -->
-    </form>
-  </nav>
-</header>
-
-<main>
-  <article>...</article>
-  <aside>...</aside>
-</main>
-
-<footer>...</footer>
- -

Se provi a navigare il sito con un lettore di schermo in un browser moderno, riceverai diverse informazioni utili. Per esempio, VoiceOver fornisce le seguenti indicazioni:

- - - -

Se ti rechi nella sezione Rotore di VoiceOver (premendo VO-U), vedrai che la maggior parte degli elementi più importanti sono elencati ordinatamente e si può accedere ad essi rapidamente.

- -

- -

Ma in realtà, la situazione è migliorabile. Il campo di ricerca è un punto di riferimento importante che gli utenti vorranno trovare, ma non compare nella lista degli elementi e non è trattato come un elemento di riferimento, a parte l'indicazione che si tratta di una casella di ricerca (<input type="search">). Inoltre, alcuni browser più vecchi (per esempio IE8), non riconoscono le indicazioni semantiche degli elementi HTML5. 

- -

Possiamo migliorare il tutto usando alcune funzionalità ARIA. Per prima cosa aggiungiamo alcuni attributi role alla nostra struttura HTML. Il nostro  esempio di sito con ruoli aria (vedi la versione live) ha la seguente struttura:

- -
<header>
-  <h1>...</h1>
-  <nav role="navigation">
-    <ul>...</ul>
-    <form role="search">
-      <!-- search form  -->
-    </form>
-  </nav>
-</header>
-
-<main>
-  <article role="article">...</article>
-  <aside role="complementary">...</aside>
-</main>
-
-<footer>...</footer>
- -

C'è anche una funzionalità bonus in questo esempio: all'elemento {{htmlelement("input")}} è stato assegnato l'attributo aria-label, che fornisce ai lettori di schermo un’etichetta descrittiva, anche se non abbiamo incluso un elemento {{htmlelement("label")}}. In casi come questo è molto utile usare l’attributo ARIA. Un campo di ricerca è infatti un elemento molto comune e facilmente riconoscibile, e aggiungere una etichetta visuale potrebbe danneggiare il disegno della pagina.

- -
<input type="search" name="q" placeholder="Scrivi qui ciò che vuoi cercare" aria-label="Campo per cercare nel contenuto del sito">
- -

Se ora usiamo VoiceOver per navigare il sito d'esempio, notiamo alcuni miglioramenti:

- - - -

Inoltre, il sito è ora maggiormente accessibile per utenti che navigano con browser antiquati come IE8; vale la pena includere ruoli ARIA anche per questo. E se per caso il tuo sito è stato costruito usando solo elementi <div>, dovresti decisamente includere i ruoli ARIA per fornire le necessarie semantiche!

- -

Il valore semantico migliorato del campo di ricerca ha mostrato cosa è possibile fare quando ARIA va oltre le semantiche disponibili con HTML5. Potrai sapere molto di più sulle semantiche e il potere delle proprietà/attributi ARIA qui sotto, specialmente nella sezione {{anch("Accessibilità dei controlli non semantici")}}. Per ora, vediamo come ARIA ci può aiutare a gestire gli aggiornamenti del contenuto dinamico.

- -

Aggiornamenti del contenuto dinamico

- -

In generale tutto il contenuto caricato nel DOM può essere facilmente interpretato usando un lettore di schermo, dal contenuto testuale fino al testo alternativo delle immagini. I tradizionali siti statici con contenuto largamente testuale sono dunque facili da rendere accessibili alle persone con deficit visivo.

- -

Il problema è che le applicazioni web moderne spesso non sono composte da testo statico, di solito hanno una gran quantità di contenuto che si aggiorna dinamicamente, cioè contenuto che si agigorna senza che l'intera pagina si ricarichi, tramite meccanismi come XMLHttpRequest, Fetch, o DOM APIs. Queste aree del contenuto sono talvolta chiamate “aree vive”, o  live regions.

- -

Consideriamo un esempio: aria-no-live.html (vedi anche la versione live). In questo esempio troviamo un paragrafo contenente una citazione selezionata casualmente:

- -
<section>
-  <h1>Citazione casuale</h1>
-  <blockquote>
-    <p></p>
-  </blockquote>
-</section>
- -

JavaScript riceve tramite XMLHttpRequest un file JSON contenente una serie di citazioni con il rispettivo autore. Dopo che la prima citazone tratta dal file è stata caricata nel paragrafo si attiva un loop setInterval() che carica una nuova citazione nel paragrafo ogni 10 secondi:

- -
var intervalID = window.setInterval(showQuote, 10000);
- -

Questo sistema funziona correttamente , ma non è ottimale in termini di accessibilità. Gli aggiornamenti del contenuto non sono rilevati dai lettori di schermo, e gli utenti che li usano non possono rendersi conto di ciò che sta succedendo. Questo esempio è molto basico, ma prova a immaginare cosa succederebbe se stessi creando una interfaccia utente più complessa, con molte aree del contenutto che si aggiornano costantemente, come una chat room, un gioco strategico o magari un sito di e-commerce con un carrello della spesa che si aggiorna con i prodotti selezionati dall'utente. Sarebbe impossibile utilizzare l'applicazione con un lettore di schermo, in assenza di un sistema che avverta gli utenti degli aggiornamenti del contenuto.

- -

Fortunatamente WAI-ARIA ci mette a disposizione un utile meccanismo per fornire tali avvertimenti, la proprietà aria-live. Applicarla a un elemento fa sì che i lettori di schermo leggano il contenuto che viene aggiornato. Con quanta frequenza il contenuto viene letto dipende dal valore assegnato:

- - - -

Generalmente, assegnare il valore assertive è sufficiente perchè gli aggiornamenti vengano annunciati in tempo reale, anche se nel caso di aggiornamenti di multiple aree di contenuto che avvengono allo stesso tempo i vari aggiornamenti saranno annunciati in sequenza, quindi con la possibilità di un breve ritardo sul tempo reale. Si raccomanda di usare rude solo per aggiornamenti ad alta priorità che devono "passare davanti" agli altri aggiornamenti in corso.

- -

Prova a realizzare una copia di aria-no-live.html e quotes.json, e modificare l'etichetta <section> così:

- -
<section aria-live="assertive">
- -

D'ora in poi il lettore di schermo leggerà il contenuto ogni volta che quest'ultimo sarà aggiornato.

- -
-

Nota: : la maggior parte dei browser attiverà una security exception se provi ad effettuare un XMLHttpRequest da un URL file://. Per esempio se carichi il file direttamente nel browser (facendo doppio click). Per farlo funzionare, devi caricare il file a un server, per esempio usando GitHub (articolo in inglese), o un server locale come Python's SimpleHTTPServer (articolo in inglese).

-
- -

C'è però una considerazione da tenere in conto: il lettore di schermo legge solo la parte del testo che viene aggiornata. È utile dunque che legga anche l'heading, per aiutare l'utente a ricordare quale sezione della pagina è stata aggiornata. Per farlo, possiamo aggiungere la proprietà aria-atomic alla sezione. Modifica la tua etichetta <section> così:

- -
<section aria-live="assertive" aria-atomic="true">
- -

L'attributo aria-atomic="true" indica al lettore di schermo che deve leggere l'intero contenuto dell'elemento, non solo le parti che sono state aggiornate.  

- -
-

Nota: : puoi vedere l'esempio completo qui: aria-live.html (vedi anche la versione live).

-
- -
-

Nota: : la proprietà aria-relevant è utile per controllare cosa viene letto quando un'area di contenuto viene aggiornata. Per esempio puoi far si che siano lette solo le parti aggiunte o al contrario le parti rimosse dal contenuto.

-
- -

Migliorare l'accessibilità da tastiera

- -

Come abbiamo già detto in altri articoli di questo modulo, uno dei punti forti di HTML in termini di accessibilità è che implementa automaticamente l'accessibilità da tastiera per funzionalità come i bottoni, i campi dei formulari e i link. In generale, puoi sempre usare il tasto TAB per muoverti da un elemento all'altro e il tasto INVIO per selezionare o attivare gli elementi. In alcune circostanze puoi anche usare altri tasti (per esempio le frecce, per muoverti su e giù tra le opzioni di una lista <select>).

- -

Ciononostante, a volte ti troverai a dover scrivere codice che fa uso di elementi non semantici che compiono la funzione di bottoni (o altri tipi di elementi), o codice che usa elementi che possono ricevere focus per scopi diversi dal normale. Forse starai cercando di sistemare del codice mal scritto in precedenza, o di costruire un qualche tipo di widget complesso che richiede tecniche non ortodosse.

- -

Per rendere focalizzabili elementi che normalmente non lo sono, WAI-ARIA estende l'attributo tabindex con alcuni nuovi valori:

- - - -

Abbiamo discusso questi valori in maggior dettaglio e mostrato una implementazione tipica nel nostro articolo sull'accessibilità in HTML, vedi Implementare l'accessibilità da tastiera in un secondo tempo.

- -

Accessibilità dei controlli non semantici

- -

Proseguendo con il tema trattato nella sezione precedente, quando si usa una serie di <div> annidati in congiunto con CSS o JavaScript per creare una funzionalità complessa per l’interfaccia utente, o se si cambia/migliora sostanzialmente un controllo nativo tramite JavaScript, non solo è possibile che l’accessibilità da tastiera ne risulti ridotta, ma anche per gli utenti che usano lettori di schermo potrebbero prodursi difficoltà a comprendere l’uso della funzionalità, se non ci sono indicazioni semantiche o altri indizi. In tali situazioni, ARIA può aiutare a fornire il valore semantico addizionale necessario. 

- -

Validazione di formulari e avvisi di errore

- -

Innanzitutto, rivediamo l’esempio di formulario che avevamo preso in considerazione nell’articolo sull’accessibilità in CSS e JavaScript (vedi Mantieni un uso non intrusivo di JavaScript). Alla fine di tale sezione abbiamo mostrato alcuni attributi ARIA che sono stati aggiunti al messaggio che appare se ci sono errori di validazione quando provi a inviare il formulario:

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

Possiamo ora procedere oltre con il nostro utilizzo di ARIA, e fornire ulteriore assitenza nella validazione dei dati. Per esempio, perchè non indicare dal principio quali campi sono obbligatori, e quale intervallo di età è permesso introdurre?

- -
    -
  1. A questo punto, salva sul tuo dispositivo una copia dei files  validazione-formulario.html e validazione.js.
    2. -
  2. Aprili entrambi in un editor di testo e dai un’occhiata a come funziona il codice.
    3. -
  3. Per prima cosa, aggiungi un paragrafo come quello che vedi qui sotto giusto prima della etichetta di apertura del formulario <form>, e marca entrambe le etichette <label> del formulario con un asterisco. Questo è il metodo con cui normalmente si segnalano i campi obbligatori agli utenti che non hanno limitazioni visuali. - 
    <p>I campi marcati con un asterisco (*) sono obbligatori.</p>
    -
    4. -
  4. Questa indicazione è utile dal punto di vista visuale, ma non è facile da cogliere per gli utenti che usano lettori di schermo. Fortunatamente, WAI-ARIA fornisce l’attributo  aria-required , che suggerisce al lettore di schermo di indicare all’utente quali sono i campi del formulario che devono essere compilati obbligatoriamente. Aggiorna gli elementi <input> come vedi qui sotto:                                                              
    5. -
  5. - 
    <input type="text" name="name" id="name" aria-required="true">
-
-<input type="number" name="age" id="age" aria-required="true">
    -
    6. -
  6. A questo punto se salvi l’esempio e lo testi con un lettore di schermo dovresti ascoltare qualcosa come “Introduci il tuo nome asterisco, obbligatorio, modifica testo”.
    7. -
  7. Potrebbe inoltre risultare utile indicare agli utenti l’intervallo di anni dentro il quale dovrebbe situarsi il valore dell’età. Spesso tale valore si indica tramite un placeholder, ossia un valore indicativo che appare all’interno del campo quando non è ancora stato compilato. WAI-ARIA include le proprietà aria-valuemin e aria-valuemax per specificare un intervallo di valori minimo e massimo, ma queste proprietà al momento non hanno un supporto ampio; una caratteristica che gode di un migliore supporto è l’attributo HTML5 placeholder, che contiene un messaggio che viene mostrato nel campo quando l’utente non vi ha ancora introdotto nessun valore, e viene letto da un certo numero di lettori di schermo. Aggiorna il campo età come indicato qui: - 
    <input type="number" name="age" id="age" placeholder="introduci un numero compreso tra 1 e 150" aria-required="true">
    -
    8. -
- -
-

Nota: puoi vedere un esempio completo qui: validazione-formulario-aggiornato.html.

-
- -

WAI-ARIA permette inoltre alcune tecniche avanzate di etichettazione dei formulari, che vanno al di là del classico elemento {{htmlelement("label")}}. Abbiamo già discusso sull’utilizzo della proprietà aria-label per rendere un’etichetta {{htmlelement("label")}} invisibile agli utenti che non usano lettori di schermo (vedi la sezione Indicatori/riferimenti sopra). Ci sono anche altre tecniche di etichettazione che fanno uso di proprietà come aria-labelledby, se vuoi usare un elemento non-<label> come etichetta o se vuoi etichettare multipli campi del formulario con la stessa etichetta, e aria-describedby, se vuoi associare informazione aggiuntiva a un campo del formulario e vuoi che il lettore di schermo la legga. Vedi l’articolo in inglese  WebAIM's Advanced Form Labeling per maggiori dettagli.

- -

Ci sono inoltre molte altre proprietà e attributi utili per indicare lo stato di un elemento di un formulario. Per esempio, si può usare aria-disabled="true" per indicare che un campo è disabilitato. Molti browser salteranno i campi disabilitati, e i lettori di schermo non li leggeranno, ma in alcuni casi saranno comunque indicati, dunque è una buona idea includere questo attributo per permettere al lettore di schermo di sapere che un campo è effettivamente disabilitato.

- -

Se esiste la possibilità che lo stato di un campo cambi da disabilitato ad abilitato è buona norma indicarlo all’utente, e  inoltre spiegare le conseguenze di tale cambio. Per esempio, nel nostro formulario demo validazione-formulario-casella-disabilitata.html c’è una casella che, quando è selezionata, abilita un altro campo del formulario, tramite il quale si possono introdurre informazioni aggiuntive. Abbiamo preparato un paragrafo nascosto:

- -
<p class="hidden-alert" aria-live="assertive"></p>
- -

Questo elemento è nascosto alla vista tramite position: absolute. Quando la casella viene selezionata/deselezionata, il contenuto dell’area nascosta si aggiorna per segnalare agli utenti che usano lettore di schermo in che modo la struttura del formulario è cambiata dopo aver selezionato la casella; inoltre si aggiorna anche lo stato dell’attributo aria-disabled e si fornisce anche un indicazione visuale del cambio:

- -
function toggleMusician(bool) {
-  var instruItem = formItems[formItems.length-1];
-  if(bool) {
-    instruItem.input.disabled = false;
-    instruItem.label.style.color = '#000';
-    instruItem.input.setAttribute('aria-disabled', 'false');
-    hiddenAlert.textContent = 'I'Il campo strumenti suonati è ora abilitato; usalo per indicarci quali strumenti sai suonare.';
-  } else {
-    instruItem.input.disabled = true;
-    instruItem.label.style.color = '#999';
-    instruItem.input.setAttribute('aria-disabled', 'true');
-    instruItem.input.removeAttribute('aria-label');
-    hiddenAlert.textContent = ''Il campo Strumenti suonati è ora disabilitato.';
-  }
-}
- -

Descrivere bottoni non semantici come bottoni

- -

Ci è già capitato di discutere della accessiblità nativa di alcuni elementi come bottoni, link o campi di formulario, e dei problemi di accessibilità che sorgono quando si usano elementi sostitutivi per compiere le stesse funzioni di questi elementi. Vedi Controlli di interfaccia utente nell’articolo sull’accessibilità in HTML, e Migliorare l’accessibilità da tastiera, qui sopra). In molti casi è possibile restituire l’accessibilità da tastiera a tali elementi senza troppi problemi, usando tabindex e un poco di JavaScript.

- -

Ma come fare con i lettori di schermo? Non potranno interpretare gli elementi sostitutivi come bottoni. Se facciamo un test con il nostro esempio  div-falsi-bottoni.html e un lettore di schermo, i falsi bottoni saranno segnalati all’utente con frasi come “Cliccami!, gruppo”, che risultano di difficile interpretazione.

- -

Possiamo rimediare al problema usando un ruolo WAI-ARIA. Salva la pagina div-falsi-buttoni.html, e aggiungi role="button" ad ogni <div> che compie la funzione di bottone, come per esempio:

- -
<div data-message="Questo messaggio viene dal primo bottone" tabindex="0" role="button">Cliccami!</div>
- -

Se ora provi a navigare la pagina con un lettore di schermo, i bottoni saranno letti come “Cliccami!, bottone”, e tutto risulterà molto più chiaro.

- -
-

Nota: non dimenticare che usare il corretto elemento semantico è sempre una opzione migliore. Se vuoi creare un bottone e non ci sono ragioni valide per non usare un elemento  <button>, dovresti usare un elemento <button>!

-
- -

Guidare gli utenti nell’uso di widget complessi

- -

Ci sono molti altri ruoli che danno la possibilità di assegnare ad elementi non semantici lo status di comuni elementi dell’interfaccia utente, elementi che vanno al di là di ciò che è disponibile nell’HTML standard, come per esempio  combobox, slider, tabpanel, tree. Puoi trovare alcuni utili esempi nella Deque university code library, per farti un'idea di come tali elementi possono essere resi accessibili.

- -

Prendiamo in considerazione un esempio. Torniamo ad usare il nostro semplice infobox a schede (vedi Nascondere elementi nell’articolo sull’accessibilità in CSS e JavaScript), che puoi trovare qui: infobox a schede (vedi codice sorgente).

- -

Questo esempio funziona perfettamente in termini di accessibilità da tastiera: puoi muoverti facilmente da una scheda all’altra usando il tasto TAB e selezionare una scheda con INVIO per visualizzarne il contenuto. È inoltre abbastanza accessibile se si usa un lettore di schermo, puoi infatti usare gli headings per navigare il contenuto anche senza vederlo. Ciò che però non risulterà del tutto chiaro è in cosa consiste il contenuto stesso: un lettore di schermo riporta il contenuto dell’infobox come composto da un lista di link e da dell’altro contenuto con tre headings. Non da nessuna indicazione di come i contenuti sono relazionati tra loro. Fornire all’utente indicazioni precise su come il contenuto è strutturato è sempre una buona idea.

- -

Abbiamo creato una versione migliorata dell’esempio, chiamata aria-tabbed-info-box.html (vedi versione live). Abbiamo aggiornato l’interfaccia del box così:

- -
<ul role="tablist">
-  <li class="active" role="tab" aria-selected="true" aria-setsize="3" aria-posinset="1" tabindex="0">Tab 1</li>
-  <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="2" tabindex="0">Tab 2</li>
-  <li role="tab" aria-selected="false" aria-setsize="3" aria-posinset="3" tabindex="0">Tab 3</li>
-</ul>
-<div class="panels">
-  <article class="active-panel" role="tabpanel" aria-hidden="false">
-    ...
-  </article>
-  <article role="tabpanel" aria-hidden="true">
-    ...
-  </article>
-  <article role="tabpanel" aria-hidden="true">
-    ...
-  </article>
-</div>
- -
-

Nota: il cambio più evidente è la rimozione dei link che erano presenti precedentemente nell’esempio. Ora si usano i componenti li della lista per identificare le schede. Questo procedimento rende il tutto meno confuso per gli utenti che usano lettori di schermo, in quanto i link che c’erano in precedenza non conducevano da nessuna parte, servivano solo a cambiare di scheda. Inoltre gli attributi aria-setsize e aria-posinset permettono ora di identificare chiaramente le schede tramite il lettore di schermo: in precedenza, con i link, il browser trasmetteva sempre al lettore “1 di 1”, e non “1 di 3”, “2 di 3”, ecc.

-
- -

 

- -

Le nuove funzionalità aggiunte all’infobox di esempio sono le seguenti:

- - - -

Secondo i nostri test, questa nuova struttura ha migliorato sensibilmente l’accessibilità dell’infobox a schede. Le schede sono ora riconosciute come schede (ora il lettore pronuncia “scheda”, o perlomeno “tab”, in inglese), la scheda attualmente selezionata è chiaramente indicata, pronunciando il lettore la parola “selezionata” insieme al nome della scheda, e il lettore di schermo indica anche il numero della scheda in cui si trova l’utente. Inoltre, grazie ai valori di aria-hidden impostati (solo la scheda attualmente selezionata ha il valore aria-hidden="false"), il contenuto non nascosto è il solo che il lettore può leggere, rendendolo il tutto più facile e meno confuso da navigare per l’utente.

- -

 

- -
-

Nota: puoi assegnare l’attributo aria-hidden="true"  a qualsiasi contenuto che vuoi che sia ignorato dai lettori di schermo.

-
- -

Riassunto

- -

Questo articolo non è da considerarsi esaustivo per quanto riguarda tutte le funzionalità disponibili con la tecnologia WAI-ARIA, ma dovrebbe averti fornito informazioni sufficienti a capire come usarla, e come identificare le situazioni più comuni in cui avrai bisogno di ricorrere ad essa.

- -

Vedi anche

- - - -

{{PreviousMenuNext("Learn/Accessibilità/CSS_e_JavaScript_accessibilità","Learn/Accessibilità/Multimedia", "Learn/Accessibilità")}}

-- cgit v1.2.3-54-g00ecf