ti trovi in: Home Page - Biblioteca - Documentazione -
Le disabilità nell'uso di strumenti informatici e telematici possono sostanzialmente essere ricondotte in tre diverse categorie: quelle sensoriali (persone non vedenti o ipovedenti, sordi); quelle motorie (paralisi , spasticità, etc. ); quelle cognitive (afasia, dislessia, etc.).
In queste pagine, per il momento, non verrà affrontato l'argomento della ricerca e delle tecniche e degli ausili riguardanti le disabilità cognitive.
Le tecniche atte a superare o mitigare queste disabilità sono in costante sviluppo e la panoramica di prodotti e accorgimenti utili è già molto vasta. Queste tecniche sono efficaci se si agisce su entrambi i fronti, sia su quello del produttore (ad esempio il web master del sito internet oppure il fornitore dell'applicazione software) che su quello dell'utilizzatore (ad esempio un dipendente della P.A. che abbia una o più delle disabilità sopra descritte).
Il motivo per cui è necessario agire contemporaneamente sui due fronti è semplice: la comunicazione, salvo casi particolari, si realizza se entrambi i soggetti si attivano per raggiungere quell'obiettivo. Ad esempio una persona non vedente può dotarsi del migliore screen reader di questo mondo, ma se una immagine in un sito non ha un commento testuale sarà impossibile comprenderne il significato. Se gli agganci ipertestuali (link) nelle pagine sono fondati su grafici anch'essi senza commento testuale, e i nomi delle pagine chiamate è anonimo rispetto al loro contenuto (esempio: pag1.html pag2.html pag3.html), la navigazione sarà veramente "alla cieca". Se i link sono troppo vicini e piccoli sullo schermo anche chi ha problemi motori e per questo usa il miglior comando vocale o il più efficiente emulatore di mouse troverà comunque difficile e faticoso raggiungere quei comandi. D'altra parte se chi prepara i siti e le applicazioni opera al meglio delle tecnologie assistive rispettando le normative WAI o simili e poi l'utente o l'operatore con disabilità non dispone degli ausili e delle interfacce ottimali, il risultato sarà scadente e renderà inutile anche il lavoro effettuato dal lato "server". Facendo un parallelo con il tema delle barriere architettoniche, si può affermare che lo scivolo e la carrozzina sono i due fronti del problema accessibilità. Se manca lo scivolo la carrozzina serve a poco, ma se manca la carrozzina lo scivolo serve ancor meno.
Gli interventi sul lato server spaziano dal disegno delle pagine secondo le regole dell'accessibilità, così come prescritto dalle circolari AIPA e DFP, preferibilmente in un sistema di "content management" che consente di sganciare la consistenza dei dati dalla loro rappresentazione, in modo da arrivare anche a siti come "pubbliaccesso" il cui formato di visualizzazione è personalizzabile dal singolo utente, e che può memorizzare queste opzioni in modo che il sito sia predisposto in modo ottimale alla successiva visita. La qualità della costruzione del sito dal punto di vista dell'accessibilità può essere testata sia mediante le procedure descritte nella circolare AIPA, sia usando dei validatori esterni come Bobby od altri. Chi produce applicazioni dovrà invece testare e verificare se le stesse sono compatibili con i software dei sistemi di tecnologia assistiva, come gli screen reader, i sistemi di sintesi e riconoscimento vocale, e via dicendo.
Per quanto riguarda la tecnologia dal lato client, che è più attinente a questo spazio, le offerte sono molte e in continua evoluzione: gli screen reader, i sistemi di sintesi vocale, i simulatori software o sostituti hardware di tastiere e mouse come ad esempio i puntatori controllati con il movimento del capo o degli occhi, i comandi vocali e la dettatura vocale.
In questo spazio nei successivi aggiornamenti verranno forniti indirizzi e riferimenti utili per il reperimento dei materiali.
3 marzo 2003
John Fischetti