Accessibilità Web: I Controlli da Applicare Durante lo Sviluppo

L’accessibilità web durante lo sviluppo non dovrebbe essere considerata un controllo da eseguire soltanto quando il sito è terminato. Molti problemi nascono infatti nelle prime decisioni: struttura HTML, componenti interattivi, colori, moduli, navigazione, immagini e organizzazione dei contenuti.

Correggere questi aspetti alla fine del progetto può richiedere la modifica del tema, dei template, dei plugin e dei contenuti già pubblicati. Integrarli durante lo sviluppo permette invece di costruire una base più ordinata e utilizzabile.

Un sito accessibile non è destinato soltanto a chi utilizza uno screen reader. Deve poter essere consultato anche da chi naviga con la tastiera, ingrandisce il testo, utilizza uno schermo piccolo, ha difficoltà visive, motorie, cognitive o si trova temporaneamente in una condizione che limita l’interazione.

Durante lo sviluppo non cerco quindi di applicare una serie di correzioni isolate. Controllo che struttura, contenuti e funzionalità possano essere utilizzati in modi differenti senza perdere informazioni o operazioni essenziali.

Accessibilità Web Durante lo Sviluppo

L’accessibilità riguarda il modo in cui una persona può:

• percepire i contenuti;
• comprendere la struttura della pagina;
• raggiungere menu e funzioni;
• utilizzare moduli e pulsanti;
• leggere testi e messaggi;
• controllare audio, video e animazioni;
• completare un’operazione;
• riconoscere e correggere un errore.

Le WCAG organizzano i requisiti intorno a quattro principi: il contenuto deve essere percepibile, utilizzabile, comprensibile e sufficientemente robusto da poter funzionare con browser e tecnologie assistive differenti.

Questi principi non riguardano soltanto la grafica. Coinvolgono progettazione, sviluppo, scrittura, pubblicazione dei contenuti e manutenzione.

Non Rimandare Tutto alla Fine del Progetto

Uno degli errori più frequenti consiste nello sviluppare l’intero sito e avviare i controlli di accessibilità soltanto prima della pubblicazione.

A quel punto possono essere già stati realizzati:

• menu non utilizzabili da tastiera;
• finestre modali senza gestione del focus;
• moduli privi di etichette;
• palette con contrasto insufficiente;
• componenti costruiti con elementi HTML non adatti;
• gerarchie dei titoli incoerenti;
• slider e animazioni non controllabili;
• template che non permettono testi alternativi corretti;
• plugin che generano codice difficile da modificare.

La correzione diventa più costosa perché il problema non appartiene più a un singolo elemento. È stato ripetuto in tutte le pagine che utilizzano lo stesso componente.

Il W3C raccomanda di valutare l’accessibilità fin dalle prime fasi e durante tutto il processo di sviluppo, quando gli errori sono più facili da individuare e correggere.

Partire da una Struttura HTML Semantica

La prima base è utilizzare elementi HTML coerenti con la funzione svolta.

Un titolo dovrebbe essere un’intestazione, un pulsante dovrebbe essere un pulsante e una navigazione dovrebbe essere identificata come tale.

L’HTML semantico permette al browser e alle tecnologie assistive di comprendere:

• quali elementi sono interattivi;
• come possono essere attivati;
• quali parti costituiscono la pagina;
• quali testi sono titoli;
• quali elementi appartengono a un elenco;
• come sono organizzati i dati;
• quale funzione svolge un controllo.

Ricreare con elementi generici un comportamento già disponibile in HTML richiede l’aggiunta manuale di interazioni, ruoli, stati e gestione della tastiera.

Usare Pulsanti e Link per la Funzione Corretta

Un link conduce normalmente a un’altra risorsa o a una sezione della pagina. Un pulsante esegue invece un’azione, come aprire un menu, inviare un modulo o mostrare una finestra.

Una struttura corretta può essere:

Utilizzare un elemento generico come un div e attribuirgli graficamente l’aspetto di un pulsante non gli assegna automaticamente il comportamento previsto.

Per renderlo equivalente sarebbe necessario gestire focus, attivazione da tastiera, nome accessibile, ruolo e stato. Utilizzare direttamente l’elemento nativo riduce il codice e il rischio di errori.

Indicare la Lingua della Pagina

La lingua principale dovrebbe essere dichiarata nel documento HTML.

Per una pagina italiana:

Questa informazione aiuta le tecnologie assistive a utilizzare pronuncia e regole linguistiche appropriate.

Quando una parte del contenuto utilizza una lingua differente, può essere indicata sul relativo elemento:

In WordPress la lingua principale viene normalmente definita nelle impostazioni, ma controllo comunque il codice generato dal tema e dagli eventuali sistemi multilingua.

Organizzare Correttamente i Titoli

I titoli non servono soltanto a rendere il testo più grande. Descrivono la struttura del contenuto.

Controllo che:

• il titolo principale sia riconoscibile;
• gli H2 introducano le sezioni principali;
• gli H3 appartengano alle sezioni precedenti;
• i livelli non vengano scelti soltanto per ottenere una dimensione grafica;
• il testo del titolo descriva realmente la sezione;
• non vengano utilizzati paragrafi in grassetto al posto delle intestazioni.

Una gerarchia logica permette di comprendere più rapidamente l’organizzazione della pagina e di navigare tra le sezioni. Il tutorial WAI raccomanda di nidificare i titoli secondo il loro livello e di evitare salti non necessari, come passare direttamente da H2 a H4.

Identificare le Regioni Principali della Pagina

Header, navigazione, contenuto principale, sezioni complementari e footer dovrebbero essere identificabili.

Gli elementi semantici più comuni comprendono:

• header;
• nav;
• main;
• aside;
• footer;
• section;
• article.

Una struttura ben organizzata aiuta chi usa tecnologie assistive a raggiungere direttamente le parti importanti e migliora l’orientamento nella pagina.

Evito però di trasformare ogni contenitore grafico in una regione. Troppe sezioni prive di un significato preciso possono rendere la navigazione più confusa.

Inserire un Collegamento per Saltare al Contenuto

Chi naviga da tastiera può essere costretto ad attraversare logo, menu e altri elementi ripetuti prima di raggiungere il contenuto principale.

Un collegamento iniziale può permettere di saltare direttamente alla parte centrale:

Il collegamento può essere nascosto visivamente quando non è utilizzato, ma deve diventare visibile quando riceve il focus.

Gli skip link continuano a essere utili per evitare blocchi ripetuti e rendere più rapida la navigazione da tastiera.

Provare l’Intero Sito con la Tastiera

Uno dei controlli più utili consiste nell’utilizzare il sito senza mouse.

Verifico se con Tab, Maiusc più Tab, Invio, barra spaziatrice e tasti freccia sia possibile:

• aprire e chiudere il menu;
• raggiungere tutti i collegamenti;
• attivare i pulsanti;
• compilare i moduli;
• selezionare checkbox e radio button;
• utilizzare filtri e schede;
• aprire e chiudere finestre;
• controllare video e audio;
• raggiungere il footer;
• tornare agli elementi precedenti.

Controllo anche che il focus non rimanga bloccato dentro un componente e che l’ordine seguito corrisponda all’organizzazione visiva e logica della pagina.

Mantenere il Focus Sempre Visibile

Durante la navigazione da tastiera deve essere possibile riconoscere l’elemento attivo.

Rimuovere indiscriminatamente il contorno del focus attraverso CSS può rendere impossibile capire quale link, campo o pulsante verrà attivato.

Controllo che l’indicatore:

• sia visibile;
• non venga eliminato;
• sia distinguibile dallo stato normale;
• rimanga presente per tutto il tempo necessario;
• non venga coperto da cookie banner o elementi fissi;
• funzioni su sfondi differenti.

Le WCAG richiedono un indicatore visibile per gli elementi utilizzabili da tastiera e, nella versione 2.2, includono anche il controllo che il componente focalizzato non venga completamente nascosto da contenuti creati dal sito.

Non Modificare l’Ordine del Focus Soltanto per la Grafica

CSS permette di disporre visivamente gli elementi in un ordine differente rispetto al codice HTML.

Questo può creare una situazione in cui il focus si sposta in modo apparentemente casuale sullo schermo.

Durante lo sviluppo confronto:

• ordine nel DOM;
• ordine visivo;
• ordine di tabulazione;
• ordine di lettura;
• sequenza necessaria per completare un’attività.

Evito inoltre di assegnare valori positivi a tabindex per forzare manualmente l’ordine. Una struttura HTML corretta è generalmente più stabile e semplice da mantenere.

Scrivere Collegamenti Comprensibili

Il testo di un link dovrebbe aiutare a comprendere la destinazione o l’azione prevista.

Espressioni come “clicca qui”, “leggi” o “scopri” possono diventare ambigue quando vengono separate dal testo circostante.

Preferisco collegamenti come:

• consulta i servizi di sviluppo WordPress;
• leggi la guida ai Core Web Vitals;
• scarica il documento in formato PDF;
• vai alla pagina dei contatti;
• visualizza i dettagli del progetto.

Quando più collegamenti hanno lo stesso testo ma destinazioni differenti, chi li consulta attraverso un elenco può non riuscire a distinguerli.

Non Affidare le Informazioni Soltanto al Colore

Il colore può rafforzare un messaggio, ma non dovrebbe essere l’unico elemento utilizzato per comunicarlo.

Un campo errato non dovrebbe essere identificato soltanto attraverso un bordo rosso. Può essere accompagnato da:

• un messaggio testuale;
• un’icona con significato accessibile;
• un’indicazione vicina al campo;
• un riepilogo degli errori;
• un collegamento al controllo da correggere.

Lo stesso principio riguarda grafici, stati, disponibilità, categorie e pulsanti selezionati.

Controllare il Contrasto dei Colori

Testo, pulsanti, campi, bordi e indicatori devono essere distinguibili rispetto allo sfondo.

Per il livello AA, le WCAG 2.2 indicano generalmente un rapporto minimo di 4,5:1 per il testo normale e 3:1 per il testo di grandi dimensioni, con eccezioni specifiche.

Non controllo soltanto il testo principale. Verifico anche:

• link;
• testi secondari;
• placeholder;
• messaggi di errore;
• pulsanti disabilitati e attivi;
• icone;
• bordi dei campi;
• focus;
• testo sopra immagini;
• stati selezionati.

Una combinazione può risultare leggibile su un monitor e diventare difficile da distinguere su uno smartphone, con luminosità ridotta o in condizioni di forte luce.

Consentire l’Ingrandimento del Testo

Il layout dovrebbe continuare a funzionare quando il testo viene ingrandito.

Durante il controllo verifico che:

• le frasi non vengano tagliate;
• i pulsanti si adattino al contenuto;
• le etichette non si sovrappongano ai campi;
• i menu restino utilizzabili;
• le finestre non escano dallo schermo;
• i contenitori non abbiano altezze rigide insufficienti;
• le informazioni non spariscano.

Le WCAG prevedono che il testo possa essere ridimensionato fino al 200% senza perdita di contenuto o funzionalità, salvo eccezioni previste.

Verificare Reflow e Comportamento Responsive

Un sito responsive non è automaticamente accessibile.

Il contenuto deve potersi adattare a viewport stretti e livelli elevati di zoom senza richiedere continuamente uno scorrimento sia verticale sia orizzontale.

Controllo in particolare:

• tabelle;
• blocchi di codice;
• menu;
• moduli affiancati;
• finestre modali;
• banner fissi;
• slider;
• immagini con testi incorporati;
• elementi con larghezza rigida.

Il criterio Reflow delle WCAG 2.2 richiede, con specifiche eccezioni, che il contenuto possa essere presentato senza perdita di informazioni o funzionalità a una larghezza equivalente a 320 pixel CSS.

Assegnare Etichette Reali ai Campi dei Moduli

Il placeholder non sostituisce l’etichetta del campo.

Può scomparire quando l’utente inizia a scrivere, avere contrasto ridotto e non essere interpretato nello stesso modo da tutte le tecnologie.

Una struttura esplicita può essere:

Il valore di for deve corrispondere all’id del controllo.

L’associazione permette di identificare correttamente il campo e rende cliccabile anche il testo dell’etichetta. Il tutorial WAI raccomanda di fornire etichette per campi di testo, checkbox, radio button e menu di selezione.

Raggruppare i Controlli Correlati

Gruppi di radio button e checkbox devono avere una domanda o un contesto comune.

Possono essere organizzati con:

Il testo della legenda descrive l’intero gruppo, mentre ogni etichetta identifica la singola scelta.

Fornire Istruzioni Prima dell’Errore

Quando un campo richiede un formato specifico, l’informazione dovrebbe essere disponibile prima dell’invio.

Controllo che siano indicati chiaramente:

• campi obbligatori;
• formato della data;
• caratteristiche della password;
• dimensione massima dei file;
• estensioni consentite;
• eventuali limiti di testo;
• condizioni necessarie per completare l’operazione.

Le istruzioni devono essere associate al relativo controllo e non affidate soltanto alla posizione visiva. Il WAI raccomanda di rendere accessibili indicazioni, formati e informazioni sui campi obbligatori.

Gestire Correttamente gli Errori

Quando il modulo non viene inviato, l’utente deve capire:

• che si è verificato un errore;
• quali campi sono coinvolti;
• perché il valore non è valido;
• come correggerlo;
• se le informazioni già inserite sono state conservate.

Un messaggio generico come “Errore nel modulo” non è sufficiente.

Preferisco messaggi specifici, ad esempio:

• inserisci un indirizzo email valido;
• seleziona almeno un servizio;
• il file supera la dimensione consentita;
• la password deve contenere almeno un numero;
• accetta le condizioni per continuare.

Quando il modulo è lungo, un riepilogo iniziale può collegare direttamente ai campi da correggere.

Comunicare i Messaggi Dinamici

Alcune informazioni compaiono senza ricaricare la pagina:

• conferma di invio;
• errore di validazione;
• prodotto aggiunto al carrello;
• risultati aggiornati;
• contenuto caricato;
• stato di un’operazione.

Se il messaggio cambia soltanto visivamente, una tecnologia assistiva potrebbe non rilevarlo.

Quando necessario può essere utilizzata una regione di stato:

Le regioni live devono essere utilizzate con moderazione. Troppe comunicazioni automatiche possono interrompere e confondere la navigazione.

Scrivere Testi Alternativi in Base alla Funzione

Il testo alternativo non deve essere generato automaticamente copiando sempre il nome del file, il titolo della pagina o una parola chiave SEO.

La descrizione dipende dal ruolo svolto dall’immagine.

Un’immagine può essere:

• informativa;
• decorativa;
• funzionale;
• parte di un collegamento;
• un grafico complesso;
• un’immagine contenente testo.

Il tutorial WAI distingue queste categorie e specifica che il testo alternativo deve comunicare l’informazione o la funzione rilevante nel contesto.

Lasciare Vuoto l’Alt delle Immagini Decorative

Un’immagine puramente decorativa non deve essere necessariamente descritta.

Può essere impostata con:

L’attributo deve essere presente ma vuoto.

Ometterlo completamente può portare alcune tecnologie a leggere il nome del file o altre informazioni prive di utilità.

Descrivere l’Azione delle Immagini Funzionali

Quando un’immagine è utilizzata come pulsante o collegamento, il testo alternativo dovrebbe descrivere l’azione.

Per un’icona che avvia una ricerca è più utile:

rispetto a:

Il primo testo comunica cosa accadrà attivando il controllo. Il secondo descrive soltanto l’aspetto dell’icona.

Non Inserire Informazioni Essenziali Soltanto nelle Immagini

Locandine, infografiche, banner e schermate possono contenere informazioni non disponibili nel testo della pagina.

In questi casi controllo che date, prezzi, istruzioni, contatti e dati principali siano presenti anche come testo HTML.

Per grafici e diagrammi complessi può essere necessaria una descrizione estesa o una rappresentazione equivalente dei dati.

Controllare Icone e Pulsanti Senza Testo

Un’icona può sembrare evidente a chi ha progettato l’interfaccia e risultare ambigua per altre persone.

Controllo che i pulsanti composti soltanto da un simbolo abbiano:

• un nome accessibile;
• una funzione riconoscibile;
• un’area di attivazione adeguata;
• uno stato visibile;
• un testo di supporto quando necessario.

Non utilizzo l’attributo title come unica etichetta, perché non è sempre disponibile o utilizzabile nello stesso modo su tastiera e dispositivi touch.

Creare Tabelle Soltanto per Dati Tabellari

Le tabelle non dovrebbero essere utilizzate per costruire il layout della pagina.

Quando servono a rappresentare dati, controllo:

• presenza di intestazioni;
• associazione tra celle e intestazioni;
• didascalia quando utile;
• ordine logico;
• comprensibilità senza dipendere soltanto dal colore;
• comportamento su schermi stretti;
• assenza di celle vuote usate per creare spazio.

Una tabella molto estesa può richiedere una soluzione responsive specifica, evitando di nascondere informazioni importanti.

Rendere Accessibili Audio e Video

I contenuti multimediali possono richiedere:

• sottotitoli sincronizzati;
• trascrizione;
• descrizione delle informazioni visive;
• controlli utilizzabili da tastiera;
• possibilità di mettere in pausa;
• volume controllabile;
• player accessibile.

I sottotitoli devono comprendere le informazioni sonore necessarie alla comprensione, non soltanto le parole pronunciate. Le risorse WAI indicano inoltre l’utilità di trascrizioni e descrizioni per rispondere a esigenze differenti.

I sottotitoli generati automaticamente devono essere controllati, perché nomi, termini tecnici, punteggiatura e divisione delle frasi possono risultare errati.

Evitare Riproduzioni Automatiche Incontrollabili

Audio, video e animazioni avviati automaticamente possono interferire con la lettura e con altri contenuti sonori.

Controllo che l’utente possa:

• mettere in pausa;
• interrompere;
• disattivare l’audio;
• nascondere un movimento;
• evitare ripetizioni infinite;
• comprendere quale elemento sta producendo il suono.

Evito inoltre contenuti lampeggianti o movimenti intensi non necessari.

Rispettare le Preferenze di Movimento Ridotto

Animazioni, parallasse, zoom e transizioni possono causare difficoltà ad alcune persone.

Quando il movimento non è indispensabile, controllo la preferenza del sistema operativo:

La disattivazione non dovrebbe eliminare contenuti o funzioni. Deve cambiare soltanto il modo in cui vengono presentati.

Gestire Correttamente Finestre Modali e Popup

Quando una finestra viene aperta sopra la pagina, controllo che:

• riceva il focus;
• abbia un titolo comprensibile;
• possa essere chiusa da tastiera;
• il focus rimanga all’interno finché è attiva;
• gli elementi sottostanti non siano utilizzabili;
• alla chiusura il focus torni al controllo che l’ha aperta;
• il pulsante di chiusura abbia un nome accessibile;
• il contenuto non esca dallo schermo.

Una finestra visivamente corretta può essere inutilizzabile quando il focus continua a muoversi dietro di essa.

Usare ARIA Soltanto Quando Serve

WAI-ARIA permette di aggiungere ruoli, stati e proprietà utili alle tecnologie assistive.

Non sostituisce però il comportamento degli elementi HTML nativi.

Attribuire a un div il ruolo di pulsante non aggiunge automaticamente attivazione con Invio e barra spaziatrice. Lo sviluppatore deve implementare tutte le interazioni previste.

La documentazione WAI sintetizza questo principio con l’indicazione che un’ARIA utilizzata male può essere peggiore della sua assenza.

Prima di utilizzare ARIA verifico quindi se esista un elemento HTML nativo capace di svolgere la stessa funzione.

Controllare i Componenti di Terze Parti

Il tema può essere ben sviluppato e il sito continuare a presentare problemi attraverso:

• cookie banner;
• chat;
• mappe;
• moduli esterni;
• slider;
• calendari;
• widget di recensioni;
• video incorporati;
• sistemi di pagamento;
• page builder.

Non considero accessibile un componente soltanto perché viene utilizzato da molti siti.

Lo provo con tastiera, zoom, focus e tecnologie di test. Verifico inoltre se possa essere configurato, modificato o sostituito.

Controllare il Tema WordPress

Nel tema verifico soprattutto:

• struttura delle intestazioni;
• regioni della pagina;
• menu desktop e mobile;
• focus;
• contrasto;
• ricerca;
• moduli dei commenti;
• paginazione;
• breadcrumb;
• testi alternativi;
• messaggi dinamici;
• comportamento responsive.

Un problema inserito nel template viene ripetuto automaticamente in tutte le pagine che lo utilizzano.

Per questo motivo controllo prima i componenti globali e soltanto dopo le singole pagine.

Curare Anche l’Area Amministrativa

Un plugin personalizzato può generare schermate utilizzate da amministratori, redattori e operatori.

Anche queste interfacce devono avere:

• etichette comprensibili;
• campi associati correttamente;
• messaggi di errore;
• focus visibile;
• ordine logico;
• pulsanti riconoscibili;
• azioni irreversibili chiaramente segnalate;
• tabelle utilizzabili;
• contrasto adeguato.

L’accessibilità non riguarda soltanto i visitatori. Può influire anche sulla possibilità di lavorare e pubblicare contenuti.

Formare Chi Pubblica i Contenuti

Un sito sviluppato correttamente può peggiorare nel tempo quando vengono pubblicati:

• titoli usati soltanto per ingrandire il testo;
• immagini senza descrizione;
• link con testo generico;
• testo inserito dentro immagini;
• tabelle copiate da documenti;
• colori con contrasto insufficiente;
• video senza sottotitoli;
• paragrafi interamente in maiuscolo;
• documenti PDF non accessibili.

Preparo quindi indicazioni semplici per chi utilizza l’editor, spiegando come gestire titoli, immagini, collegamenti, documenti e contenuti multimediali.

Non Affidarsi Soltanto ai Test Automatici

Gli strumenti automatici sono utili per individuare problemi come:

• assenza di alcuni testi alternativi;
• contrasto insufficiente;
• attributi non validi;
• etichette mancanti;
• errori nella struttura;
• ruoli ARIA incoerenti;
• elementi duplicati.

Non possono però stabilire sempre se:

• un testo alternativo sia realmente utile;
• l’ordine di lettura sia comprensibile;
• un messaggio di errore sia chiaro;
• il componente sia facile da utilizzare;
• il testo di un link descriva bene la destinazione;
• un’interazione sia prevedibile.

Il W3C specifica che nessun singolo strumento può determinare da solo se un sito soddisfi gli standard e che è necessaria una valutazione umana competente.

Integrare Test Automatici e Manuali

Durante il controllo utilizzo più livelli:

1. Verifica del codice e della struttura.
2. Analisi automatica delle pagine principali.
3. Navigazione completa da tastiera.
4. Controllo del focus.
5. Test con ingrandimento e viewport differenti.
6. Verifica dei moduli e dei messaggi.
7. Controllo con una tecnologia assistiva.
8. Test dei componenti dinamici.
9. Verifica dei contenuti pubblicati.
10. Controllo dopo gli aggiornamenti.

Un risultato positivo in uno strumento non sostituisce la prova delle attività reali che l’utente deve completare.

Testare Percorsi Completi e Non Soltanto la Home Page

Una scansione della pagina iniziale non copre necessariamente:

• modulo di contatto;
• ricerca;
• area riservata;
• carrello;
• checkout;
• prenotazione;
• filtri;
• pagine di errore;
• messaggi di conferma;
• contenuti caricati dinamicamente.

Preparo quindi percorsi di prova basati sulle attività principali del sito.

Per un e-commerce, ad esempio, il controllo deve comprendere ricerca, scheda prodotto, selezione delle varianti, carrello, checkout, errori e conferma finale.

Un Esempio Pratico su un Modulo di Contatto

Un modulo può apparire semplice e funzionare correttamente con il mouse.

Durante il controllo può emergere che:

• i campi utilizzano soltanto placeholder;
• il focus non è visibile;
• l’ordine di tabulazione è incoerente;
• l’errore viene indicato soltanto in rosso;
• il messaggio finale non viene annunciato;
• la checkbox della privacy non ha un’etichetta associata;
• il pulsante è costruito con un elemento generico;
• i dati già compilati vengono cancellati dopo un errore.

La soluzione non consiste nell’aggiungere indiscriminatamente attributi ARIA.

Correggo prima la struttura HTML, associo le etichette, mantengo il focus visibile, rendo specifici i messaggi e verifico l’intero invio da tastiera.

Il Mio Metodo per i Controlli di Accessibilità Web

Durante lo sviluppo seguo una procedura ordinata:

1. Definisco struttura e componenti prima della grafica definitiva.
2. Utilizzo elementi HTML semantici.
3. Controllo lingua, regioni e gerarchia dei titoli.
4. Provo menu e funzioni con la tastiera.
5. Verifico ordine e visibilità del focus.
6. Controllo link, pulsanti e componenti interattivi.
7. Analizzo contrasto, zoom e reflow.
8. Associo etichette e istruzioni ai moduli.
9. Verifico errori e messaggi dinamici.
10. Controllo immagini, icone, audio e video.
11. Valuto plugin e componenti esterni.
12. Eseguo test automatici.
13. Completo la verifica con controlli manuali.
14. Testo i percorsi principali del sito.
15. Ripeto i controlli dopo modifiche e aggiornamenti.

Questa procedura permette di individuare i problemi nel componente originario, evitando di correggere separatamente tutte le pagine in cui viene utilizzato.

Sviluppare un Sito Utilizzabile da Più Persone

L’accessibilità web durante lo sviluppo non consiste nell’aggiungere un pulsante o un widget alla fine del progetto.

Dipende dalla qualità della struttura, dalla prevedibilità delle interazioni, dalla chiarezza dei contenuti e dalla possibilità di utilizzare il sito in modi differenti.

HTML semantico, navigazione da tastiera, focus visibile, moduli comprensibili, contrasto adeguato e testi alternativi corretti costituiscono una base tecnica che deve essere mantenuta nel tempo.

I test automatici aiutano a individuare parte degli errori, ma devono essere accompagnati da verifiche manuali e dalla prova delle funzioni reali.

Integrare questi controlli durante lo sviluppo riduce le correzioni successive e produce siti più ordinati, robusti e semplici da utilizzare anche in condizioni non previste inizialmente.