PRIMA PAGINA
Dopo aver letto questa nutrita schiera di suggerimenti per favorire l'accessibilità, può sorgere spontanea la domanda: si tratta di pura teoria o esiste davvero la possibilità di creare un'opera multimediale che soddisfi tutti questi criteri? La mia risposta è che è assolutamente possibile, con gli strumenti software ed i linguaggi standard attualmente disponibili, creare opere che rispettino pienamente i criteri di accessibilità sopra descritti. Anzi, non è soltanto possibile, ma è addirittura necessario: non è più accettabile, infatti, che una parte dei potenziali utenti sia ingiustamente discriminata, impedendole di fatto - come accade oggi in moltissimi casi - l'accesso alle informazioni contenute nelle opere messe in commercio. Dovrebbe essere sentito dagli editori come un obbligo morale il produrre opere che non siano inutilmente discriminatorie.
Per di più, se gli editori riflettessero sul fatto che mettere in commercio un'opera pienamente accessibile significa poter raggiungere un numero di clienti senza dubbio maggiore di quello interessato ad acquistare i prodotti discriminatori attualmente in commercio, avrebbero un serio motivo in più per scrollarsi di dosso, una buona volta, la polvere dei vecchi pregiudizi.
Uno dei quali è sicuramente questo: realizzare un'opera accessibile significa creare un prodotto povero, cioè meno bello, meno attraente, meno ricco di gadget tecnologici e di interattività di quelli che si producono oggi, nella più totale indifferenza alle regole dell'accessibilità. E sono questi orpelli, questi gadget, le cose che fanno realmente vendere il prodotto.
Sono sicuro che questo è il pensiero di editori e sviluppatori, quando insistono nel progettare le loro opere con i criteri di sempre, continuando nel frattempo a non tenere in alcuna considerazione le proteste di chi si lamenta per la perdurante inaccessibilità di ogni nuovo prodotto commercializzato.
Ma sono altrettanto sicuro che questo pregiudizio degli editori sia - come tutti i pregiudizi - un grave errore di conoscenza. Se, infatti, conoscessero a sufficienza le regole dell'accessibilità e le potenzialità estetiche e funzionali derivanti dall'uso di linguaggi come HTML, CSS, JavaScript, XML, SMIL e SVG, saprebbero anche che tali linguaggi consentirebbero loro di raggiungere come minimo gli stessi effetti estetici e le stesse funzionalità di consultazione delle applicazioni proprietarie che sono soliti sviluppare oggi. Con in più, però, gli enormi vantaggi di garantire la scalabilità e l'accessibilità dei contenuti, la compatibilità con i più diversi sistemi hardware e software, il perdurare a tempo indeterminato della consultabilità dei documenti.
Tanto per scendere nel concreto, ecco di seguito una situazione di sviluppo
in cui i linguaggi standard consentono di preservare facilmente l'accessibilità.
Consideriamo un'interfaccia di consultazione in cui le funzioni di selezione dei
documenti siano attivate - come accade quasi sempre - da pulsanti grafici. In
una tipica applicazione proprietaria, del tipo di quelle esaminate all'inizio
dell'articolo, tali pulsanti risulterebbero inaccessibili per chi usa
sintetizzatori vocali; inoltre l'applicazione stessa sarebbe un programma a sé
stante, che non potrebbe essere caricato in un browser testuale come Lynx.
Invece in una situazione di cura dell'accessibilità, questa stessa applicazione
potrebbe essere sviluppata in HTML. Basterebbe così il banale uso dell'attributo
ALT per fornire dei testi alternativi ai pulsanti grafici, così da renderli
accessibili sia a chi consulta l'opera usando un browser testuale come Lynx sia
a chi usa sintetizzatori vocali. Il tutto, senza intervenire minimamente
sull'aspetto estetico dei pulsanti grafici, che rimarrebbe inviariato agli occhi
di chi consulta l'opera con un browser di ultima generazione. Un piccolissimo
sforzo per un grande vantaggio...
Ed ancora, con dei semplici JavaScript sarebbe possibile consentire agli
utenti di personalizzare dimensione e colore dei caratteri usati per i testi
nonché il colore dello sfondo. Con l'uso collegato dell'elemento NOSCRIPT si
potrebbero fornire nello stesso tempo, a chi consulta l'opera con programmi che
non supportano JavaScript, delle versioni alternative della stessa pagina,
ciascuna contenente una particolare personalizzazione, così da non penalizzare
nessuna categoria di utenti. Il contenuto dell'elemento NOSCRIPT sarebbe
visibile solo a chi adopera un browser non abilitato per JavaScript; tutti gli
altri vedrebbero la normale pagina, contenente i comandi di personalizzazione
dei testi e degli sfondi. Insomma: sviluppando per mezzo di linguaggi standard è
possibile, da un lato conservare l'estetica e l'interattività di un'interfaccia
proprietaria, dall'altro garantire accessibilità e durata nel tempo
all'applicazione e ai documenti che essa permette di consultare.
Un ultimo pregiudizio da considerare è quello della presunta stupidità dell'utilizzatore. Da quando nei PC il DOS è stato soppiantato da sistemi operativi di tipo grafico, è partita una corsa inarrestabile allo sviluppo di programmi sempre più elefantiaci, in termini di memoria occupata e di risorse di elaborazione richieste, nati con lo scopo principale di prendere per mano l'utilizzatore e condurlo senza sforzo, come un felice cretino, all'uso di tutte le innumerevoli funzioni messe a disposizione. Salvo ritrovarsi alla fine con utenti disorientati dalle troppe informazioni e dalle troppe funzioni, che - sgomenti di fronte alla serie quasi sterminata di menu, sottomenu, finestre di dialogo, funzioni di aiuto e di ricerca - si ritrovano alla fine ad usare più o meno la stessa ristretta cerchia di comandi e di funzioni, che erano già disponibili all'epoca della preistoria informatica targata DOS.
In un simile panorama, le opere multimediali non potevano essere da meno dei cosiddetti programmi di produttività personale ed aziendale. Ed ecco, allora, programmi di installazione di applicazioni su CD costruiti in modo tale da fare tutto da soli, senza quasi richiedere scelte consapevoli da parte dell'utilizzatore - il felice cretino di cui sopra - a parte l'inserimento del CD nell'apposito lettore... Salvo discriminare in questo modo tutti gli utilizzatori di sistemi hardware/software non compatibili con il complesso programma proprietario di "assistenza del cretino". Salvo installare nel computer del "cretino compatibile" file e voci di registro che cambiano inesorabilmente la configurazione del sistema ospite, fino, nei casi più sfortunati, a creare conflitti irrimediabili con altri software già installati. Il tutto, naturalmente, possibile solo per un periodo di tempo limitato, cioè fino a che dura la compatibilità - ancorché relativa - tra i programmi presenti sui supporti mobili dell'opera multimediale ed il software di sistema installato sul computer di destinazione...
Perché allora non provare una buona volta a restituire all'utilizzatore la propria intelligenza? Sogno un'opera multimediale:
Per la consultazione dell'opera, apri nel tuo browser preferito il file indice.htm. Se hai bisogno di ulteriori spiegazioni, apri invece il file guida.txt.
E questo è tutto, per il momento. Anzi, vale forse la pena di aggiungere un ultimo requisito: sogno un'opera multimediale che, per legge, non possa essere commercializzata senza essere stata preventivamente testata e approvata da un esperto di accessibilità.
(1) Se qualcuno avesse davvero questo problema, non bastandogli neppure le istruzioni allegate al CD, sarebbe meglio che facesse una cura di fosforo prima di acquistare opere su CD dedicate alla fisica atomica o allo studio comparato delle lingue.
(2) I creativi non temano che il loro lavoro sia penalizzato da una tale soluzione: riflettano piuttosto sul fatto che anche le loro creazioni più blindate e inaccessibili sono a tutt'oggi, quanto a valore estetico, tanto lontane dall'arte di un Leonardo o di un Raffaello quanto è lontano lo Stato italiano dall'aver debellato l'evasione fiscale ed il lavoro nero.
Vai al
sommario
Scrivi a
info@diodati.org
Aggiornato Tuesday, 15-Oct-2002 10:45:42 CEST
--20987--
