Una checklist breve e opinabile per pulsanti web accessibili

Il problema dei consigli sull'accessibilità dei pulsanti

La maggior parte delle indicazioni sull'accessibilità dei pulsanti rientra in due categorie: o è un'interpretazione di 40 pagine delle WCAG che nessuno legge, oppure è un suggerimento vago a "rendere i pulsanti accessibili" senza passaggi operativi. Nessuna delle due aiuta quando devi rilasciare una funzionalità giovedì.

Questa checklist copre i cinque problemi di accessibilità dei pulsanti più comuni che vediamo in produzione. Non ti renderà un esperto WCAG, ma intercetterà i problemi che incidono davvero sugli utenti.

1. Usa l'elemento button per i pulsanti

Se si comporta come un pulsante, dovrebbe essere un elemento <button>. Non un <div> con onclick, non uno <span> con role="button", non un <a> con href="#" e preventDefault.

L'elemento <button> ti offre gratuitamente navigazione da tastiera, gestione del focus e annunci per screen reader. Quando usi un <div>, stai ricostruendo tutto da zero — e lo farai in modo sbagliato.

L'unica eccezione: se l'azione porta a una nuova pagina o modifica l'URL, usa un elemento <a>. Link e pulsanti sono semanticamente diversi. Gli utenti di screen reader navigano per tipo di elemento e si aspettano che i pulsanti eseguano azioni e che i link navighino.

2. Rendi l'area attiva almeno 44×44 pixel

WCAG 2.5.5 (Level AAA) richiede che gli elementi interattivi abbiano una dimensione minima del target di 44×44 pixel CSS. Non riguarda la dimensione visiva — riguarda l'area cliccabile.

Puoi avere un piccolo pulsante visivo con padding adeguato, oppure puoi estendere l'area attiva con uno pseudo-elemento. Ciò che conta è che l'utente non debba mirare con precisione.

Utenti mobile, persone con disabilità motorie e chiunque usi un dispositivo in movimento mancheranno target piccoli. Un pulsante icona da 24×24 pixel può sembrare pulito, ma è un fallimento di usabilità.

3. Fornisci stati di focus visibili che non siano solo quelli predefiniti del browser

L'anello di focus predefinito del browser è meglio di niente, ma è incoerente tra browser e spesso invisibile su determinati sfondi. Ti serve uno stato di focus personalizzato che funzioni nel tuo design system.

Un buon indicatore di focus ha tre qualità:

• Contrasto elevato: almeno 3:1 rispetto ai colori adiacenti
• Offset visibile: non nascosto dal bordo o dallo sfondo del pulsante
• Forma coerente: gli utenti dovrebbero riconoscerlo come indicatore di focus in tutta l'interfaccia

Non rimuovere outline: none senza sostituirlo con qualcosa di migliore. E non rendere gli stati di focus così sottili da poterli vedere solo tu in condizioni di illuminazione perfette.

4. Scrivi etichette dei pulsanti che abbiano senso fuori contesto

Gli utenti di screen reader spesso navigano saltando da un pulsante all'altro. Quando lo fanno, ascoltano un elenco di etichette di pulsanti senza contesto circostante.

Un pulsante etichettato "Scopri di più" è inutile in quell'elenco. Lo stesso vale per "Clicca qui" o "Invia". L'etichetta dovrebbe descrivere l'azione: "Scarica la checklist di accessibilità", "Iscriviti agli aggiornamenti", "Elimina questo commento".

Se il tuo design richiede un'etichetta visiva breve, usa aria-label per fornire un'alternativa descrittiva. Ma la soluzione migliore è scrivere etichette che funzionino per tutti.

Per i pulsanti solo icona, aria-label è obbligatorio. Un pulsante con solo l'icona di una lente d'ingrandimento ha bisogno di aria-label="Search" o di un testo equivalente. L'icona non è accessibile agli screen reader.

5. Garantisci un contrasto cromatico sufficiente

WCAG 2.1 richiede un rapporto di contrasto di almeno 4,5:1 per il testo normale e 3:1 per il testo grande (18pt o 14pt in grassetto). Le etichette dei pulsanti sono di solito testo normale.

Testo grigio chiaro su un pulsante bianco non supera il requisito. Azzurro pallido su sfondo azzurro chiaro non lo supera. Queste combinazioni possono sembrare sofisticate, ma escludono utenti ipovedenti, daltonici o chiunque stia guardando lo schermo sotto una forte luce solare.

Usa un verificatore di contrasto durante la progettazione, non dopo il lancio. Correggere problemi di contrasto in produzione è costoso perché spesso richiede modifiche al design system.

Se lavori con strumenti di elaborazione delle immagini, l'elaborazione lato client può aiutare a preservare la privacy durante la generazione di asset visivi accessibili — in particolare quando testi combinazioni di colori o generi stati di anteprima.

Cosa non copre questa checklist

Questo elenco è deliberatamente incompleto. Non copre la semantica degli stati disabilitati, gli stati di caricamento, la gestione degli errori o pattern di pulsanti complessi come split button o trigger di menu a discesa. Quei pattern hanno bisogno di indicazioni proprie.

