Come smettere di indovinare quando si costruiscono interfacce accessibili
Ti sei mai chiesto perché un normale pulsante sul web a volte si comporta in modo strano quando provi a cliccarlo con la tastiera? O perché uno screen reader improvvisamente inizia a blaterare sciocchezze quando apri un modal? Di solito il problema è con gli attributi ARIA. Siamo abituati ad aggiungerli "a occhio", sperando che aria-label o role="button" risolvano magicamente una cattiva semantica. Ma l'accessibilità non è magia — sono pattern di interazione rigorosi.
Nel repository w3c/aria-practices si trova quello che chiamo la "bibbia dello sviluppatore frontend". Non è una semplice specifica noiosa, ma una guida pratica vivente (APG) che spiega esattamente come dovrebbero funzionare dropdown, tab, slider e accordion affinché chiunque possa utilizzarli.
Di cosa tratta questo progetto
Il progetto è gestito da un gruppo di lavoro del W3C. In sostanza, sono le persone che inventano gli standard web. Nel repository raccolgono esempi di riferimento per l'implementazione dei pattern di interfaccia. Se non sai se il focus dovrebbe tornare al pulsante dopo la chiusura di un modal, o quali tasti freccia dovrebbero cambiare i tab — è qui che devi guardare.
Molti sviluppatori considerano ancora l'accessibilità (a11y) qualcosa di opzionale. Ma quando un progetto cresce, la mancanza di una corretta navigazione da tastiera diventa debito tecnico. Questo repository aiuta a eliminare quel debito già nella fase di progettazione dei componenti.
Cosa offre questo repository
All'interno troverai non solo regole secche, ma esempi di codice funzionanti. Ecco alcune cose a cui faccio costantemente riferimento in questo progetto.
Pattern di progettazione pronti all'uso
Per ogni elemento complesso (ad esempio, Combobox o Tree View), c'è una sezione separata. Descrive il comportamento previsto della tastiera e i ruoli richiesti. Questo elimina la necessità di reinventare la ruota. Devi solo prendere la lista dei requisiti e verificare il tuo componente rispetto ad essi.
Esempi di codice di riferimento
Nella cartella examples ci sono implementazioni in puro HTML, CSS e JavaScript. Non ci sono astrazioni inutili, React o Vue — solo la logica di accessibilità pura. Questo è utile quando devi capire come collegare gli elementi id tramite aria-controls o aria-labelledby affinché lo screen reader annunci correttamente il contesto.
Testing e linting
Interessante: gli autori usano un linting rigoroso. Validano l'HTML attraverso NU HTML Validator e JS e CSS attraverso ESLint e Stylelint standard. Se decidi di contribuire al progetto, dovrai installare il JDK per il validatore HTML. Questo dimostra il livello di serietà: anche negli esempi di codice, non è permesso nemmeno un errore di validazione.
Come usare questo nel tuo lavoro
Uso spesso questo repository come lista di controllo. Ad esempio, sto scrivendo un select personalizzato. Invece di cercare su Google "come fare un select accessibile", vado su APG e guardo la sezione Select-Only Combobox.
Lì trovo:
- Quali attributi servono all'elemento genitore.
- Come gestire lo stato
aria-expanded. - Cosa dovrebbe succedere premendo i tasti Home, End o PageUp.
A proposito, il repository ha script per il testing automatizzato degli esempi. Il comando npm test esegue test che verificano il comportamento degli elementi nel browser. Questo è un ottimo esempio di come puoi automatizzare i test di accessibilità nei tuoi progetti.
Il lato tecnico
Il progetto funziona con Node.js. Per lavorare localmente, avrai bisogno di:
- Node.js e npm per eseguire linter e test.
- JDK (Java Development Kit) per la validazione HTML.
Punto interessante: il progetto ha la correzione automatica degli errori configurata al commit. Se hai sbagliato gli spazi nel CSS o dimenticato camelCase in JavaScript, il linter proverà a correggerlo da solo prima di far entrare il codice nel repository.
Chi dovrebbe dare un'occhiata ad aria-practices
Prima di tutto — gli sviluppatori di librerie di componenti. Se stai scrivendo il tuo design system, ignorare queste pratiche semplicemente non è un'opzione. Il progetto è utile anche per gli ingegneri QA: puoi trovare qui esattamente come un'interfaccia dovrebbe comportarsi durante il test dell'accessibilità.
Non dirò che leggere questo repository sia un intrattenimento serale leggero. I testi sono secchi e ci sono molti requisiti. Ma è l'unico modo per costruire interfacce che funzionino davvero per tutti, non solo per chi usa il mouse.
Se sei stanco dei tuoi modal che "volano" alla fine della pagina quando vengono chiusi, o vuoi finalmente capire a cosa serve aria-live, clona questo repository e guarda come lo fanno i professionisti del W3C. Link al progetto: w3c/aria-practices.
Progetti correlati