Pulsante ruolo ARIA: Guía Completa y Práctica

Il ruolo ARIA button è un ruolo ARIA che fa sì che le tecnologie di assistenza annuncino un contenitore generico come pulsante, ma non porta comportamento: è necessario aggiungere tabindex="0", gestire Invio e Spazio, e visualizzare lo stato con aria-pressed o aria-disabled. La specifica WAI-ARIA 1.2 definisce questo ruolo all’interno della categoria widget e la prima regola di ARIA consiglia di utilizzare un <pulsante> nativo sempre che sia possibile.

Il ruolo ARIA button appartiene alla tassonomia dei ruoli di WAI-ARIA, lo standard del W3C che descrive la semantica accessibile per le interfacce web. Quando un elemento riceve role="button", l’albero di accessibilità che costruisce i lettori dello schermo (NVDA, JAWS, VoiceOver, Narratore) smette di esporlo come un div o uno span generico e lo presenta come un controllo accessibile. La differenza è enorme per chi naviga con il lettore dello schermo: senza il ruolo, l’utente sente “gruppo” o semplicemente testo; con il ruolo, sente “pulsante” e sa di poterlo attivare.

La confusione abituale è che role="button" ha convertito un div in un pulsante funzionale. Non lo fa. Il ruolo cambia solo la semantica annunciata; il comportamento —ricevere il fuoco, rispondere alla tastiera, attivare l’azione— rimane responsabilità dello sviluppatore. Questa separazione tra semantica e comportamento è la ragione della maggior parte degli errori che derivano da questo ruolo.

WAI-ARIA è stata pubblicata come raccomandazione del W3C e la sua versione 1.2 è il riferimento vigente per ruoli, stati e proprietà. Il ruolo pulsante è uno dei ruoli del widget più antichi e stabili secondo le specifiche, presente da ARIA 1.0.

Quando si usa role=“button” e quando no

La prima regola di ARIA, riconosciuta nelle pratiche di autore di WAI-ARIA (WAI-ARIA Authoring Practices), è la seguente: se esiste un elemento HTML nativo con la semantica e il comportamento necessario, usalo. <pulsante> si trova il ruolo implicito, il fuoco tramite tastiera, l’attivazione con Invio e Spazio e lo stato disattivato. Reimplementare tutto questo con l’aria role role="button" è un lavoro extra e fonte di bug.

Esistono, tuttavia, scenari legittimi per il ruolo. Il più comune è quando il markup è condizionato dal framework o dal CMS e non è possibile introdurre un <pulsante> senza compromettere il layout o il JavaScript esistente. Altro caso è il componente che deve comportarsi come un pulsante ma la cui struttura interna richiede un contenitore specifico, come alcuni widget di terzi.

Correlato: UserWay — Widget di accessibilità con piano gratuito per empezar hoy mismo.

Un terzo scenario, il più discutibile, è uno degli elementi che hai un ruolo nativo distinto e devi presentarlo come pulsante. Qui conviene chiedersi se il disegno non sta forzando una semantica equivoca. Se sembra qualcosa, ma in realtà navighi in un’altra pagina, la correzione è un collegamento <a>, non un pulsante.

Situazione	Soluzione consigliata	Motivo
Azione nel formulario o interfaccia	<pulsante> nativo	Ruolo, fuoco e tastiera inclusi
Navigazione in un altro URL	<a href>	Semantica di collegamento corretta
Contenitore non modificabile	ruolo="pulsante" + teclado + stati	Unico caso in cui il ruolo è utile
Botón de alternancia (on/off)	<pulsante premuto aria>	Estado expuesto nativamente
Pulsante disabilitato	<pulsante disabilitato>	Stato e fuoco gestiti

Come implementare correttamente un pulsante con role=“button”.

Un pulsante basato su role="button" deve contenere quattro tasti: fuoco, testo, stato e nome accessibile. Omitir cualquiera de ellos produce un controllo que “parece” accessibile ma falla en pruebas reales.

Il fuoco è abilitato con tabindex="0", che inserisce l’elemento nell’ordine di tabulazione naturale. Nunca usa tabindex con valores positivos: alteran el orden de tabulación de toda la página y generan saltos impredecibles. Il valore “0” è quello corretto per gli elementi interattivi personalizzati.

Vale la pena dare un'occhiata: AudioEye — Accessibilità gestionale: automatizzazione combinata con revisione umana.

