Modello per semplificare il Web Design per le disabilità cognitive

Per quanto possibile, le disabilità cognitive dovrebbero essere demistificate prima che si possa fare qualche passo avanti su quegli strumenti di sviluppo che favoriscono la creazione di contenuti accessibili per utenti con queste disabilità. A questo fine, questo documento delinea un ambiente concettuale all’interno del quale i creatori di strumenti possano approcciare correttamente la sfida di identificare e rimuovere le barriere legate alle disabilità cognitive.

Questo schema concettuale è formato da:

  • Tipologie di disabilità funzionali cognitive
  • Principi di accessibilità per le disabilità cognitive
  • Elementi di analisi dei contenuti Web
  • Elementi da analizzare
  • Attività di analisi
  • Competenze e responsabilità in gioco

Dopo aver brevemente esplorato questa struttura, ci soffermeremo su come essa possa essere applicata allo sviluppo degli strumenti per l’accessibilità dei disabili cognitivi.

Disabilità cognitive cliniche e funzionali

Esiste un’infinità di disabilità cognitive, ciascuna delle quali con una specifica diagnosi clinica. Un uomo può soffrire di disturbi dell’apprendimento (dislessia, disgrafia, discalculia, o generici deficit nell’attenzione), disabilità genetiche o dello sviluppo (autismo, sindrome di down), o anomalie congenite (sindrome alcolica fetale), o di tanti altri tipi di disabilità legate alla cognizione. Pur essendo (forse) utili ai medici, queste diagnosi dicono poco o niente agli sviluppatori Web non essendoci un collegamento diretto tra le diagnosi e le azioni da intraprendere per venir incontro agli utenti del Web affetti da esse.

Innanzitutto, c’è una considerevole sovrapposizione nelle limitazioni conseguenze delle varie diagnosi; un individuo con la sindrome di Down o con la sindrome alcolica fetale può avere problemi nell’elaborare informazioni basate sul testo, ma lo stesso può valere per un individuo affetto da disturbi nell’apprendimento, anche se a diversi livelli. Questo ci porta al secondo punto, cioè al gran numero di variazioni non solo fra gruppi diversi, ma anche all’interno di ciascun gruppo con le stesse disabilità cliniche.  Alcuni individui con sindrome di Down possono avere elevate capacità di lettura e di comprensione della maggior parte dei contenuti del Web, altri possono essere completamente inabili in questo campo.

Un modello ben più utile per gli sviluppatori è quello delle disabilità cognitive funzionali. Non tutte le categorie di questo modello presenti in letteratura hanno una particolare  rilevanza per gli sviluppatori del Web; le categorie che noi proponiamo si basano essenzialmente sulle categorie di Rowland[1] con qualche elemento in aggiunta.  Le categorie sono:

  • Memoria
  • Risoluzione di problemi
  • Attenzione
  • Comprensione verbale, linguistica e di lettura
  • Comprensione della matematica
  • Comprensione visuale

Le ultime tre categorie sono un’elaborazione delle categorie di Rowland relative alla percezione ed elaborazione, che pensiamo siano un po’ troppo estese per i nostri scopi. Le difficoltà dell’utente rispetto ad una di queste categorie di disabilità funzionali si traducono (anche se in maniera non esclusiva) in un preciso effetto sulle capacità dell’utente di accedere ai contenuti del Web. La non esclusiva mutualità di queste categorie in qualche modo complica la faccenda, ma esse mantengono la loro utilità come punto di riferimento all’interno del quale caratterizzare le sfide degli utenti con disabilità cognitive. La gran parte degli ostacoli per gli utenti rientrano essenzialmente in una delle categorie, anche se i loro effetti tendono a farsi sentire anche in altre categorie. Per esempio, un utente con difficoltà nella lettura potrebbe anche avere difficoltà nel concentrarsi e prestare attenzione a testi molto lunghi. Nel primo caso, i problemi nella lettura causano la disattenzione; al contrario la disattenzione può facilmente condurre a difficoltà nella lettura. Nonostante questa sovrapposizione negli effetti risultanti, riuscire a focalizzare l’attenzione sulla causa principale può eliminare, o quanto meno ridurre, gli effetti secondari. Similmente, dal punto di vista dello sviluppatore Web, ciascuna di queste categorie rappresenta una diversa tipologia di problema, che richiede di solito un diverso tipo di soluzione.


[1]Rowland, C. (2004). Cognitive disabilities part 2: conceptualizing design considerations. Retrieved April 1, 2005 from http://www.webaim.org/techniques/ articles/conceptualize/.

Principi di accessibilità per le disabilità cognitive 

Esistono dei principi generali che possono essere applicati a tutte le categorie di disabilità cognitive funzionali. Essi, adattati da Bohman (http://www.webaim.org/techniques/articles/framework/#note3#note3) asseriscono che il contenuto Web dovrebbe risultare:

  • Semplice
  • Consistente
  • Chiaro
  • Multimodale
  • Tollerante agli errori
  • Tollerante ai ritardi
  • Focalizzato all’attenzione

Anche la semplice definizione di questi principi non è sempre un compito facile. Per esempio, quanto semplice deve essere una cosa per essere considerata “semplice”? E quanta variazione può essere introdotta prima che una cosa risulti non più consistente? Quali sono i metodi migliori per rendere chiaro il significato di un certo contenuto?

Le risposte a queste problematiche determineranno cosa gli strumenti dovranno identificare nei contenuti Web allo scopo di renderli maggiormente accessibili agli utenti disabili. Sfortunatamente molte delle risposte sono vaghe e fumose; ciò nonostante l’identificazione di alcuni principi è almeno il primo passo verso la giusta direzione perché ci permette di catalogare gli algoritmi che già esistono negli strumenti e ci fornisce una direzione da seguire per lo sviluppo degli algoritmi futuri.

Unità di Analisi          

Una delle aree più spesso trascurate nello sviluppo di strumenti per l’accessibilità web è l’unita di analisi. Noi abbiamo identificato sei potenziali unità di analisi:

  • La “pagina” Web
  • L’intero sito Web
  • Il template
  • Il contenuto presente nel template
  • “parti” o “sottosezioni” del contenuto
  • Scenari e percorsi

La maggior parte degli strumenti analizzano le pagine Web una alla volta oppure analizzano tutte quelle presenti nell’intero sito. Perfino gli strumenti che producono un report per un intero sito web utilizzano pagine individuali come unità di analisi.

Nella maggior parte dei casi i report mostrano un elenco di errori e forniscono all’utente l’URI delle pagine dove sono stati trovati.

Nonostante sia utile in molti casi, l’analisi svolta a livello di pagina non è efficiente o utile come quella svolta con le altre tipologie di unità di analisi.

L’analisi a livello di pagina risulta essere meno efficiente perché i siti sono costruiti usando di solito un template, spesso con elementi di navigazione come le etichette (tabs) o le barre laterali (side bar)  che consentono il collegamento verso altre aree del sito Web. Questi template sono generalmente abbastanza coerenti da pagina a pagina. I report che si concentrano sulla pagina come unità di analisi riportano invariabilmente sempre gli stessi errori per ogni pagina.

Se il logo principale nel template non contiene alcun testo alt, per esempio, lo strumento ci mostrerà sempre la mancanza del testo alt su ogni pagina per tutto il sito. Sarebbe più efficiente riportare quest’errore soltanto una volta ed identificare l’errore come un errore presente nel template. Gli errori presenti nel contenuto principale dovrebbero essere identificati come sopra – ma gli strumenti possono potenzialmente fare di più che separare il contenuto dal template.

Dove appropriato, gli strumenti potrebbero analizzare singole parti o sottosezioni del contenuto principale. Questo risulta molto utile nei siti che raggruppano in un unico contenuto più sorgenti. Ogni componente potrebbe essere analizzata separatamente e presa in considerazione come unità indipendente. Però non tutto il contenuto Web può o potrebbe essere separato in piccole sottosezioni, ma dove è possibile separarlo potrebbe aver senso analizzarlo separatamente.

L’ultima unità di analisi è una delle più importanti, infatti è anche quella universalmente ignorata:

Scenari e percorsi

Nel contesto di questo documento, uno scenario o percorso è la totale esperienza che ha utente dall’inizio alla fine. Su un sito di commercio elettronico, per esempio, lo scenario utente potrebbe essere la ricerca di un prodotto, l’aggiunta di un prodotto al carrello della spesa virtuale, l’inserimento delle informazioni sul pagamento e le spese di spedizione, e la conferma dell’ordine. Questo, naturalmente presuppone che l’utente non deve perdersi nel percorso.

Percorsi alternativi o secondari potrebbero essere la lettura di maggiori informazioni sulla società che vende il prodotto, leggere le informazioni sulle politiche della privacy, confrontare il prodotto con prodotti simili, etc. Se uno dei passi del tragitto presenti su questi percorsi risulta inaccessibile, l’intero percorso è inaccessibile. In questo caso, a poco senso dire che il 95% del sito Web è accessibile se il 5% non è accessibile impedendo all’utente l’acquisto di un prodotto.

L’intero scenario — o l’insieme degli scenari — deve prendere in considerazione il raggiungimento del massimo dell’accessibilità.

Aspetti dell’analisi

Per tutte le unità di analisi, ci sono due differenti aspetti da analizzare:

  • Il contenuto
  • La presentazione

Il contenuto può essere analizzato principalmente per il significato semantico e concettuale.

La presentazione in formato testo, grafico, video, audio, o in altri formati può essere analizzata nei termini della sua multi-modalità, della tolleranza agli errori, della tolleranza nel ritardo, o nell’abilità di attirare l’attenzione dell’utente.

Curiosamente, la presentazione può essere valutata anche in base al suo significato semantico e concettuale. Per esempio, una pagina Web può essere divisa in differenti sezioni di significato mediante il <div> con differenti colori nello sfondo o nel bordo.

Queste sezioni possono effettivamente servire come raggruppamento visuale o fornire un meccanismo di suddivisione in parti del contenuto. Forniscono più che un abbellimento visivo una rappresentazione visuale di un significato semantico. Naturalmente, questo significato semantico dovrebbe essere in qualche modo presente nella parte principale, non-presentazionale, ma l’aspetto di presentazione applicato a questo contenuto serve a estendere e a mettere in risalto il significato semantico.

Fasi dell’analisi

Il contenuto Web può essere valutato in vari stadi di sviluppo, e per differenti motivi. I principali stadi di analisi sono:

  • Il processo di pianificazione
  • Il processo di progettazione
  • La fase di test
  • Dopo che il contenuto è completato

La maggior parte degli strumenti sono progettati per essere utilizzati dopo che il contenuto è completato. Questo è un importante stadio di analisi ma non è l’unico. Il grosso del lavoro sull’accessibilità web è consigliabile farlo durante la prima fase: il processo di pianificazione.

Strumenti per il processo di pianificazione dovrebbero essere presenti all’interno degli strumenti di authoring, o negli strumenti grafici (per la creazione di prototipi), o negli strumenti progettati esclusivamente per il processo di pianificazione. Questi strumenti potrebbero aiutare l’utente mediante suggerimenti o informazioni perfino prima d’iniziare lo sviluppo, questo consentirebbe di prevenire problemi prima che essi si presentino.

In aggiunta agli strumenti di creazione per gli ambienti di authoring, strumenti di test possono essere creati per il browser, per applicazioni standalone, o per applicazioni Web.

Ambiti di responsabilità

Una delle difficoltà che emergono quando si discute del modo in cui rendere accessibile un contenuto Web  a persone con disabilita cognitive è data dall’incertezza su chi dovrebbe avere la responsabilità di decidere le modifiche. Tra i principali ambiti di responsabilità ci sono:

  • Sviluppatori web
  • Linee guida e standard
  • Sviluppatori di strumenti di authoring
  • Sviluppatori di user agent
  • Sviluppatori di tecnologie assistive
  • Assistenti personali degli utenti (ove applicabile)
  • Utenti

Sono molti i punti sui cui intervenire per rendere il contenuto Web più accessibile alle persone con disabilita cognitive. L’ordine nel quale gli ambiti di responsabilità compaiono nella lista presentata sopra è la rappresentazione approssimativa del flusso del contenuto Web dall’origine (lo sviluppatore Web) alla destinazione  (l’utente). Gli sviluppatori Web implementano le linee guida e gli standard con i loro strumenti di auhtoring. Il contenuto è visualizzato tramite uno “user agent” (Browser), e potrebbe essere utilizzato tramite qualche tecnologia assistiva (es. sintetizzatore vocale) o da un’assistente personale, dipende dalla disabilita cognitiva. La più severa disabilità cognitiva è molto probabilmente quella in cui la persona avrà bisogno di un’assistente personale che lo guida nell’accesso al contenuto Web. Alla fine del flusso ci sono gli utenti, che personalizzano il proprio browser secondo le loro necessità e preferenze.

Nonostante la presenza di molti punti d’intervento, il fatto che il processo parta dallo sviluppatore Web è cruciale. Gli sviluppatori web non possono abdicare le loro responsabilità, per quanto a molti potrebbe piacere.Il familiare adagio “garbage in” e “garbage out” è particolarmente apprezzato in questo contesto.

Dopo che lo sviluppatore web invia il contenuto web, il contenuto può essere pienamente accessibile o meno per le persone con disabilita cognitive.

Tramite gli altri punti d’intervento si può far ben poco sul contenuto in quanto solo l’autore ne conosce il vero significato. Tutti gli altri punti d’intervento sono interpretazioni delle intenzioni originarie dell’autore. E quindi raramente vengono compensati errori, disattenzioni, omissioni o sviste dell’autore.

 

Potrebbero interessarti anche i seguenti articoli

  • Conclusioni e riferimentiConclusioni e riferimenti Conclusioni Il modello presentato in questo documento non è certamente la bacchetta magica per la realizzazione di strumenti per disabilita cognitive; è […]
  • Applicare il modello ad uno strumento di sviluppoApplicare il modello ad uno strumento di sviluppo Applichiamo il modello Il modello descritto in questo documento aiuta sia a definire che ad ampliare le possibilità per gli strumenti di sviluppo, non solo per […]
  • Disabilità cognitive: strumenti e sviluppiDisabilità cognitive: strumenti e sviluppi Articolo originale "A Conceptual Framework for Accessibility Tools to Benefit Users with Cognitive Disabilities " […]
  • Le possibilità futureLe possibilità future Possibilità e sviluppi Ironicamente, per creare strumenti che meglio rispondono alle necessità degli utenti con disabilita cognitive, questi strumenti […]
  • Voce e Web – VXMLVoce e Web – VXML L'articolo è stato redatto in collaborazione con Cristina Tabachetti La ricerca nel campo delle tecnologie vocali, che ormai è prossima a compiere i suoi […]
Condividi:

Informazioni sull'autore

Roberto Castaldo
Roberto Castaldo
Sono nato e vivo a Napoli, ed opero professionalmente nel mondo dell'informatica da più di vent'anni. In realtà l'informatica, insieme alla musica e ad altre poche cose, è stato da sempre un mio chiodo fisso, e la buona sorte mi ha aiutato a trasformarlo in un mestiere. Sin dalle mie primissime esperienze lavorative - insegnavo dattilografia ed i primi rudimenti di informatica in una scuola privata - mi sono trovato a mio agio nel settore della formazione e della divulgazione, certamente aiutato dai miei studi classici. Nel 1987 ho iniziato la mia attività come insegnante d'informatica in un Istituto Professionale Statale - per circa due anni sono stato il più giovane insegnante di ruolo d'Italia. Ho avuto svariate esperienze anche nel settore privato come sviluppatore (TPascal - lo ricordate? - VB, ASP e, più di recente VB.NET ed ASP.NET), ma soprattutto come docente e come divulgatore. Ho effettuato attività di formazione presso le più grandi realtà imprenditoriali italiane (IBM, Omnitel, Telecom Italia, TIM, Unicredito, Ekip, BNL, SSGRR), ma anche all'estero in qualità di docente e/o progettista di percorsi formativi; gli argomenti spaziano dal mondo Office fino al multimedia ed alla programmazione avanzata ASP ed ASP.NET. Ho collaborato con l'Istituto Italiano per gli Studi Filosofici di Napoli, ho redatto articoli/tutorial per un'importante rivista informatica (Win98 Magazine), ed ho partecipato allo sviluppo di CD-Rom Multimediali (IBM, Selfin, BNL) curando personalmente la registrazione dei commenti audio ed il montaggio delle musiche (CoolEdit), l'eventuale connessione a database remoti, l'assemblaggio degli elementi testuali, grafici e multimediali (Director 8) fino alla creazione del master definitivo. Negli anni 1998-2000 ho collaborato con la Gazzetta dello Sport Online curando, in occasione dei più importanti avvenimenti sportivi (Mondiali ed Europei di calcio, Giro d'Italia, Campionato di Serie A) le pagine contenenti la traduzione in inglese e francese degli articoli in italiano. Il mio compito consisteva nell'inviare ai miei traduttori la cronaca in italiano, riceverne la traduzione, creare le pagine inglesi e francesi del sito www.gazzetta.it e pubblicarle sul server, il tutto entro 90 minuti dalla fine dell'evento. Nel frattempo, mi avvicinavo in maniera sempre più approfondita alle problematiche legate all'accessibilità di siti web, progettando percorsi di formazione ad hoc, ed aderendo entusiasticamente al progetto webaccessibile.org. Sono stato per diversi mesi membro del XML Protocol Working Group del W3C, ed attualmente partecipo ai lavoro del WAI Web Content Accessibility Guidelines (WCAG) Working Group e del E&O Education ad Outreach Working Group.

Commenti

È presente 1 commento:

  1. […] Partiamo allora da qui e prendiamo ad esempio una scuola, domandandoci in che misura può essere identificata come contesto organizzativo predisposto all’apprendimento “per tutti”. Poniamoci dunque quello che potremmo definire un problema di design for all. […]

Rispondi

Link e informazioni