L'accessibilita web spesso viene raccontata come un tema enorme, tecnico e pieno di sigle. In parte lo e: ci sono standard, criteri, tecnologie assistive, casi d'uso diversi e responsabilita reali.

Pero per iniziare bene non serve sapere tutto. Serve capire il modello mentale giusto e applicare poche abitudini concrete mentre scrivi HTML, CSS e JavaScript.

Questa guida non sostituisce le WCAG e non e una certificazione. E una base pratica per evitare gli errori piu comuni: div usati come bottoni, focus invisibile, form senza label, immagini senza descrizione utile, testo poco leggibile, layout mobile faticosi e ARIA usata come toppa casuale.

Il punto e semplice: una pagina accessibile non e una pagina "speciale". E una pagina fatta meglio. Funziona meglio con tastiera, screen reader, zoom, mobile, connessioni lente, distrazioni, stanchezza e situazioni reali.

Accessibilita web significa progettare e sviluppare contenuti che possano essere percepiti, compresi e usati dal maggior numero possibile di persone, anche quando usano modalita diverse dalla tua.

Non riguarda solo chi usa uno screen reader. Riguarda anche chi naviga con la tastiera, chi ha bassa vista, chi non distingue bene alcuni colori, chi usa lo zoom, chi ha difficolta motorie, chi e in un ambiente rumoroso, chi consulta il sito da mobile o chi semplicemente e stanco e vuole capire subito cosa fare.

La cosa importante e questa: l'accessibilita non arriva alla fine come "controllo extra". Entra nelle decisioni base:

• quale elemento HTML scelgo?
• il contenuto ha una gerarchia chiara?
• un bottone si puo usare anche senza mouse?
• un errore del form viene spiegato bene?
• il testo resta leggibile su mobile e con zoom?
• un'immagine importante ha una descrizione utile?

Quando prendi queste decisioni bene, migliori la vita a molte persone e spesso rendi il codice piu pulito.

Una definizione pratica

Una pagina accessibile e una pagina che non obbliga l'utente a usare un solo modo di interazione.

Se puoi leggere, ascoltare, ingrandire, navigare con tastiera, capire gli errori, distinguere i controlli e completare il flusso principale, sei gia molto piu vicino a un'interfaccia rispettosa.

Le WCAG sono le linee guida internazionali piu importanti per l'accessibilita dei contenuti web. Per iniziare, la cosa piu utile non e memorizzare tutti i criteri, ma capire i quattro principi.

Percepibile

Le informazioni devono essere disponibili in modi che l'utente possa percepire: testo leggibile, alternative per immagini, contrasto, contenuti non affidati solo al colore.

Utilizzabile

L'interfaccia deve poter essere usata: tastiera, focus visibile, controlli raggiungibili, nessuna trappola di navigazione.

Comprensibile

Contenuti, etichette, messaggi ed errori devono essere chiari e prevedibili.

Robusto

Il codice deve essere abbastanza solido da funzionare con browser, tecnologie assistive e strumenti diversi.

Questa bussola e potente: quando non sai se una scelta e buona, chiediti quale principio sta aiutando o danneggiando.

Il modo piu semplice per migliorare l'accessibilita e usare l'HTML giusto prima di inventare soluzioni complicate.

HTML non serve solo a "far vedere cose". Comunica significato: un bottone e un'azione, un link porta altrove, un titolo organizza il contenuto, una label descrive un input, una nav raccoglie link di navigazione.

<header>
  <nav aria-label="Navigazione principale">
    <a href="/">Home</a>
    <a href="/tutorial/">Tutorial</a>
  </nav>
</header>

<main>
  <h1>Accessibilita web base</h1>
  <section>
    <h2>HTML semantico</h2>
    <p>Il contenuto principale della sezione.</p>
  </section>
</main>

Questo codice e piu chiaro per browser, sviluppatori e tecnologie assistive rispetto a una lunga serie di <div> senza significato.

Heading: non sono solo dimensioni

Gli heading creano la mappa del contenuto. Non usarli solo per ottenere un font piu grande.

• usa un H1 principale per il tema della pagina;
• usa H2 per i blocchi principali;
• usa H3 per sotto-sezioni interne;
• non saltare livelli solo per estetica;
• non trasformare ogni frase evidenziata in heading.

Se la gerarchia dei titoli e leggibile, anche la pagina diventa piu scansionabile.

Landmark utili

Elementi come <header>, <main>, <nav>, <footer> e <aside> aiutano a capire le zone della pagina.

Non servono per decorare il markup: servono a orientarsi. Una pagina con un solo <main>, una navigazione chiara e sezioni ordinate e gia molto piu solida.

Un errore molto comune e usare link e bottoni come se fossero intercambiabili. Non lo sono.

<a href="/tutorial/">Vai ai tutorial</a>

