Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Accessibility
Code

ARIA in pratica: gli elementi dell'Homepage e gli standard di navigazione

by
Length:MediumLanguages:
This post is part of a series called Web Accessibility With ARIA.
Site Accessibility: Getting Started With ARIA
Hands-on With ARIA: Accessibility for eCommerce

Italian (Italiano) translation by Cinzia Sgariglia (you can also view the original English article)

State cercando di rendere il vostro sito Web più accessibile? Volete essere in prima linea quando le nuove interfacce online arrivano sul mercato? Vi basta osservare ARIA.

Questo insieme di standard mantenuto dal W3C (World Wide Web Consortium) vi dà il meglio di entrambi i mondi con l'aggiunta di un numero di attributi che consentono all'HTML di essere esteso in modo significativo. Qui, vedremo che cosa è ARIA, vedrete come ne può beneficiare un sito informativo e analizzeremo un caso di utilizzo passo per passo con esempi di codice. Iniziamo!

Nozioni di base di ARIA

ARIA (o, talvolta, WAI-ARIA) è l'acronimo di un insieme di standard di accessibilità, chiamato Web Accessibility Initiative-Accessible Rich Internet Applications. È possibile controllare di più sui fondamenti di ARIA nel mio precedente articolo, ma ora esaminiamo alcuni dei suoi pilastri.

Definizione di relazioni non tradizionali

La maggioranza dei siti Web sono costruiti utilizzando HTML, che riguarda principalmente gli elementi tra loro in modo gerarchico tramite relazioni padre-figlio. Questa struttura è fantastica per la definizione dei contenuti, ma delude quando si tratta di definire le interfacce utente. Per esempio, in molti siti e applicazioni web, un'area di contenuto è controllata dai pulsanti all'interno di un elemento fratello adiacente — i fratelli adiacenti hanno lo stesso elemento padre, ma in HTML non hanno un rapporto diretto l'uno con l'altro. Per questo motivo, diventa difficile definire quali elementi dell'interfaccia utente (UI) controllano quali parti di contenuto quando si utilizzano le tecnologie assistive.

Questo porta inoltre a interfacce più nuove. Ad esempio, se si sta tentando di navigare un sito Web attraverso un dispositivo smart, diventa difficile quando le modifiche dell'elemento non sono visibili.

ARIA vi consente di legare gli elementi HTML insieme utilizzando attributi aggiuntivi per rappresentare questi tipi di controlli.

Classificazione non rigida dell'elemento

Un'altra lacuna dell'HTML è l'impossibilità di separare la struttura dallo scopo.

Per esempio, se si desidera rendere un elemento dell'immagine in un pulsante cliccabile. Tuttavia, HTML definisce ancora in gran parte quell'immagine come sola immagine, e tutto ciò che è oltre che avviene altrove.

Con ARIA, lo scopo può essere separato da un elemento, consentendo alle immagini di essere contrassegnate come pulsanti o a un link di essere definito come un tooltip. Questo dà più controllo allo sviluppatore riguardo all'interfaccia utente, creando più chiaramente relazioni fisse.

Creazione di zone di riferimento

Oltre a contrassegnare gli elementi all'interno dell'interfaccia, ARIA dà anche accesso all'attributo role — utilizzato per definire le aree di una pagina. Per esempio, è possibile contrassegnare il vostro menu principale come navigazione e l'area di contenuto del vostro articolo come contenuto principale. Questo rende più facile agli utenti di muoversi in tutte le aree importanti del vostro sito e può evitare confusione per quelli con layout del sito insolito o complesso.

Caso di utilizzo: Homepage per piccole imprese

Per ottenere una certa esperienza nell'aggiungere ARIA a un sito, prenderemo un wireframe di un sito che potrebbe essere utilizzato da una piccola impresa e implementeremo i nostri attributi passo dopo passo.

Example Page Wireframe
Il wireframe della pagina che codificheremo

Per motivi di chiarezza, il codice con lavoreremo è ridotto al minimo, con le classi CSS e qualsiasi funzionalità da un CMS è stata rimossa.

La prima cosa che vogliamo fare è dividere il nostro wireframe in parti per rendere l'aggiunta di ARIA più semplice nel complesso. Nella foto qui sotto, vedrete che ho scelto di suddividere il sito in cinque parti principali:

  • navigazione
  • contenuto
  • barra laterale
  • moduli di contatto
  • elementi di interfaccia utente specializzati

