Sull’interessante intervista di Tommaso a Elena Brescacin, Laura Raffaeli (del Blindsight Project) nei commenti scrive che
rendere accessibile, con poca spesa (perché l’accessibilità non va di pari passo al prezzo alto, anzi!) un sito non è poi così né costoso né difficile
In base alla mia esperienza, non mi sento di dire se sia costoso o meno in generale: dipende dalla complessità del sito.
Un sito statico di poche pagine o un WordPress base con il tema di Tommaso, non è certo costoso renderlo accessibile ma basta aggiungere, per esempio, una decina di plugin – cosa non certo insolita – ed ecco aumentare il lavoro: è ben raro che questi componenti extra siano “a posto”. Il discorso si complica per CMS più complessi (Joomla!, Drupal eccetera). È un problema di mantenimento di fork, non di accessibilità, con il software libero.
Se uso un software libero che, in qualche modo, non è accessibile, posso modificarlo e sperare che la mia patch venga integrata nel software… oppure sono costretto ad aprirmi un mio subversion (o simile) e continuamente riallineare il mio fork ai changeset del progetto esterno.
Restando nel software libero LAMP, non è raro che un sito CMS di media complessità, usi una decina di componenti di terze parti… dovrei quindi gestire altrettanti subversion con le mie patch di ciascuno e i relativi riallineamenti di cui sopra.
Questo per la parte di programmazione: ci sono poi le modifiche grafiche (per ipovedenti) delle quali si occuperanno i grafici e non i programmatori, ci sono i test con software per non vedenti e gli inevitabili ricircoli.
Quindi abbiamo due tipi di costi: iniziali e a regime; quelli iniziali li comprendono tutti, quelli a regime (i riallineamenti tra fork interno e trunk esterno, sia per nuove funzioni che per “semplici” motivi di sicurezza) purtroppo spesso il cliente non li capisce e quindi fatica ad accettarli (si legga: a pagarli).
Da alcuni anni, mi è capitato di lavorare diverse volte su questi problemi e se dovessi dare, seppur a spanne, una indicazione, direi che con un CMS (non MVC, non recentissimo quindi) di medie dimensioni e appunto con una decina di componenti esterni “classici” (forum, acl, crud pubblici vari, gestione documentale eccetera) non è strano stimare diversi mesi uomo per renderlo accessibile, usabile e Stanca-compatibile.
Naturalmente, ben altri costi si avrebbero per siti grandi o – peggio – grandi, vecchi e scritti da zero. Non dico quindi che sia tanto o poco (e tantomeno non dico che non sia doveroso rendere accessibili e usabili quanti più siti sia possibile) ma, per quel che vale, volevo condividere qualche esperienza professionale sul tema.
Ma sono il solo che quando legge “sito accessibile” intende che le informazioni che contiene devono essere accessibili ?
Faccio un esempio, nella sezione Tariffe e Promozioni di Vodafone mi aspetto di trovare si delle “fregnacce” grafiche e dei tool flash che mi “aiutino” nella scelta di una tariffa … ma mi aspetto un elenco chiaro delle tariffe esistente, tutte linkate in ordine e per tipologia.
Se vado sul sito del Comune di Bari, mi aspetto di poter effettivamente accedere alle sezioni Bandi e Concorsi, e non di vedermi presentati solo una parte di queste informazioni.
Tutti i passaggi di validazione sono del tutto secondari rispetto allo scopo primo di un sito web, che sono la condivisione di una INFORMAZIONE, e non la sua rappresentazione.
Non so se ho espresso il punto …
Se si, allora, credo che una buona parte delle spese da fare per rendere accessibile un sito siano da imputare alla pianificazione attenta dei contenuti da pubblicare, quanto sia veloce arrivarci, e come … diciamo uno schema logico di dati e relazioni come negli esami di basi di dati ?
Qui, invece, mi pare che tutti si preoccupino solo del codice xHTML (o quel che usano …)
Beh, sono due cose diverse. Una è l’accessibilità, l’altra – alla quale ti riferisci – è l’usabilità.
L’usabilità è molto importante, certo e il problema che descrivi è chiaro (eviterò esempi di lavoro, diciamo :D). Cosa si può fare? Si dovrebbero lasciar distribuire le quantità di contenuti per “pagina” a chi ne capisce :), seguire alcune regole note in “letteratura” e usare tool apposta… per il backend di WordPress, per esempio, hanno usato un software che registra i movimenti degli occhi (è servito per disporre al meglio i menu e le varie voci). C’è un software (userfly.com) segnalato proprio da Tommaso, che aiuta – via web – in queste misurazioni.