Solo perché parla, non significa che sia accessibile

Accessibilità significa cose diverse per persone diverse. Per alcuni significa porte automatiche o bancomat a un’altezza specifica; per altri può significare un interprete del linguaggio dei segni a un colloquio di lavoro o il diritto di viaggiare con un cane da assistenza. Sebbene ogni disabilità sia diversa, tutti questi accorgimenti hanno una cosa in comune: devono essere fatti bene o non saranno efficaci.

Lo stesso vale per l’accessibilità dei documenti. Solo perché il font è grande non significa che il contenuto sia leggibile da una persona con problemi di vista. Solo perché lo screen reader inizia a parlare quando apri il file, non significa che l’utente finale stia ricevendo le informazioni che stai cercando di trasmettere.

I progressi della tecnologia implicano che, in alcuni casi, siano necessarie sempre meno conoscenze di base per modificare un documento da un formato a un altro. È possibile salvare un file PDF in diversi altri tipi di documenti che possono rendere il contenuto più accessibile. Il software di traduzione Braille consente persino di importare file Word o di testo e con un clic è possibile trasformare la stampa in Braille. Detto questo, il file convertito conterrà tutte le informazioni dell’originale? L’ordine di lettura e la formattazione saranno logici? L’output soddisfa gli standard di settore per l’accessibilità? È qui che entrano in gioco i test o il controllo di qualità.

Per diversi anni ho lavorato come consulente per le risorse umane per il governo federale. Sebbene il mio lavoro non fosse correlato all’accessibilità, spesso aiutavo i colleghi che cercavano di garantire che documenti e pagine web fossero conformi alla legislazione pertinente sull’accessibilità. Una volta mi è stato chiesto di verificare un PDF compilabile. Il mio collega mi ha informato che era abbastanza sicuro che il file fosse a posto: “L’ho aperto e lo screen reader ha iniziato a parlare, quindi probabilmente va bene”. In effetti, quando ho aperto il file JAWS ha iniziato a parlare, ma tutto ciò che ha fatto è stato dire il nome del modulo. In ciascuna delle caselle da compilare c’era la parola “modifica”. L’ordine di lettura non era stato contrassegnato correttamente, quindi era impossibile sapere quali informazioni appartenessero a quale casella. Solo perché parla, non significa che sia accessibile!

Che lo si chiami testing, proofing o QC, questo processo ha due elementi chiave nella produzione di documenti accessibili. Il primo è garantire che la versione accessibile del file sia accurata e contenga tutte le informazioni trovate nell’originale. Ciò è essenziale in tutti i tipi di file, ma è di particolare importanza nei rendiconti bancari e finanziari, dove uno zero in più o in meno fa una differenza significativa.

L’altro elemento è la conformità agli standard del settore. Ogni formato accessibile ha linee guida e standard che devono essere seguiti. Ad esempio, la stampa grande non riguarda solo l’ingrandimento del font. Riguarda anche il modo in cui il contenuto è disposto sulla pagina. Anche la formattazione è importante nel braille e ci sono una serie di regole che regolano l’uso del codice stesso. WCAG 2.0 AA e PDF/UA forniscono indicazioni per rendere accessibili i file PDF. Tutti i formati hanno requisiti su come devono essere visualizzate le immagini e altre informazioni visive. Ci sono specifiche aggiuntive per la copia cartacea, come la qualità della carta, la rilegatura e l’altezza dei punti. I test garantiscono che l’utente finale riceva informazioni accurate in un documento che soddisfa gli standard più elevati per il formato richiesto.

Per saperne di più sul processo di testing o per avere idee per testare internamente i tuoi file, non è troppo tardi per iscriversi al webinar di domani, Testing Accessible Documents. Dalle 13:00 alle 14:00 ET, esamineremo le migliori pratiche per testare i formati accessibili come il braille, la stampa a caratteri grandi, l’eText, il PDF accessibile e altri formati comunemente utilizzati.