Nel nostro caso, appare così:

Wireframe broken into sections
Le sezioni su cui lavoreremo

Quando dividete il vostro sito in aree come queste, stiamo cercando due cose. La prima è per gli elementi principali che possono essere definiti da un punto di riferimento ARIA: banner, navigazione, principale, complementare, informazioni di contenuto, ricerca e forma. Questi rappresentano le parti necessarie del nostro sito, e le cose superflue per utilizzarlo non saranno contrassegnate come un punto di riferimento (es. pubblicità).

La seconda cosa da cercare sono gli elementi specifici che devono essere chiariti con ARIA. Nella maggior parte dei casi, è abbastanza semplice (ad esempio contrassegnare un'immagine come un'immagine), ma per alcuni elementi dell'interfaccia utente, può essere un po' difficile.

Una volta che sappiamo quali aree necessitano di avere ARIA implementato, possiamo iniziare a muoverci attraverso di loro sistematicamente. Cominciamo con la navigazione del sito.

Navigazione

Nel nostro esempio, noterete che abbiamo alcuni tipi di navigazione. Il primo è un menu come visto sulla maggior parte dei siti, che elenca alcune pagine del sito. Direttamente sotto c'è un menu più piccolo che contiene le opzioni per gli utenti.

Vogliamo segnare questi con l'attributo role="navigation" in modo che essi possono essere facilmente selezionati come i menu del sito. Questo porta alla domanda: dovrebbero essere raggruppati insieme in un punto di riferimento di navigazione singolo, o magari contrassegnati come due distinti punti di riferimento?

Per rispondere a questa domanda nei propri progetti, potete in genere porvi due domande:

  1. È diverso lo scopo per questi menu? Nel nostro esempio, il menu in alto naviga le pagine principali del sito, mentre il menu più piccolo si concentra su cose di cui un utente  registrato potrebbe aver bisogno. Questi scopi sono diversi, quindi ha senso separarli.

  2. I menu sono all'interno dello stesso elemento padre? So che questo sembra controintuitivo poiché ARIA è stato progettato per aiutarci a superare questi tipi di restrizioni di rapporto, ma in questo caso riguarda meno ciò che è possibile e più ciò che è giusto per l'utente. Avere un singolo menu definito, ma con la metà di esso in un percorso e l'altra metà altrove, rende più difficile la navigazione.

Per il nostro caso, ci accingiamo a trattare le nostre navigazioni come due punti di riferimento separati. Così faremo alcune modifiche al codice. Per cominciare, abbiamo solo il nostro HTML di base:

Ora, lo annoteremo con alcuni punti di riferimento.

Il prossimo passo nella definizione di questi punti di riferimento è quello di dare all'utente un indizio su che qual è lo scopo di ogni menu. Se li lasciamo entrambi come navigazione senza qualsiasi ulteriore informazione, rende solo le cose più difficili da interpretare. Quindi aggiungiamogli delle etichette significative utilizzando l'attributo aria-label:

Oltre a ciò, vorremo aggiungere del markup role aggiuntivo al nostro menu per consentire agli utenti di sapere che questo è un menu e contrassegnare ogni collegamento all'interno come una voce di menu:

Area del contenuto

Ora l'area del contenuto. Qui, aggiungeremo al codice del contenitore che contiene interamente il nostro contenuto principale con role="main". Ancora una volta, per confronto, ecco il nostro codice di partenza.

Ed ecco come appare dopo che abbiamo aggiunto il punto di riferimento "main".

All'interno di tale contenuto, andremo a cercare qualsiasi elemento che ha uno scopo che non corrisponde alla definizione HTML.

In primo luogo, ci occupiamo dell'immagine che agisce come un pulsante aggiungendo il ruolo di "button":

Questo collegamento che attiva un modale è un po' più complicato, perché dipende da che cosa è il modale stesso. Per noi, diremo che è un tooltip:

All'interno del nostro contenuto principale, abbiamo anche un modulo di ricerca. Ha un ulteriore livello di complessità, nel senso che è un modulo di ricerca che utilizza elementi HTML, e si qualifica anche come un punto di riferimento della casella di ricerca. Lo contrassegneremmo così:

Oltre a ciò, potete definire ogni elemento con un tag di ARIA adeguato. Per la maggior parte dei siti, questo può essere troppo penalizzante per il processo di sviluppo, anche se nella maggior parte dei CMS può essere automatizzato. In casi dove non lo può essere, se la definizione di un elemento HTML corrisponde al suo intento di utilizzo, allora può essere considerato a bassa priorità quando si effettuano le implementazioni di ARIA. Ecco come appare l'area del contenuto principale dopo aver effettuato tutte queste modifiche:

Barra laterale

La barra laterale di un sito può assumere molte forme. Nel nostro caso, fornisce contenuti aggiuntivi relazionati al sito, con una lista di post correlati in fondo.

Ecco il codice iniziale per la barra laterale:

Per definire il contenuto, vogliamo assegnargli il ruolo "complementary", consentendo agli utenti di sapere che le informazioni nella barra laterale sono contenuti aggiuntivi relativi al contenuto principale. Che può apparire come questo:

I post collegati sotto potrebbero essere considerati una forma di navigazione, consentendo agli utenti di esplorare ulteriormente i post del sito. Vogliamo assegnargli un ruolo di "navigation" e dargli un'etichetta appropriata, in questo modo:

La barra laterale di ogni sito è diversa e può richiedere una diversa combinazione di ruoli e punti di riferimento. Se la vostra sidebar ha un annuncio, allora è meglio non contrassegnare tale elemento. Se c'è un modulo di ricerca all'interno della barra laterale, allora contrassegnatela pure con il ruolo appropriato. Tutti i menu che vengono visualizzati in una barra laterale dovrebbero seguire lo stesso schema come abbiamo discusso nella sezione sulla navigazione:

  • un punto di riferimento "navigation"
  • un ruolo "menu" per il contenitore di menu
  • ruoli "menuitem" per ognuno degli elementi nidificati

Ecco come appare la nostra sidebar finale:

Gestione dei moduli di contatto

Infine, nella parte inferiore della nostra pagina è una forma di chiamata all'azione, chiedendo all'utente nome e indirizzo email, con un pulsante di invio standard sotto. Quando si tratta di moduli, ci sono tre parti da tenere a mente:

  1. Date al modulo il ruolo di punto di riferimento "form": dato che il modulo è una parte importante del sito, abbiamo bisogno di rendere più facile agli utenti arrivare ad esso. Lo facciamo dando un ruolo di riferimento

  2. Assegnate i ruoli corrispondenti agli elementi. I moduli sono un'area abituale dove gli scopi e le definizioni HTML sono disallineati. Aggiungete i ruoli ARIA dove necessario, soprattutto quando si tratta di caselle di controllo, barre di scorrimento, descrizioni comandi e altri elementi che possono essere implementati in più modi.

  3. Abbinate le etichette con gli elementi appropriati. HTML gestisce ciò in modo base, lasciandovi utilizzare l'elemento <label> per associare un'etichetta a un input. I moduli possono facilmente avere una struttura più complessa che ne impedisce il funzionamento; fortunatamente possiamo rimediare con l'attributo aria-labelledby.

Diamo un'occhiata a come appare il nostro codice aggiornato:

Testate la vostra implementazione

Con tutte le nostre implementazioni a posto, dobbiamo ora controllare che funzionino correttamente. Per fare questo, è più facile usare uno strumento di accessibilità esistente come gli strumenti di sviluppo di accessibilità di Google o il Plugin Dynamic Assistant di IBM.

Entrambi si integrano con gli strumenti per gli sviluppatori di Chrome per consentire l'ispezione in tempo reale dell'accessibilità del vostro sito. Il W3C mantiene anche una lista più grande di strumenti per l'accessibilità.

Rendere il Web più accessibile

Il wireframe del nostro sito ha ormai ARIA! Mentre c'è ancora un sacco di ARIA rimasta da esplorare, ora ne sapete abbastanza per rendere una gran parte dei siti su cui lavorate più accessibili. Oltre a ciò, il vostro sito è anche meglio preparato a gestire un numero qualsiasi di nuove tecnologie che attraversano internet che potrebbero presentarsi.

C'è qualche altro aspetto di ARIA che si vorreste farci esplorare? Avete domande su questo articolo? Sentitevi liberi di aggiungerle nei commenti qui sotto!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.