Accessibility StatementUno sviluppatore mi ha inoltrato un PDF di 60 pagine con tre parole evidenziate: «improve accessibility».
Mi ha scritto una riga sola: «e adesso cosa faccio».
12 novembre. Quarantanove giorni al 31 dicembre 2026.
Tre situazioni. Una è la tua.
A) Hai pagato un audit e il PDF è fermo nella casella di qualcuno da mesi.
B) Il report è arrivato al team e nessuno sa da dove cominciare.
C) Non hai mai fatto fare un audit, e almeno non hai sprecato soldi.
Il problema non è l'audit. È che un report scritto per il cliente non è scritto per chi deve mettere le mani nel codice.
Un report usabile ha una riga per barriera, e quella riga contiene quattro cose:
— il criterio (3.3.2, 2.4.7, 1.4.1)
— il punto esatto: pagina ed elemento
— come riprodurla: tre righe, tastiera per prima
— come verificarla: il test da rifare dopo la correzione
E una cosa che ai team piace parecchio: le occorrenze sono raggruppate. Spesso si correggono tre cose, non sessanta, perché una singola modifica chiude molte righe insieme.
Da dire con onestà: il codice non lo tocchiamo noi. Lo sistema il tuo team, o la tua agenzia. Noi ritestiamo il mese dopo e riemettiamo il record aggiornato. Se cercavi qualcuno che mettesse le mani nel sito, serve un altro preventivo, e te lo diciamo prima.
Prima di spendere qualunque cifra: controllo gratuito della tua home page, dieci secondi.
Scrivi A, B o C nei commenti. Rispondo a ognuno e ti dico se il report che hai in mano è utilizzabile o solo lungo.
Poi mandalo allo sviluppatore che dovrà leggerlo.
