L’obiezione più comune in assoluto
“L’accessibilità fa lievitare il preventivo, facciamo un sito standard per risparmiare.” È l’obiezione su cui cade la maggior parte delle trattative — ed è costruita su un equivoco: un sito non accessibile non è un sito “più economico”, è un prodotto incompleto il cui costo reale è solo nascosto, non assente.
La metafora dell’architettura: costruire contro ristrutturare
Inserire un ascensore nel progetto originale di una palazzina ha un costo marginale, prevedibile fin dal preventivo iniziale. Aggiungere un ascensore dopo che la palazzina è già costruita — abbattendo muri, rifacendo la struttura portante — costa molto di più e blocca l’operatività dell’edificio nel frattempo.
Nel codice funziona nello stesso modo
Scrivere HTML semantico fin dal primo giorno ha un impatto quasi nullo sulle ore di sviluppo. Riscrivere il codice a posteriori, con la remediation, richiede di intervenire su una struttura già in produzione — con lo stesso principio di costo crescente confermato dal Systems Sciences Institute di IBM: un difetto corretto in fase di implementazione costa circa 6 volte di più che risolverlo in fase di progettazione.
Il costo nascosto della manutenzione
I componenti che rispettano gli standard HTML/CSS nativi restano stabili negli aggiornamenti. I componenti costruiti con trick e script personalizzati per apparire “belli” senza passare per gli standard si rompono a ogni cambio di browser o di grafica — ore di debug retribuito, ripetute nel tempo, che un componente costruito bene fin dall’inizio non avrebbe mai generato.
Il tasso di abbandono che Google Analytics non mostra
Analytics non registra l’utente che chiude la scheda perché non riesce ad azionare un menu da tastiera, né quello che abbandona perché lo screen reader non legge la conferma d’ordine. Non stai risparmiando sul preventivo: stai tagliando fuori una parte di mercato già pronta a comprare, e la perdita è mascherata da “risparmio”, quando in realtà è fatturato mancato che nessun report ti mostra.
L’inganno dell’overlay “economico”
Un widget da 30-50€ al mese che promette di “aggiungere” accessibilità sopra un codice invariato è un doppio costo: paghi un abbonamento continuo per uno strumento che non risolve il codice sottostante e non garantisce conformità reale. Quando emerge che non basta — un controllo, una segnalazione, un cliente che non riesce comunque a comprare — paghi comunque uno specialista per sistemare il codice alla radice, sommando l’abbonamento già speso al costo che avresti comunque dovuto sostenere.
Il messaggio chiave
Progettare un sito accessibile non significa aggiungere un optional costoso. Significa applicare le regole corrette di ingegneria del software fin dal primo giorno. Un sito accessibile non costa di più — è semplicemente un sito fatto bene, pensato per durare, invece che per essere rifatto tra due anni.
Un esempio concreto
Ho testato con NVDA due plugin diffusi sul mercato per filtri e griglie prodotto. Il primo — quello apparentemente più “pronto all’uso” — violava un pattern ARIA di base: il tasto Escape non chiudeva il combobox dei filtri, e dopo un aggiornamento AJAX dei risultati il focus della tastiera si perdeva, tornando all’inizio della pagina invece di restare sul filtro appena usato. Il secondo, verificato con lo stesso test, gestiva entrambi i casi correttamente. Nessuna delle due differenze emerge da una demo guardata al volo, o da una lista di funzionalità sul sito del prodotto — emergono solo navigando davvero con tastiera e screen reader, cosa che la maggior parte di chi sceglie un plugin non fa prima di comprarlo.