Inoltre non copre la questione più ampia di quando usare un pulsante rispetto ad altri elementi interattivi. Per quello, devi comprendere l'HTML semantico e l'albero di accessibilità — argomenti che meritano articoli dedicati.

Ciò che copre sono i risultati più immediati: gli errori che emergono in quasi ogni code review, che colpiscono il maggior numero di utenti e che sono più facili da correggere durante lo sviluppo.

Come integrarla nel tuo workflow

Le checklist di accessibilità funzionano solo se fanno parte del processo di sviluppo, non se vengono aggiunte dopo. Ecco come fare in modo che accada:

Nel design: aggiungi stati di focus e annotazioni sull'area attiva ai tuoi file di design. Non lasciare che siano gli sviluppatori a indovinarli.

Nella code review: controlla la presenza di elementi <button>, aria-label sui pulsanti solo icona e CSS per lo stato di focus. Sono elementi rapidi da individuare.

Nei test: attraversa l'interfaccia con la tastiera usando Tab. Se non riesci a raggiungere un pulsante o non riesci a vedere dov'è il focus, non ci riusciranno nemmeno i tuoi utenti.

Nella documentazione: includi i requisiti di accessibilità dei pulsanti nella tua libreria di componenti. Rendi più facile fare la cosa giusta che quella sbagliata.

Se stai facendo debug di problemi in produzione, gli strumenti per ispezionare header HTTP e redirect possono aiutarti a capire come le tecnologie assistive interpretano il tuo markup — in particolare quando risolvi problemi di gestione del focus dopo la navigazione.

Il costo di saltare questo lavoro

I pulsanti inaccessibili non falliscono solo la conformità WCAG — interrompono i workflow. Un utente che non può cliccare un pulsante di invio non può completare un modulo. Un utente che non può vedere gli stati di focus non può navigare con la tastiera. Un utente che non può distinguere il testo del pulsante dallo sfondo non può leggere l'etichetta.

Questi non sono casi limite. Circa il 15% della popolazione mondiale ha una qualche forma di disabilità, e le limitazioni temporanee (mouse rotto, luce solare intensa, tenere in braccio un bambino) prima o poi riguardano tutti.

La buona notizia è che l'accessibilità dei pulsanti è in gran parte un insieme di problemi già risolti. Non devi inventare nuovi pattern o aspettare il supporto dei browser. Devi solo usare correttamente la piattaforma e testare il tuo lavoro.

Punti chiave

• Usa elementi <button> per i pulsanti ed elementi <a> per la navigazione — la differenza semantica è importante per le tecnologie assistive
• Assicurati che le aree attive siano almeno 44×44 pixel CSS per supportare persone con disabilità motorie e utenti mobile
• Fornisci stati di focus visibili e ad alto contrasto che funzionino in tutto il tuo design system
• Scrivi etichette dei pulsanti che abbiano senso quando lette da sole e usa aria-label per i pulsanti solo icona
• Controlla il contrasto cromatico durante la progettazione, non dopo il lancio, per evitare costosi interventi successivi

FAQ

Q: Posso usare role="button" su un <div> se aggiungo gestori da tastiera?

A: Puoi, ma non dovresti. Dovrai gestire manualmente Enter, Space, gestione del focus e stati disabilitati — e inevitabilmente ti sfuggirà qualcosa. L'elemento <button> fa tutto questo correttamente per impostazione predefinita. Usalo.

Q: E i pulsanti che alternano uno stato, come un pulsante play/pausa?

A: Usa aria-pressed="true" o aria-pressed="false" per indicare lo stato corrente. Anche l'etichetta del pulsante dovrebbe riflettere l'azione che avverrà al clic ("Pausa" durante la riproduzione, "Play" quando è in pausa), non lo stato corrente. Gli utenti di screen reader devono sapere cosa farà il pulsante, non in quale stato si trova il sistema.

Q: I pulsanti disabilitati devono soddisfare i requisiti di contrasto?

A: WCAG 2.1 esenta i controlli disabilitati dai requisiti di contrasto (1.4.3), ma è un punto controverso. I pulsanti disabilitati con contrasto scarso sono difficili da percepire per tutti. Se mostri un pulsante disabilitato, rendilo leggibile. Meglio ancora, nascondilo o spiega perché è disabilitato.

Q: Come posso testare l'accessibilità dei pulsanti senza uno screen reader?

A: Usa la tastiera. Attraversa l'interfaccia con Tab e verifica di poter raggiungere ogni pulsante, vedere dov'è il focus e attivare i pulsanti con Enter o Space. Questo intercetta la maggior parte dei problemi. Per test più approfonditi, usa l'inspector di accessibilità in Chrome o Firefox DevTools per controllare ruolo e etichetta calcolati.

Q: Qual è la differenza tra aria-label e aria-labelledby?

A: aria-label fornisce direttamente una stringa di testo. aria-labelledby fa riferimento all'ID di un altro elemento il cui contenuto testuale diventa l'etichetta. Usa aria-labelledby quando il testo dell'etichetta esiste già altrove nel DOM. Usa aria-label quando devi fornire un'etichetta che non è visibile sullo schermo.

Fonti

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM