HTML semantico

L’HTML semantico è un HTML in cui ogni elemento viene scelto per il suo significato, non solo per la sua apparenza. Un <button> è destinato alle azioni. Un <nav> racchiude la navigazione. Un <table> contiene dati tabulari. Usare un <div> stilizzato per sembrare un pulsante costituisce un errore semantico — anche se il risultato visivo è identico.

La grande maggioranza dei bug di accessibilità è riconducibile all’abbandono della semantica. Quasi ogni guasto nelle tecnologie assistive ha la stessa causa principale: un elemento generico che svolge il compito per cui era stato progettato un elemento semantico.

Perché gli screen reader dipendono dalla semantica

Gli screen reader espongono l’HTML all’utente attraverso il loro albero di accessibilità — una rappresentazione interna costruita a partire dal DOM che associa ogni elemento a un ruolo, un nome, uno stato e delle proprietà. L’albero di accessibilità è ciò che l’utente ascolta effettivamente.

Un <button> nativo entra nell’albero di accessibilità come button "Invia". Un <div> stilizzato per sembrare un pulsante entra come generic — il che significa che lo screen reader non annuncia nulla di utile e l’utente non ha modo di scoprire che il div è interattivo.

La stessa logica si applica a:

• I titoli (<h1>–<h6>) — gli screen reader consentono agli utenti di spostarsi tra i titoli per scorrere una pagina. Un <div class="heading"> non compare nell’elenco dei titoli.
• Le liste (<ul>, <ol>, <li>) — gli screen reader annunciano «lista, 5 elementi» prima della lettura. I <div> che simulano voci di elenco non lo fanno.
• I moduli — un <input> collegato a un <label> viene letto come «Email, campo di testo». Un campo personalizzato costruito con div e contenteditable non legge nulla.
• Le tabelle — una <table> con intestazioni di riga e colonna <th> consente agli utenti di navigare celle per cella con il contesto dell’intestazione annunciato. Le griglie CSS di div non lo consentono.

Il pattern di sostituzione

La soluzione ha quasi sempre la stessa forma:

• <div onclick="..."> → <button> (oppure <a href> per la navigazione).
• <span class="link"> → <a href>.
• <div role="heading"> → da <h1> a <h6>.
• Dropdown personalizzati → <select> dove il design lo consente, oppure una combobox ARIA testata secondo i pattern stabiliti dove non è possibile.
• Tab realizzate con <div> stilizzati → pattern tab dalla ARIA Authoring Practices Guide.

Quando ricorrere ad ARIA

La prima regola di ARIA recita: non usare ARIA se un elemento nativo svolge il compito. I ruoli, gli stati e le proprietà ARIA sono una patch per i casi in cui l’HTML nativo non è in grado di descrivere il widget che si sta costruendo (alberature, combobox a selezione multipla, certi pattern modali). Non sono un sostituto all’uso di <button>.

Un audit pragmatico

Il modo più rapido per individuare il degrado semantico in un codebase: cercare onclick su div e span. Ogni corrispondenza è un potenziale problema. Il secondo modo più rapido: cercare gli attributi role=. ARIA è appropriato in contesti limitati, ma un uso massiccio di ARIA spesso segnala che gli elementi nativi sono stati evitati per ragioni stilistiche che in realtà non lo richiedevano.