<button type="button">Apri menu</button>

Se usi un <div> cliccabile al posto di un bottone, perdi comportamento nativo, focus, semantica e spesso anche supporto da tastiera.

Testo dei link

Il testo di un link deve avere senso anche fuori contesto. "Clicca qui" non dice nulla.

• <a href="/tutorial/seo-tecnico-base/">SEO tecnico base</a>
• <a href="/contatti/">Contatta Codedge</a>

• <a href="/tutorial/seo-tecnico-base/">leggi qui</a>
• <a href="/contatti/">clicca</a>

Un link chiaro aiuta persone, screen reader e anche la comprensione generale del percorso.

Una pagina dovrebbe essere usabile anche senza mouse. Questo e uno dei controlli piu semplici e rivelatori.

Apri la pagina, appoggia il mouse, premi Tab e prova a usare tutto cio che conta: menu, link, bottoni, form, modali, card interattive.

• l'ordine di focus segue il percorso visivo e logico;
• ogni controllo interattivo riceve focus;
• il focus e visibile;
• Enter e Space funzionano dove ci si aspetta;
• non rimani intrappolato in componenti custom;
• puoi chiudere menu o modali senza mouse.

Non eliminare il focus

Questo e uno degli errori peggiori:

*:focus {
  outline: none;
}

Se togli l'outline senza sostituirlo con uno stato visibile, chi naviga da tastiera non sa piu dove si trova.

Meglio creare un focus coerente con il design:

a:focus-visible,
button:focus-visible,
input:focus-visible {
  outline: 3px solid #7ddcff;
  outline-offset: 3px;
}

Tabindex: poco e con criterio

tabindex="0" puo rendere focusabile un elemento quando serve davvero. tabindex="-1" puo essere utile per portare focus via script su un contenitore o messaggio.

Evita invece tabindex="1", tabindex="2" e simili: creano ordini artificiali difficili da mantenere.

L'attributo alt non e una descrizione obbligatoria da riempire sempre nello stesso modo. E un'alternativa testuale quando l'immagine porta informazione.

La domanda utile e: se questa immagine non si vede, quale informazione perde l'utente?

<img
  src="/images/percorsi-apprendimento/accessibilita-web-base/panoramica-accessibilita-web-base.svg"
  alt="Panoramica dei quattro principi dell'accessibilita web: percepibile, utilizzabile, comprensibile e robusto"
  width="1200"
  height="520">

Tre casi comuni

Immagine informativa

Scrivi un alt che trasmette il significato essenziale, non ogni dettaglio decorativo.

Immagine decorativa

Usa alt="", cosi viene ignorata dalle tecnologie assistive.

Immagine-link

L'alt deve spiegare la destinazione o l'azione, non descrivere solo l'immagine.

Errori da evitare

• alt="immagine", perche non comunica nulla;
• keyword stuffing dentro l'alt;
• alt lunghissimi che ripetono tutto il testo vicino;
• lasciare senza alt immagini che sono contenuto vero;
• descrivere icone decorative che non aggiungono informazione.

Il colore aiuta, ma non deve essere l'unico modo per capire qualcosa.

Se un errore e indicato solo con il rosso, chi non distingue bene quel colore potrebbe non capirlo. Aggiungi testo, icone sensate, bordi, messaggi e stati chiari.

• testo e sfondo devono avere contrasto sufficiente;
• link e bottoni devono essere distinguibili;
• stati hover, focus, active ed error devono essere riconoscibili;
• non comunicare informazioni solo con il colore;
• il testo deve restare leggibile su mobile e con zoom.

Leggibilita pratica

La leggibilita non e solo contrasto. Conta anche quanto e faticoso leggere.

• usa righe non troppo lunghe;
• mantieni spaziatura sufficiente;
• evita blocchi enormi senza sottotitoli;
• non ridurre troppo il font nei pannelli compatti;
• non affidarti a placeholder o testo grigio chiaro per informazioni importanti.

I form sono uno dei punti in cui l'accessibilita diventa molto concreta. Se un utente non capisce cosa compilare o non capisce l'errore, il flusso si rompe.

La base minima:

• ogni input importante ha una <label> collegata;
• placeholder e label non sono la stessa cosa;
• gli errori sono scritti in modo chiaro;
• il messaggio di errore e vicino al campo;
• non indicare errori solo con colore;
• il submit non cancella dati senza avviso.

<label for="email">Email</label>
<input
  id="email"
  name="email"
  type="email"
  autocomplete="email"
  aria-describedby="email-help email-error">
<p id="email-help">Useremo questa email solo per rispondere.</p>
<p id="email-error">Inserisci un indirizzo email valido.</p>

Label, placeholder e istruzioni