El teclado richiede manejar dos teclas: Enter y Espacio. Un <button> nativo risponde a ambas, ma un div con un’aria di ruolo del pulsante non lo fa da solo. Hay que escuchar keydown y ejecutar la acción quando la tecla è Enter o Space, evitando además el desplazamiento de página que provoca Espacio por defecto. Este detalle se pasa por alto con frecuencia y deja botones que funcionan solo con ratón.

Lo stato comunica con gli attributi ARIA. Un pulsante di alternanza usa aria-pressed="true" o "false" per indicare se sei attivo. Un pulsante disattivato utilizza aria-disabled="true", che annuncia lo stato ma non ostacola l’interazione da solo: è necessario bloccare l’azione sul codice. La differenza tra “aria-disabled” e l’attributo nativo “disabled” è importante, poiché il primo mantiene l’elemento focalizzabile e il secondo lo spazio dell’ordine di tabulazione.

Il nome accessibile viene costruito con il testo visibile dell’elemento o, se non c’è testo, con aria-label o aria-labelledby. Un pulsante senza nome accessibile è un pulsante che il lettore dello schermo pronuncia come “pulsante” a secondi, senza traccia di ciò che ha fatto.

<div
  ruolo="pulsante"
  tabindice="0"
  aria-pressed="falso"
  id="btn-modo"
>
  Modo oscuro
</div>

<copione>
  const btn = document.getElementById('btn-modo');
  funzione alterna() {
    const activo = btn.getAttribute('aria-pressed') === 'true';
    btn.setAttribute('aria-pressed', String(!activo));
  }
  btn.addEventListener('clicca', attiva/disattiva);
  btn.addEventListener('keydown', (e) => {
    if (e.tasto === 'Invio' || e.tasto === ' ') {
      e.preventDefault();
      alterna();
    }
  });
</script>

El ejemplo anterior cubre foco, teclado, estado y nombre. È il minimo vitale affinché il controllo sia utilizzabile con il lettore di schermo e tastiera.

Errori frequenti e come rilevarli

L’errore più esteso viene applicato a role="button" senza tabindex, per cui viene prodotto un pulsante non selezionabile tramite teclado. Gli strumenti automatici lo rilevano come “elemento con ruolo interattivo non focalizzabile”, una delle violazioni più segnalate negli auditorium di accessibilità.

Il secondo errore non è gestire il teclado. Un div con un’aria role de botón e tabindex ma senza manejadores de tecla recibe foco e nessuna risposta a Enter ni Espacio. L’utente della tastiera si è bloccato: è possibile premere il pulsante ma non attivarlo.

Correlato: IAAP CPACC / WAS Certification — La certificazione professionale che accredita la tua esperienza di accessibilità.

Il terzo errore è usare role="button" su un collegamento. Questo rompe la semantica di navigazione e confonde i lettori dello schermo, che pronunciano il “pulsante” quando l’utente aspetta un collegamento. Se l’elemento naviga, deve essere un collegamento.

El quarto error è olvidar el estado en botones de alternancia. Un pulsante che cambia tra due modalità senza “aria-pressed” lascia l’utente senza sapere quale stato si trova. L’attributo è l’unico modo per comunicare questo stato in forma programmatica.

Per rilevare questi problemi, gli strumenti automatici come ascia, Lighthouse o WAVE segnalano le violazioni del ruolo e del fuoco, ma non convalidano né il comportamento del teclado né la logica dello stato. Esa parte exige prueba manual: navegar con Tab, activar con Enter y Espacio, y escuchar la salida del lector de pantalla. La combinazione di uditorio automatico e prova manuale è l’unica forma affidabile per convalidare un pulsante personalizzato.

Se stai facendo acquisti: accessiBe — Sovrapposizione di IA che promette il completamento del WCAG in 48 ore.

Come provare un pulsante con role=“pulsante”

La prova empieza por el teclado. Ricorre la pagina con Tab e controlla che il pulsante con il ruolo dell’aria pulsante recibe foco sia visibile. Pulsa Enter e Espacio por separado: ambos deben disparar la acción. Se Espacio sposta la pagina nel punto in cui si attiva il pulsante, non viene visualizzato preventDefault.

La seconda prova è con lettore di schermo. NVDA su Windows, VoiceOver su macOS e Assistente vocale su Windows sono i riferimenti più utilizzati. Quando si attiva il pulsante, il lettore deve pronunciare il ruolo (“pulsante”), il nome accessibile e lo stato se lo tiene. Si anuncia “grupo” o no menciona el estado, algo falla.

