Web Design  »  Articoli  »  Accessibilità 

Questa è la traduzione dell'articolo Seven accessibility mistakes (part 1) pubblicato originariamente su Digital Web Magazine il 31 gennaio 2006. La traduzione viene qui presentata con il consenso dell'editore e dell'autore.

Ci sono diversi motivi per cui vengono pubblicati sul web siti non accessibili. Di uno abbiamo discusso in un mio precedente articolo: a molti clienti dell'accessibilità non importa praticamente nulla. Le loro motivazioni hanno un senso se ci si mette nei loro panni. Un'altra ragione è rappresentata dagli errori di noi sviluppatori. Fare errori è naturale, pagarne le conseguenze e imparare da quegli errori è ciò che può renderci migliori, come sviluppatori e come persone.

In questo articolo parlerò di alcuni fra i principali errori che ho dovuto affrontare nel corso della mia attività di sviluppatore web professionista. Se li terremo in considerazione nel futuro, è molto probabale che riusciremo a creare siti belli e accessibili senza tanti problemi, accontendando clienti e visitatori.

Alla fine di ogni sezione, presenterò anche una serie di suggerimenti utili ad evitare simili errori. È possibile che non tutti siano in grado di seguirli, per ragioni di budget, o perché alcuni richiedono un rapporto molto stretto con il cliente, ma tenerli presenti non può certo far male. Nessun passo compiuto nella direzione di un design fatto a vantaggio dell'utente e che tenga conto delle idee del cliente può rappresentare una perdita di tempo.

I sette errori in tema di accessibilità: 1-3

Errore #1: Fidarsi dei prodotti senza testarli

Molti strumenti di editing, framework o sistemi CMS dichiarano di poter creare siti standard compliant e conformi al livello WAI tripla-A. Molti di essi si limitano però a chiudere i tag HTML, a mettere in minuscolo i nomi degli elementi generati da un editor WYSIWYG e a rispettare le regole relative all'uso dell'attributo alt sulle immagini. Non c'è niente di male in tutto ciò, ma non basta.

Un codice HTML valido non è necessariamente corretto a livello semantico o logico, solo un essere umano è in grado di stabilire se lo è davvero. Non vorrei essere frainteso: ci sono strumenti di editing sicuramente validi, ma sono solo strumenti, macchine che non sono in grado di comprendere le questioni riguardanti l'interazione degli esseri umani con un computer. Le macchine non possono determinare in alcun modo se il risultato finale abbia o meno un senso, per quanto siano sofisticate. Nel bel mezzo di un progetto, poi, uno può scoprire che un certo CMS ha qualche difetto tenuto ben nascosto nei siti dimostrativi che in genere ne accompagnano la distribuzione (mi viene in mente la conformità rispetto alla codifica UTF-8 per i siti internazionali).

Cosa significa tutto ciò per lo sviluppatore?

• Dedicare molto tempo ad attività di training su uno specifico prodotto (nel caso di un IDE si tratta di un investimento che paga una volte per tutte).
• Documentare errori e bug insieme ai modi per risolverli. Fare di questo documento una parte obbligatoria del progetto da consegnare poi al team di gestione del sito o a eventuali nuovi membri del team di sviluppo.
• Svolgere test con esseri umani nel corso della fase di sviluppo. È un compito che può essere svolto da un editor appositamente addestrato se non c'è il tempo per un ciclo di test completi.

Altri articoli

Altre guide

Altre newsletter