Il placeholder sparisce quando inizi a scrivere e spesso ha contrasto piu basso. Non usarlo come unica etichetta.

• <label for="nome">Nome</label>
• <input id="nome" name="nome" autocomplete="given-name">

• <input placeholder="Nome"> come unica indicazione;
• messaggi tipo Errore senza spiegazione;
• campi obbligatori non dichiarati chiaramente.

ARIA serve ad aggiungere informazioni di accessibilita quando l'HTML nativo non basta, soprattutto in componenti dinamici o custom.

La regola piu importante e semplice: se puoi usare un elemento HTML nativo con semantica e comportamento gia corretti, usa quello.

• <button type="button">Apri menu</button>
• <nav aria-label="Navigazione principale">...</nav>
• <label for="email">Email</label>

• <div role="button">Apri menu</div> senza comportamento da bottone;
• <span onclick="...">Invia</span> al posto di un bottone;
• aggiungere ruoli ARIA a caso per "migliorare" elementi gia corretti.

Quando ARIA aiuta davvero

ARIA puo essere utile per:

• comunicare stato aperto/chiuso con aria-expanded;
• collegare descrizioni con aria-describedby;
• etichettare regioni o navigazioni con aria-label;
• annunciare aggiornamenti dinamici con live regions;
• costruire widget complessi quando non esiste un elemento nativo sufficiente.

Pero ARIA non aggiunge automaticamente interazioni da tastiera. Se trasformi un <div> in bottone con role="button", devi comunque gestire focus, Enter, Space e stati. Per questo di solito e meglio usare un vero <button>.

Responsive accessibile

Un layout responsive non e automaticamente accessibile. Deve restare usabile quando cambia schermo, zoom, orientamento o densita del contenuto.

• il testo non si sovrappone;
• i target touch sono comodi;
• il menu mobile funziona con tastiera e focus;
• non spariscono contenuti importanti;
• lo zoom non rompe layout e navigazione;
• l'ordine visivo e l'ordine del DOM restano coerenti.

Motion e animazioni

Le animazioni possono migliorare l'esperienza, ma non devono rendere la pagina difficile da usare.

Se usi movimenti importanti, considera prefers-reduced-motion:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms;
    animation-iteration-count: 1;
    scroll-behavior: auto;
  }
}

Non serve togliere ogni micro-interazione. Serve evitare movimento eccessivo, obbligatorio o impossibile da fermare.

Contenuto chiaro

Accessibilita e anche scrittura. Un'interfaccia con testi vaghi, errori criptici e call to action ambigue crea barriere.

• usa titoli che spiegano davvero la sezione;
• scrivi bottoni con azioni chiare;
• spiega cosa succede dopo un invio;
• evita messaggi generici come "qualcosa e andato storto" quando puoi aiutare di piu;
• mantieni coerenza tra etichette, link e destinazioni.

Controllo rapido

• la pagina ha un H1 chiaro e heading ordinati;
• usi elementi HTML nativi quando esistono;
• link e bottoni hanno ruoli coerenti;
• la navigazione con Tab funziona;
• il focus e sempre visibile;
• le immagini informative hanno alt utili;
• le immagini decorative hanno alt="";
• testo e controlli hanno contrasto sufficiente;
• i form hanno label, istruzioni ed errori chiari;
• il layout resta usabile su mobile e con zoom;
• ARIA e usata solo quando serve davvero;
• la pagina si puo completare senza mouse.

Test manuale in 5 minuti

1. Apri la pagina.
2. Premi Tab e segui il focus.
3. Apri menu, link, bottoni e form senza mouse.
4. Aumenta lo zoom del browser.
5. Controlla mobile o viewport stretto.
6. Leggi la pagina guardando solo titoli, link e messaggi.
7. Verifica che gli errori dei form siano comprensibili.

Questo non sostituisce test professionali, screen reader, audit completi o validazioni WCAG. Pero intercetta molti problemi prima che arrivino online.

Da qui in poi

Se capisci questa base, inizi a progettare componenti meno fragili. Non stai solo "facendo accessibilita": stai scegliendo HTML piu corretto, interazioni piu prevedibili, messaggi piu chiari e pagine piu resistenti.

Per continuare il percorso, queste guide si collegano bene:

• SEO tecnico base: per collegare accessibilita, leggibilita tecnica e qualita della pagina pubblicata.
• Browser e DevTools: per controllare DOM, CSS applicato, console e comportamento reale.
• VSCode essenziale: per lavorare con piu ordine su file, problemi e routine.
• Deploy base: per pubblicare e verificare la versione davvero online.
• Tutti i tutorial: per seguire gli altri contenuti disponibili.

Fonti utili da consultare quando vuoi approfondire: W3C WAI Accessibility Fundamentals, WCAG 2.2 Quick Reference, overview WCAG del W3C e Using ARIA.