La terza prova è de orden de foco. Il pulsante deve apparire nell’ordine logico della tabulazione, né prima né dopo dove corrisponde visivamente. I positivi del tabindex rompono questo ordine e sono un indicatore chiaro di cattiva implementazione.

La cuarta prueba es de contraste y foco visibile. L’indicatore di fuoco non deve essere eliminato con outline: none senza sostituirlo con un’alternativa visibile. Un pulsante che ricevi fuoco ma non lo mostra deja al utente del teclado senza riferimento a dove si trova.

Pulsante alternative moderne al ruolo

L’elemento "" nativo continua a essere la migliore opzione nel 2024 e in qualsiasi nuovo progetto. Aporta rol, foco, teclado y estados sin código adicional, e los navegadores lo tratan de forma consistente.

Gli elementi personalizzati o i componenti Web sono stati offerti altrove. Un componente che estende HTMLElement può incapsulare il comportamento del pulsante ed esponerlo con la semantica corretta, anche se è necessario gestire manualmente il fuoco e la tastiera uguali a role="button". La vendita è la riutilizzazione; lo svantaggio, la misma responsabilità di implementazione.

Las ARIA in HTML (regole che definiscono il modo in cui i ruoli ARIA sono consentiti su ciascun elemento HTML) disattivano la scrittura dei ruoli nativi. Applicare l’aria role role="button" a un <button> è ridondante; applicarlo a un <a> con href è controproducente. La raccomandazione generale è prenotare il ruolo per i contenitori senza semantica propria.

Punti chiave

• role="button" cambia solo la semantica annunciata; el foco, el teclado y el estado hay que implementarlos a mano.
• La prima regola di ARIA consiglia di utilizzare <button> nativo sempre che il contrassegno lo permetta.
• Un botón con aria role button necesita tabindex="0", manejo de Enter y Espacio, nome accessibile e stato con aria-pressed o aria-disabled.
• Las herramientas automáticas discoveran la falta de foco, pero el comportamiento de teclado y estado exige prueba manual con lector de pantalla.
• Nunca usa tabindex positivo ni apliques role="button" sobre enlaces que navegan.

Domande frequenti

Qual è la differenza tra role=“button” e l’elemento button?

L’elemento "" nativo include il ruolo implicito, il fuoco tramite tastiera, l’attivazione con Invio e Spazio e lo stato disattivato senza codice aggiuntivo. L’attributo role="button" porta solo la semantica annunciata; il resto del comportamento deve essere programmato. Per questo la prima regola di ARIA consiglia l’elemento nativo sempre che sia possibile.

¿Necessario tabindex con role=“button”?

Sì. Un div o span con role="button" non è impostabile per difetto, poiché il tabindex="0" è fuori dall’ordine di tabulazione ed è inalcabile con il comando teclado. Il valore corretto è “0”; i valori positivi alterano l’ordine di tabulazione di tutta la pagina e devono essere evitati.

Come faccio a rispondere a Enter e Espacio con un div con role=“button”?

È necessario selezionare l’evento “keydown” ed eseguire l’azione quando il tasto è “Invio” o “Spazio”. Nel caso di Spazio è possibile chiamare preventDefault per evitare lo spostamento della pagina. Sin estos manejadores, el botón recibe foco ma no se activa con teclado.

Come indicare che un pulsante è attivo o disabilitato?

Per un pulsante di alternanza utilizzare aria-pressed="true" o "false" a seconda dello stato. Per disattivare il pulsante, utilizzare aria-disabled="true", annunciando lo stato, ma non bloccare l’interazione solo per sé: ciò impedisce l’azione sul codice. L’attributo nativo disabled è preferibile quando si utilizza un <button>.

È mala pratica usare role=“button” in un collegamento?

Sì, quando il collegamento viene inviato a un altro URL. Soscrivere il ruolo di un <a href> con role="button" rompe la semantica di navigazione e confonde i lettori dello schermo, che pronunciano “botón” quando l’utente aspetta un collegamento. Se l’elemento naviga, è necessario conservare il ruolo di collegamento.

¿Qué gli strumenti rilevano errori con role=“button”?

Gli strumenti automatici come axe, Lighthouse o WAVE segnalano violazioni come la mancanza di fuoco negli elementi con ruolo interattivo. Tuttavia, non convalidare il comportamento della tastiera o la logica dello stato, quindi la verifica affidabile combina l’auditorium automatico con la prova manuale utilizzando NVDA, VoiceOver o l’Assistente vocale.