Normative

ARIA

Vedi anche: WAI-ARIA, Accessible Rich Internet Applications

Accessible Rich Internet Applications — una specifica W3C che definisce ruoli, stati e proprietà per rendere i controlli UI personalizzati accessibili alle tecnologie assistive.

WAI-ARIA — Accessible Rich Internet Applications — è una specifica W3C che colma un vuoto specifico: quando gli elementi HTML nativi non sono sufficienti a descrivere un controllo UI personalizzato, ARIA fornisce un vocabolario di ruoli, stati e proprietà comprensibile dalle tecnologie assistive (in particolare dagli screen reader).

Cosa è ARIA e cosa non è

ARIA è uno strato sovrapposto all’HTML. Non aggiunge comportamenti. Inserire role="button" su un <div> fa sì che lo screen reader lo annunci come pulsante, ma non rende il <div> raggiungibile con il focus, non aggiunge la gestione della tastiera e non aggiunge lo stile visivo. Tutto ciò deve essere aggiunto manualmente.

Questa è la fonte della maggior parte dei bug ARIA in produzione: gli sviluppatori aggiungono il ruolo e si fermano, poi pubblicano un «pulsante» che non risponde al tasto Invio o alla barra spaziatrice, non è raggiungibile con Tab e non ha un indicatore di focus.

La prima regola di ARIA

Se è possibile utilizzare un elemento HTML nativo con la semantica e il comportamento richiesti, è necessario farlo.

Ogni riga di ARIA che si scrive è una riga di semantica HTML che si è scelto di reimplementare a mano. <button> si annuncia già come pulsante, è raggiungibile con il focus, risponde a Invio e alla barra spaziatrice e ha un anello di focus — gratuitamente. <div role="button" tabindex="0"> con gestori di tastiera personalizzati consente di ottenere lo stesso risultato, ma in modo fragile e con più codice.

Le grandi categorie

ARIA definisce tre tipi di attributi:

  • Ruoli — cosa è l’elemento (role="button", role="dialog", role="navigation", role="alert"). La lista completa dei ruoli conta oltre 80 voci; la guida ARIA Authoring Practices Guide del W3C le raggruppa in ruoli landmark, ruoli widget e ruoli per la struttura del documento.
  • Stati — qual è la condizione attuale dell’elemento (aria-expanded="true", aria-checked="false", aria-disabled="true"). Gli stati cambiano a runtime.
  • Proprietà — quali sono le relazioni dell’elemento (aria-labelledby="title-id", aria-describedby="help-id", aria-controls="menu-id"). Le proprietà sono tipicamente statiche.

Le altre tre regole di ARIA

La sequenza in cinque regole del W3C, dopo «utilizzare HTML nativo quando possibile»:

  1. Non modificare la semantica nativa, a meno che non sia strettamente necessario. (<h1 role="button"> genera confusione negli screen reader riguardo alla natura dell’elemento — intestazione o pulsante.)
  2. Tutti i controlli ARIA interattivi devono essere utilizzabili con la tastiera.
  3. Non utilizzare role="presentation" o aria-hidden="true" su un elemento raggiungibile con il focus.
  4. Tutti gli elementi interattivi devono avere un nome accessibile.

Seguire queste cinque regole elimina oltre l’80% dei bug ARIA.

Dove cercare

Il riferimento operativo più utile è l’ARIA Authoring Practices Guide (APG), che fornisce pattern di implementazione completi per i widget più comuni — combobox, finestre di dialogo, treeview, schede — incluse le tabelle di interazione da tastiera ed esempi di DOM.