Accessibilità, la sfida è mutare i processi di produzione

I fattori che concorrono alla produzione di applicazioni web di qualità sono molti, si pensi ad esempio a caratteristiche infrastrutturali come la robustezza, la sicurezza e le prestazioni oppure ad aspetti di interazione con l’utente come l’usabilità e l’accessibilità delle interfacce. Negli ultimi anni le caratteristiche di interazione sono diventate di particolare importanza perché in alcuni contesti, tipicamente della pubblica amministrazione, esistono vincoli legislativi che impongono, nei fatti, il rispetto di particolari requisiti tecnici. È il caso della legge 4/2004, contenente Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici.

La necessità di normare tecnicamente l’interazione tra utente e sistema informativo, attraverso la produzione di requisiti tecnici ai quali le applicazioni devono conformarsi, ha l’obiettivo di garantire che le applicazioni siano utilizzabili senza problemi anche da chi, a causa di condizioni di disabilità o di limitazioni tecnologiche, non possa interagire con esse utilizzando strumenti di navigazione tradizionali come il classico browser web. In questi casi l’utente è spesso obbligato a utilizzare appositi strumenti hardware e software, le tecnologie assistive, che agevolano la fruizione dei sistemi informativi tentando di superare, almeno parzialmente, alcune tipologie di disabilità. Si pensi ad esempio ad uno strumento software in grado di leggere all’utente il contenuto dello schermo consentendo quindi la fruizione di contenuti e servizi anche alle persone non vedenti.

Per garantire l’accessibilità dei sistemi informativi è quindi necessario fare in modo che questi siano conformi a un particolare insieme di requisiti tecnici, più in generale questo significa, se si vuole ottenere il massimo dell’efficienza e del controllo dei costi, intervenire sui processi di produzione del software.

I processi di produzione tradizionali

I classici processi di sviluppo del software, dal modello a cascata fino ai più recenti approcci agili, passando per i modelli iterativi ed evolutivi, hanno due grosse limitazioni. Innanzi tutto sono concepiti avendo come principale obiettivo il software da realizzare e non necessariamente l’utente che poi lo utilizzerà; solitamente, inoltre, esiste una forte specializzazione dei professionisti all’opera nella varie fasi del processo. Chi si occupa di analisi funzionale e dei requisiti, per esempio, dovrà essere un esperto di processi funzionali e dovrà guidare l’utente nella loro razionalizzazione e ottimizzazione, indipendentemente dagli aspetti tecnologici della realizzazione.

Allo stesso modo, in altre fasi del processo, chi si occupa della scrittura del codice di business dovrà essere un bravo interprete di quanto precedentemente progettato e dovrà verificarne la rispondenza ai requisiti funzionali di dettaglio, indipendentemente dal contesto complessivo. Se in questo scenario inseriamo l’ulteriore complessità di dover gestire anche la conformità ai requisiti tecnici della legge 4/2004, e di doverli successivamente verificare secondo quanto indicato dalla normativa, potremmo ragionevolmente pensare di delegare tali attività, e quindi la responsabilità sulla conformità complessiva dell’applicazione, unicamente alle fasi di scrittura del codice e di test. Agendo in questo modo però si rischierebbe di avere delle analisi funzionali contenenti scelte di interfaccia o indicazioni comportamentali incompatibili con alcuni dei requisiti tecnici.

A titolo di esempio si pensi alla richiesta dell’utente di poter aprire una nuova finestra per ottenere informazioni di dettaglio o per selezionare un oggetto da una lista: se l’analista riceve questo requisito senza indicare all’utente che questo comportamento non è consentito, il rischio concreto è di accorgersi della non conformità soltanto nella fase di codifica oppure, nella peggiore delle ipotesi, nella fase di verifica dell’accessibilità, con il rischio di dover innescare un riciclo che interessi tutto il processo di sviluppo, a partire dall’analisi funzionale. Questo ci fa capire come i processi di sviluppo tradizionali siano il più delle volte inadeguati per governare con efficienza progetti che debbano essere conformi ai requisiti tecnici per l’accessibilità. Questo vale a maggior ragione se si pensa alla legge 4/2004 che prevede un’apposita attività di verifica tecnica della conformità.

