diff options
Diffstat (limited to 'files/it/learn/accessibility/wai-aria_basics')
| -rw-r--r-- | files/it/learn/accessibility/wai-aria_basics/index.html | 423 |
1 files changed, 0 insertions, 423 deletions
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 ---- -<div>{{LearnSidebar}}</div> - -<div>{{PreviousMenuNext("Learn/Accessibilità/CSS_e_JavaScript_accessibilità","Learn/Accessibilità/Multimedia", "Learn/Accessibilità")}}</div> - -<p class="summary">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à.</p> - -<table class="learn-box standard-table"> - <tbody> - <tr> - <th scope="row">Prerequisiti:</th> - <td>Conoscimenti basici sull'uso del computer, livello basico di HTML, CSS e JavaScript, aver letto <a href="/it/docs/Learn/Accessibilità">i precedenti articoli del corso</a>.</td> - </tr> - <tr> - <th scope="row">Obiettivo:</th> - <td>Acquisire familiarità con la tecnologia WAI-ARIA e imparare a usarla dove necessario per fornire valore semantico addizionale che migliori l'accessibilità.</td> - </tr> - </tbody> -</table> - -<h2 id="Cosa_è_WAI-ARIA">Cosa è WAI-ARIA?</h2> - -<p>Cominciamo col dare un'occhiata a cosa è WAI-ARIA, e in che modo ci può essere utile.</p> - -<h3 id="Un_nuovo_set_di_problemi">Un nuovo set di problemi</h3> - -<p>Man mano che le applicazioni web cominciarono ad essere sempre più complesse e dinamiche, nuovi problemi di accessibilità iniziarono a manifestarsi.</p> - -<p>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 <code><div class="nav"></code>. 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. </p> - -<p>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:</p> - -<pre class="brush: html"><a href="#hidden" class="hidden">Vai alla barra di navigazione</a></pre> - -<p> </p> - -<p>Ma questo sistema non è molto preciso, e può essere usato solo quando il lettore di schermo comincia a leggere dalla parte alta della pagina.</p> - -<p>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:</p> - -<pre class="brush: html"><input type="date"> -<input type="range"></pre> - -<p>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.</p> - -<p>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.</p> - -<h3 id="E_arrivò_WAI-ARIA">E arrivò WAI-ARIA</h3> - -<p><a href="https://www.w3.org/TR/wai-aria-1.1/">WAI-ARIA</a> è 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: </p> - -<ul> - <li><strong>Ruoli </strong>— I ruoli (role) definiscono cosa un elemento è e qual è la sua funzione. Molti sono cosiddetti ruoli di riferimento, che in sostanza replicano il valore semantico degli elementi HTML5. Per esempio<code> role="navigation" </code>({{htmlelement("nav")}}) che corrisponde a <a href="https://developer.mozilla.org/it/docs/Web/HTML/Element/nav" title="L'elemento HTML nav (<nav>) rappresenta una sezione della pagina che contiene link ad altre pagine o a parti della pagina corrente: una sezione di navigazione."><nav></a>, o <code>role="complementary"</code> ({{htmlelement("aside")}}), che corrisponde a <a href="https://developer.mozilla.org/it/docs/Web/HTML/Element/aside" title="L'elemento HTML <aside> rappresenta una sezione della pagina il cui contenuto è connesso solo marginalmente al resto della pagina, e che dovrebbe essere considerato separato dal resto del contenuto. Queste sezioni sono spesso usate come sidebar. Spesso co"><aside></a>. Ma ce ne sono anche altri che definiscono diverse strutture della pagina che si trovano comunemente nelle IU (Interfacce Utente), come <code>role="banner"</code>, <code>role="search"</code>, <code>role="tabgroup"</code>, <code>role="tab"</code>, ecc.</li> - <li><strong>Proprietà </strong>— Si tratta delle proprietà degli elementi, che si possono usare per dare agli stessi un significato extra. Per esempio, <code>aria-required="true"</code> specifica che il campo di un formulario deve essere obbligatoriamente compilato per essere valido, mentre <code>aria-labelledby="label"</code> permette di assegnare una ID a un elemento e in seguito usare l'elemento come etichetta per qualsiasi altro elemento nella pagina, anche per multipli elementi allo stesso tempo, cosa che non è possibile con <code><label for="input"></code>. Per esempio, potresti usare aria-labelledby per specificare che una descrizione contenuta in un {{htmlelement("div")}} si usi come etichetta per multiple celle di una tabella, o come testo alternativo di una immagine, senza doverlo ripetere nell'attributo <code>alt</code>. Puoi vedere un esempio d'uso nella sezione Alternative testuali.</li> - <li><strong>Stati</strong> — GLi stati sono proprietà speciali che definiscono le condizioni correnti degli elementi, come per esempio <code>aria-disabled="true"</code>, che specifica a un lettore di schermo che un campo di input di un formulario è al momento disabilitato. Gli stati si distinguono dalle proprietà per il fatto che le proprietà non cambiano durante il ciclo vitale di un'applicazione, mentre gli stati possono essere cambiati, in genere tramite l'uso di JavaScript.</li> -</ul> - -<p>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.</p> - -<div class="note"> -<p><strong>Nota</strong>: 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 <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">Definizione di Ruoli </a>(in inglese).</p> - -<p>La specifica contiene anche una lista delle proprietà e degli stati, con link ad ulteriori informazioni. Vedi <a href="https://www.w3.org/TR/wai-aria-1.1/#state_prop_def">Definizioni di Stati e Proprietà</a> (in inglese).</p> -</div> - -<h3 id="Dove_è_supportata_WAI-ARIA">Dove è supportata WAI-ARIA?</h3> - -<p>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è:</p> - -<ol> - <li>Ci sono molte funzionalità nella specifica WAI-ARIA.</li> - <li>Ci sono moltissime combinazioni possibili di sistemi operativi, browser e lettori di schermo.</li> -</ol> - -<p>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) <a href="https://developer.paciellogroup.com/blog/2014/10/rough-guide-browsers-operating-systems-and-screen-reader-support-updated/">Guida: browser, sistemi operativi e supporto per i lettori di schermo</a>.</p> - -<p>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.</p> - -<ol> - <li>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%.</li> - <li>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) <a href="https://www.powermapper.com/tests/screen-readers/aria/">Compatibilità dei lettori di schermo con WAI-ARIA</a> .</li> -</ol> - -<p>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.</p> - -<div class="note"> -<p><strong>Nota</strong>: 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 <a href="https://jqueryui.com/about/#deep-accessibility-support">jQuery UI: supporto all'accessibilità</a>), <a href="https://www.sencha.com/products/extjs/">ExtJS</a>, e <a href="https://dojotoolkit.org/reference-guide/1.10/dijit/a11y/statement.html">Dojo/Dijit</a>.</p> -</div> - -<h3 id="Quando_dovresti_usare_WAI-ARIA">Quando dovresti usare WAI-ARIA?</h3> - -<p>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: </p> - -<ol> - <li><strong>Indicatori/riferimenti</strong>: gli attributi <code>role</code> 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 <code>search</code>, <code>tabgroup</code>, <code>tab</code>, <code>listbox</code>, ecc.</li> - <li><strong>Aggiornamento dinamico del contenuto</strong>: i lettori di schermo in generale hanno difficoltà a indicare quando il contenuto subisce cambiamenti; con ARIA possiamo usare <code>aria-live</code> per indicare agli utenti che usano lettori di schermo quando un' area del contenuto viene aggiornata, per esempio tramite <a href="/it/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a>, o <a href="/it/docs/Web/API/Document_Object_Model">DOM APIs</a> .</li> - <li><strong>Migliorare l'accessibilità da tastiera</strong>: 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 <code>tabindex</code>).</li> - <li><strong>Accessibilità dei controlli non semantici</strong>: quando si usano una serie di <code><div></code> 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 <code>button</code>, <code>listbox</code>, o <code>tabgroup</code>, e proprietà come <code>aria-required</code> o <code>aria-posinset</code>.</li> -</ol> - -<p>Ricorda: <strong>dovresti ricorrere a WAI-ARIA solo quando è necessario!</strong> Idealmente, dovresti usare <em>sempre</em> <a href="/it/docs/Learn/Accessibilità/HTML_accessibilità">funzionalità HTML native</a> 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à. </p> - -<p>Ma ricorda, usala solo quando è necessario!</p> - -<div class="note"> -<p><strong>Nota</strong>: 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.</p> -</div> - -<h2 id="Esempi_di_uso_pratico_di_WAI-ARIA">Esempi di uso pratico di WAI-ARIA </h2> - -<p>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.</p> - -<p>Vedi la sezione (in inglese) sul <a href="https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Accessibility#Screenreaders">testing con lettori di schermo</a> per maggiori informazioni.</p> - -<h3 id="Indicatoririferimenti">Indicatori/riferimenti</h3> - -<p>WAI-ARIA trasmette ai browser l'attributo <code>role</code>, 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 <a href="https://github.com/mdn/learning-area/tree/master/accessibility/aria/website-no-roles">sito senza attributi role</a> (vedi la <a href="https://mdn.github.io/learning-area/accessibility/aria/website-no-roles/">versione live</a>) ha la seguente struttura:</p> - -<pre class="brush: html"><header> - <h1>...</h1> - <nav> - <ul>...</ul> - <form> - <!-- search form --> - </form> - </nav> -</header> - -<main> - <article>...</article> - <aside>...</aside> -</main> - -<footer>...</footer></pre> - -<p>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:</p> - -<ul> - <li>Riguardo l'elemento <code><header></code> — "banner, 2 oggetti" (contiene un heading h1 e la barra di navigazione <code><nav></code>).</li> - <li>Riguardo l'elemento <code><nav></code> — "navigazione, 2 oggetti" (contiene una lista e un formulario).</li> - <li>Riguardo l'elemento <code><main></code> — "principale, 2 oggetti" (contiene un articolo e una barra di navigazione laterale).</li> - <li>Riguardo l'elemento <code><aside> </code>— "complementario, 2 oggetti" (contiene un heading h2 e una lista).</li> - <li>Riguardo il campo di ricerca — "Funzione ricerca, casella di testo".</li> - <li>Riguardo l'elemento <code><footer></code> — "pié di pagina 1 oggetto".</li> -</ul> - -<p>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.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/14420/landmarks-list.png" style="display: block; margin: 0 auto;"></p> - -<p>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 (<code><input type="search"></code>). Inoltre, alcuni browser più vecchi (per esempio IE8), non riconoscono le indicazioni semantiche degli elementi HTML5. </p> - -<p>Possiamo migliorare il tutto usando alcune funzionalità ARIA. Per prima cosa aggiungiamo alcuni attributi role alla nostra struttura HTML. Il nostro <a href="https://github.com/mdn/learning-area/tree/master/accessibility/aria/website-aria-roles">esempio di sito con ruoli aria</a> (vedi la <a href="https://mdn.github.io/learning-area/accessibility/aria/website-aria-roles/">versione live</a>) ha la seguente struttura:</p> - -<pre class="brush: html"><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></pre> - -<p>C'è anche una funzionalità bonus in questo esempio: all'elemento {{htmlelement("input")}} è stato assegnato l'attributo <code>aria-label</code>, 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.</p> - -<pre class="brush: html"><input type="search" name="q" placeholder="Scrivi qui ciò che vuoi cercare" aria-label="Campo per cercare nel contenuto del sito"></pre> - -<p>Se ora usiamo VoiceOver per navigare il sito d'esempio, notiamo alcuni miglioramenti:</p> - -<ul> - <li>Il campo di ricerca viene indicato come un elemento separato, sia mentre si naviga la pagina sia nella sezione Rotore.</li> - <li>Il testo contenuto nell'attributo <code>aria-label</code> viene letto quando il campo riceve focus.</li> -</ul> - -<p>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 <code><div></code>, dovresti decisamente includere i ruoli ARIA per fornire le necessarie semantiche!</p> - -<p>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.</p> - -<h3 id="Aggiornamenti_del_contenuto_dinamico">Aggiornamenti del contenuto dinamico</h3> - -<p>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.</p> - -<p>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 <a href="/it/docs/Web/API/XMLHttpRequest">XMLHttpRequest</a>, <a href="/it/docs/Web/API/Fetch_API">Fetch</a>, o <a href="/it/docs/Web/API/Document_Object_Model">DOM APIs</a>. Queste aree del contenuto sono talvolta chiamate “aree vive”, o <strong>live regions</strong>.</p> - -<p>Consideriamo un esempio: <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-no-live.html">aria-no-live.html</a> (vedi anche la <a href="https://mdn.github.io/learning-area/accessibility/aria/aria-no-live.html">versione live</a>). In questo esempio troviamo un paragrafo contenente una citazione selezionata casualmente:</p> - -<pre class="brush: html"><section> - <h1>Citazione casuale</h1> - <blockquote> - <p></p> - </blockquote> -</section></pre> - -<p>JavaScript riceve tramite <code>XMLHttpRequest</code> 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 <code>setInterval()</code> che carica una nuova citazione nel paragrafo ogni 10 secondi:</p> - -<pre class="brush: js">var intervalID = window.setInterval(showQuote, 10000);</pre> - -<p>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.</p> - -<p>Fortunatamente WAI-ARIA ci mette a disposizione un utile meccanismo per fornire tali avvertimenti, la proprietà <code>aria-live</code>. 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:</p> - -<ul> - <li><code>off:</code> valore di default. Gli aggiornamenti non vengono annunciati.</li> - <li><code>polite</code>: gli aggiornamenti vengono annunciati solo quando l'utente è inattivo.</li> - <li><code>assertive</code>: gli aggiornamenti vengono annunciati all'utente il prima possibile.</li> - <li><code>rude</code>: gi aggiornamenti vengono annunciati istantaneamente, interrompendo ciò che l'utente sta facendo.</li> -</ul> - -<p>Generalmente, assegnare il valore <code>assertive</code> è 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 <code>rude</code> solo per aggiornamenti ad alta priorità che devono "passare davanti" agli altri aggiornamenti in corso.</p> - -<p>Prova a realizzare una copia di <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-no-live.html">aria-no-live.html</a> e <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/quotes.json">quotes.json</a>, e modificare l'etichetta <code><section></code> così:</p> - -<pre class="brush: html"><section aria-live="assertive"></pre> - -<p>D'ora in poi il lettore di schermo leggerà il contenuto ogni volta che quest'ultimo sarà aggiornato.</p> - -<div class="note"> -<p><strong>Nota</strong>: : la maggior parte dei browser attiverà una security exception se provi ad effettuare un <code>XMLHttpRequest</code> da un URL <code>file://</code>. 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 <a href="https://developer.mozilla.org/en-US/docs/Learn/Common_questions/Using_Github_pages">GitHub</a> (articolo in inglese), o un server locale come <a href="http://www.pythonforbeginners.com/modules-in-python/how-to-use-simplehttpserver/">Python's SimpleHTTPServer</a> (articolo in inglese).</p> -</div> - -<p>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à <code>aria-atomic</code> alla sezione. Modifica la tua etichetta <code><section></code> così:</p> - -<pre class="brush: html"><section aria-live="assertive" aria-atomic="true"></pre> - -<p>L'attributo <code>aria-atomic="true"</code> indica al lettore di schermo che deve leggere l'intero contenuto dell'elemento, non solo le parti che sono state aggiornate. </p> - -<div class="note"> -<p><strong>Nota</strong>: : puoi vedere l'esempio completo qui: <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-live.html">aria-live.html</a> (vedi anche la <a href="http://mdn.github.io/learning-area/accessibility/aria/aria-live.html">versione live</a>).</p> -</div> - -<div class="note"> -<p><strong>Nota</strong>: : la proprietà <code>aria-relevant</code> è 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.</p> -</div> - -<h3 id="Migliorare_l'accessibilità_da_tastiera">Migliorare l'accessibilità da tastiera</h3> - -<p>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 <code><select></code>).</p> - -<p>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.</p> - -<p>Per rendere focalizzabili elementi che normalmente non lo sono, WAI-ARIA estende l'attributo <code>tabindex</code> con alcuni nuovi valori:</p> - -<ul> - <li><code>tabindex="0"</code> — come specificato in precedenza, questo valore rende "tabbabili" elementi che normalmente non lo sono. Questo è il valore più utile di <code>tabindex</code>.</li> - <li><code>tabindex="-1"</code> — questo valore permette ad elementi normalmente non tabbabili di ricevere focus programmaticamente, per esempio tramite JavaScript, o come destinazione di un link. </li> -</ul> - -<p>Abbiamo discusso questi valori in maggior dettaglio e mostrato una implementazione tipica nel nostro articolo sull'accessibilità in HTML, vedi <a href="/it/docs/Learn/Accessibilità/HTML_accessibilità#Implementare_l'accessibilità_da_tastiera_in_un_secondo_tempo">Implementare l'accessibilità da tastiera in un secondo tempo</a>.</p> - -<h3 id="Accessibilità_dei_controlli_non_semantici">Accessibilità dei controlli non semantici</h3> - -<p>Proseguendo con il tema trattato nella sezione precedente, quando si usa una serie di <code><div></code> 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. </p> - -<h4 id="Validazione_di_formulari_e_avvisi_di_errore"><strong>Validazione di formulari e avvisi di errore</strong></h4> - -<p>Innanzitutto, rivediamo l’esempio di formulario che avevamo preso in considerazione nell’articolo sull’accessibilità in CSS e JavaScript (vedi <a href="/it/docs/Learn/Accessibilità/CSS_e_JavaScript_accessibilità#Mantieni_un_uso_non_intrusivo_di_JavaScript">Mantieni un uso non intrusivo di JavaScript</a>). 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:</p> - -<pre class="brush: html"><code class="language-html"><span class="tag token"><span class="tag token"><span class="punctuation token"><</span>div</span> <span class="attr-name token">class</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>errors<span class="punctuation token">"</span></span> <span class="attr-name token">role</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>alert<span class="punctuation token">"</span></span> <span class="attr-name token">aria-relevant</span><span class="attr-value token"><span class="punctuation token">=</span><span class="punctuation token">"</span>all<span class="punctuation token">"</span></span><span class="punctuation token">></span></span> - <span class="tag token"><span class="tag token"><span class="punctuation token"><</span>ul</span><span class="punctuation token">></span></span> - <span class="tag token"><span class="tag token"><span class="punctuation token"></</span>ul</span><span class="punctuation token">></span></span> -<span class="tag token"><span class="tag token"><span class="punctuation token"></</span>div</span><span class="punctuation token">></span></span></code></pre> - -<ul> - <li><code><u><a href="https://www.w3.org/TR/wai-aria-1.1/#alert">role="alert"</a></u></code> trasforma automaticamente l’elemento a cui è applicato in una live region, di modo che i cambi applicati all’elemento vengono letti dal lettore di schermo; inoltre identifica semanticamente l’elemento come un messaggio di allerta (informazione importante relativa al momento/contesto), e rappresenta una migliore e più accessibile maniera di fornire un avviso a un utente (i dialoghi modali come le chiamate <code><u><a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/alert">alert()</a></u></code> presentano un certo numero di problemi di accessibilità; vedi l’articolo (in inglese) <u><a href="http://webaim.org/techniques/javascript/other#popups">Popup Windows</a></u> scritto da WebAIM).</li> - <li>Il valore <code><u><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-relevant">aria-relevant="all"</a></u></code> indica al lettore di schermo che deve rileggere il contenuto della lista di errori ogni volta che si verificano cambi in essa, per esempio quando vengono aggiunti o rimossi errori. Ciò risulta utile, in quanto l’utente potrà essere sempre al corrente di quali errori sono presenti sulla lista, non solo di quali sono stati aggiunti o rimossi dalla stessa.</li> -</ul> - -<p>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?</p> - -<ol> - <li>A questo punto, salva sul tuo dispositivo una copia dei files <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/form-validation.html">validazione-formulario.html</a> e <a href="https://github.com/mdn/learning-area/blob/master/accessibility/css/validation.js">validazione.js</a>.</li> - <li>Aprili entrambi in un editor di testo e dai un’occhiata a come funziona il codice.</li> - <li>Per prima cosa, aggiungi un paragrafo come quello che vedi qui sotto giusto prima della etichetta di apertura del formulario <code><form></code>, e marca entrambe le etichette <code><label></code> del formulario con un asterisco. Questo è il metodo con cui normalmente si segnalano i campi obbligatori agli utenti che non hanno limitazioni visuali. - <pre class="brush: html"><p>I campi marcati con un asterisco (*) sono obbligatori.</p></pre> - </li> - <li>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 <u><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-required">aria-required</a></u> , che suggerisce al lettore di schermo di indicare all’utente quali sono i campi del formulario che devono essere compilati obbligatoriamente. Aggiorna gli elementi <code><input></code> come vedi qui sotto: </li> - <li> - <pre><code><input type="text" name="name" id="name" aria-required="true"> - -<input type="number" name="age" id="age" aria-required="true"></code></pre> - </li> - <li>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”.</li> - <li>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à <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-valuemin">aria-valuemin</a></code> e <code><u><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-valuemax">aria-valuemax</a></u></code> 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 <code>placeholder</code>, 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: - <pre class="brush: html"><input type="number" name="age" id="age" placeholder="introduci un numero compreso tra 1 e 150" aria-required="true"></pre> - </li> -</ol> - -<div class="note"> -<p><strong>Nota</strong>: puoi vedere un esempio completo qui: <a href="http://mdn.github.io/learning-area/accessibility/aria/form-validation-updated.html">validazione-formulario-aggiornato.html</a>.</p> -</div> - -<p>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à <code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-label">aria-label</a></code> per rendere un’etichetta {{htmlelement("label")}} invisibile agli utenti che non usano lettori di schermo (vedi la sezione <code><a href="https://developer.mozilla.org/it/docs/Learn/Accessibilit%C3%A0/WAI-ARIA_basics/Indicatori/riferimenti">Indicatori/riferimenti</a></code> sopra). Ci sono anche altre tecniche di etichettazione che fanno uso di proprietà come <code><u><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby">aria-labelledby</a></u></code>, se vuoi usare un elemento non-<code><label></code> come etichetta o se vuoi etichettare multipli campi del formulario con la stessa etichetta, e <code><u><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-describedby">aria-describedby</a></u></code>, se vuoi associare informazione aggiuntiva a un campo del formulario e vuoi che il lettore di schermo la legga. Vedi l’articolo in inglese <a href="http://webaim.org/techniques/forms/advanced">WebAIM's Advanced Form Labeling</a> per maggiori dettagli.</p> - -<p>Ci sono inoltre molte altre proprietà e attributi utili per indicare lo stato di un elemento di un formulario. Per esempio, si può usare <code><u><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-disabled">aria-disabled</a></u>="true"</code> 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.</p> - -<p>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 <u><a href="http://mdn.github.io/learning-area/accessibility/aria/form-validation-checkbox-disabled.html">validazione-formulario-casella-disabilitata.html</a></u> 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> - -<pre class="brush: html"><p class="hidden-alert" aria-live="assertive"></p></pre> - -<p>Questo elemento è nascosto alla vista tramite <code>position: absolute</code><strong>. </strong>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 <code>aria-disabled</code> e si fornisce anche un indicazione visuale del cambio:</p> - -<pre class="brush: js">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.'; - } -}</pre> - -<h4 id="Descrivere_bottoni_non_semantici_come_bottoni">Descrivere bottoni non semantici come bottoni</h4> - -<p>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 <a href="/it/docs/Learn/Accessibilità/HTML_accessibilità#Controlli_di_Interfaccia_Utente">Controlli di interfaccia utente</a> nell’articolo sull’accessibilità in HTML, e <a href="/it/docs/Learn/Accessibilità/WAI-ARIA_basics#Migliorare_l'accessibilità_da_tastiera">Migliorare l’accessibilità da tastiera</a>, qui sopra). In molti casi è possibile restituire l’accessibilità da tastiera a tali elementi senza troppi problemi, usando <code>tabindex</code> e un poco di JavaScript.</p> - -<p>Ma come fare con i lettori di schermo? Non potranno interpretare gli elementi sostitutivi come bottoni. Se facciamo un test con il nostro esempio <a href="http://mdn.github.io/learning-area/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">div-falsi-bottoni.html</a> e un lettore di schermo, i falsi bottoni saranno segnalati all’utente con frasi come “Cliccami!, gruppo”, che risultano di difficile interpretazione.</p> - -<p>Possiamo rimediare al problema usando un ruolo WAI-ARIA. Salva la pagina <a href="https://github.com/mdn/learning-area/blob/master/tools-testing/cross-browser-testing/accessibility/fake-div-buttons.html">div-falsi-buttoni.html</a>, e aggiungi <code><a href="https://www.w3.org/TR/wai-aria-1.1/#button">role="button"</a></code> ad ogni <code><div></code> che compie la funzione di bottone, come per esempio:</p> - -<pre><div data-message="Questo messaggio viene dal primo bottone" tabindex="0" role="button"><code>Cliccami!</code></div></pre> - -<p>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.</p> - -<div class="note"> -<p><strong>Nota</strong>: 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 <code><a href="https://developer.mozilla.org/it/docs/Web/HTML/Element/button" title="L'elemento HTML <button> rappresenta un bottone cliccabile."><button></a></code>, dovresti usare un elemento <code><a href="https://developer.mozilla.org/it/docs/Web/HTML/Element/button" title="L'elemento HTML <button> rappresenta un bottone cliccabile."><button></a></code>!</p> -</div> - -<h4 id="Guidare_gli_utenti_nell’uso_di_widget_complessi">Guidare gli utenti nell’uso di widget complessi</h4> - -<p>Ci sono molti altri <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">ruoli</a> 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 <code> <a href="https://www.w3.org/TR/wai-aria-1.1/#combobox">combobox</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#slider">slider</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tabpanel">tabpanel</a></code>, <code><a href="https://www.w3.org/TR/wai-aria-1.1/#tree">tree</a></code>. Puoi trovare alcuni utili esempi nella <a href="https://dequeuniversity.com/library/">Deque university code library</a>, per farti un'idea di come tali elementi possono essere resi accessibili.</p> - -<p>Prendiamo in considerazione un esempio. Torniamo ad usare il nostro semplice infobox a schede (vedi <a href="https://developer.mozilla.org/it/docs/Learn/Accessibilità/CSS_e_JavaScript_accessibilità#Nascondere_elementi">Nascondere elementi</a> nell’articolo sull’accessibilità in CSS e JavaScript), che puoi trovare qui: <a href="http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html">infobox a schede</a> (vedi <a href="https://github.com/mdn/learning-area/blob/master/css/css-layout/practical-positioning-examples/info-box.html">codice sorgente</a>).</p> - -<p>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.</p> - -<p>Abbiamo creato una versione migliorata dell’esempio, chiamata <a href="https://github.com/mdn/learning-area/blob/master/accessibility/aria/aria-tabbed-info-box.html">aria-tabbed-info-box.html</a> (vedi <a href="http://mdn.github.io/learning-area/accessibility/aria/aria-tabbed-info-box.html">versione live</a>). Abbiamo aggiornato l’interfaccia del box così:</p> - -<pre class="brush: html"><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></pre> - -<div class="note"> -<p><strong>Nota</strong>: 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 <code>aria-setsize</code> e <code>aria-posinset</code> 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.</p> -</div> - -<p> </p> - -<p>Le nuove funzionalità aggiunte all’infobox di esempio sono le seguenti:</p> - -<ul> - <li>Nuovi ruoli — <a href="https://www.w3.org/TR/wai-aria-1.1/#tablist">tablist</a>, <a href="https://www.w3.org/TR/wai-aria-1.1/#tab">tab</a>, <a href="https://www.w3.org/TR/wai-aria-1.1/#tabpanel">tabpanel</a> — che identificano le aree più importanti dell’interfaccia: il contenitore delle schede, le schede stesse e i pannelli corrispondenti.</li> - <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-selected">aria-selected</a></code> — definisce quale scheda è attualmente selezionata. Quando l’utente seleziona una nuova scheda, il valore di questo attributo viene aggiornato per ogni scheda tramite JavaScript.</li> - <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-hidden">aria-hidden</a></code> — impedisce che un elemento venga letto dal lettore di schermo. Quando l’utente seleziona una nuova scheda, il valore di questo attributo viene aggiornato per ogni scheda tramite JavaScript.</li> - <li><code>tabindex="0"</code> — poichè abbiamo rimosso i link, dobbiamo assegnare questo attributo agli elementi li della lista per renderli focalizzabili tramite tastiera.</li> - <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-setsize">aria-setsize</a></code> — questa proprietà permette di specificare al lettore di schermo che un elemento è parte di una serie, e quanti sono gli elementi che costituiscono la serie. </li> - <li><code><a href="https://www.w3.org/TR/wai-aria-1.1/#aria-posinset">aria-posinset</a></code> — questa proprietà permette di specificare quale posizione un elemento occupa nella serie. Usata insieme a <code>aria-setsize</code>, questa proprietà fornisce al lettore di schermo informazioni sufficienti perchè possa segnalare all’utente dove si trova correntemente, cioè se nell’elemento “1 di 3”, “2 di 3”, ecc. In molti casi, i browser dovrebbero essere in grado di ricavare questa informazione dalla gerarchia degli elementi, ma è sicuramente di aiuto fornire più indicazioni possibile. </li> -</ul> - -<p>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 <code>aria-hidden</code> impostati (solo la scheda attualmente selezionata ha il valore <code>aria-hidden="false"</code>), il contenuto non nascosto è il solo che il lettore può leggere, rendendolo il tutto più facile e meno confuso da navigare per l’utente.</p> - -<p> </p> - -<div class="note"> -<p><strong>Nota</strong>: puoi assegnare l’attributo <code>aria-hidden="true"</code> a qualsiasi contenuto che vuoi che sia ignorato dai lettori di schermo.</p> -</div> - -<h2 id="Riassunto">Riassunto</h2> - -<p>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.</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li><a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">Definition of Roles</a> — guida di riferimento sui ruoli ARIA.</li> - <li><a href="https://www.w3.org/TR/wai-aria-1.1/#state_prop_def">Definitions of States and Properties (all aria-* attributes)</a> — guida di riferimento sulle proprietà e gli stati.</li> - <li><a href="https://dequeuniversity.com/library/">Deque university code library</a> — una libreria di utilissimi esempi pratici che mostrano complessi elementi di interfaccia utente resi accessibili usando le funzionalità di WAI-ARIA.</li> - <li><a href="http://w3c.github.io/aria-practices/">WAI-ARIA Authoring Practices</a> — dettagliatissime guide di disegno del W3C, che spiegano come implementare differenti tipi di controlli di interfaccia utente complessi, e come renderli accessibili usando le funzionalità di WAI-ARIA.</li> - <li><a href="https://www.w3.org/TR/html-aria/">ARIA in HTML</a> — Una specifica del W3C che definisce, per ogni elemento HTML, quali semantiche di accessibilità (ARIA) sono implementate nativamente dai browser, e quali funzionalità WAI-ARIA puoi usare per fornire semantiche extra se sono necessarie.</li> -</ul> - -<p>{{PreviousMenuNext("Learn/Accessibilità/CSS_e_JavaScript_accessibilità","Learn/Accessibilità/Multimedia", "Learn/Accessibilità")}}</p> |