Per ottenere un processo di produzione adeguato ed efficiente è quindi necessario agire contemporaneamente in due direzioni: da un lato aggiungere fasi di prototipazione e verifica che creino feedback e accorcino i ricili, dall’altro fornire un livello di formazione adeguato sui temi dell’accessibilità a tutti gli attori coinvolti nel processo. Si tratta quindi di integrare i processi tradizionali con le metodologie tipiche dello User-Centered Design Process, il processo di sviluppo centrato sull’utente.

Adottare lo User-Centered Design Process

L’Ucdp è un processo iterativo basato sulla produzione di prototipi e su alcune macrofasi che devono essere implementate in relazione al contesto cui il processo si applica. Nell’implementazione del Centro di Competenza per l’Accessibilità del Gruppo Engineering, sono state identificate tre macrofasi: analisi e design, progettazione e sviluppo, deploy ed esercizio. All’interno del processo sono state poi inserite adeguate attività di prototipazione, sperimentazione e test. Di particolare rilevanza è la fase di prototipazione, inserita immediatamente in cascata alla raccolta dei requisiti e delle specifiche funzionali, in quanto la produzione di un prototipo di qualità è la chiave del successo dell’intero processo di sviluppo.

Progettazione basata sul modello User Centerd Design Process

Il prototipo ha ben tre livelli successivi di raffinamento: si parte dal prototipo concettuale, che descrive sommariamente l’interfaccia e i suoi comportamenti, si passa per il prototipo grafico, che presenta con buona approssimazione gli elementi di layout che verranno realizzati, e si arriva al prototipo fisico, che implementa nel dettaglio le principali componenti dell’interfaccia applicativa. Quest’ultimo è direttamente realizzato in linguaggio xHtml in modo da essere totalmente riutilizzato nella fase di codifica.

Ogni tipologia di prototipo viene seguita da un’analoga fase di test per verificarne la conformità rispetto ai requisiti tecnici: sul prototipo concettuale è possibile verificare immediatamente quali sono i visual design pattern utilizzati e quindi, se necessario, intervenire per correggere alcuni modelli comportamentali. Sul prototipo grafico, invece, è possibile verificare direttamente la conformità ai requisiti tecnici che regolamentano l’uso dei colori e la distinguibilità delle informazioni. Sul prototipo fisico, infine, è possibile effettuare l’intera verifica tecnica prevista dalla normativa e correggere eventuali non conformità, tutto questo senza aver scritto una sola riga di codice.

La fase di test che segue lo sviluppo dovrà occuparsi degli aspetti funzionali, prestazionali, di sicurezza, ma anche della verifica di conformità ai requisiti tecnici. In ogni caso, poiché il codice di interfaccia è stato integralmente riutilizzato, è ragionevole aspettarsi pochi problemi legati alla conformità e comunque di tipo esclusivamente tecnico in quanto gli aspetto generali e comportamentali dell’interfaccia sono già stati verificati in precedenza, di conseguenza il livello di riciclo sarà minimo. Con questo metodo, inoltre, si liberano i programmatori di business dall’incombenza di scrivere codice di interfaccia, cosa che fanno spesso bene, ma che, obiettivamente, non è sempre il loro mestiere.

La formazione e i costi

Perché tutto funzioni correttamente è necessario che ciascun attore coinvolto conosca, e quindi sia in grado di applicare alle proprie fasi del processo, anche quegli aspetti dell’accessibilità che possono avere impatti sui propri deliverable. Questo per evitare, come si diceva in precedenza, che l’utente chieda e ottenga comportamenti che poi sono irrealizzabili se si vuole il rispetto della conformità ai requisiti tecnici. È necessario quindi formare correttamente tutti i professionisti che operano su progetti vincolati all’accessibilità e non soltanto chi dovrà poi scrivere il codice in modo conforme alla normativa.

Qualunque processo di sviluppo dovrebbe essere orientato a massimizzare la qualità del prodotto minimizzando contemporaneamente i tempi e costi di produzione. Il processo applicato in Engineering raggiunge questi obiettivi perché anticipa il più possibile la fase di verifica della conformità, risolvendo i problemi alla radice, e contemporaneamente riutilizza tutto il codice prototipale prodotto, non esistono quindi attività a perdere. Inoltre, poiché il prototipo viene realizzato da personale specializzato nelle interfacce, è solitamente di qualità superiore e più omogeneo rispetto a quello che potrebbe essere prodotto da chi per mestiere si occupa di scrivere componenti di business.