aggiornato il 12/6/2006 Sebastiano Nutarelli
La legge Stanca introduce forse un pericoloso principio: la separazione tra accessibilità ed usabilità era nota, ma l'obbligo di verifica dei requisiti raggiunti per le PA centrali solo della prima (la PA può così autocertificarsi come "accessibile" secondo la legge italiana, previo avviso al CNIPA che poi potrà verificare il tutto quando e se lo riterrà opportuno) pone la seconda in una indebita posizione di secondo piano (la valutazione della "qualità" di un sito web è a richiesta e a pagamento e costa non poco - è presumibile che saranno ben pochi a intraprendere questa strada, seppur meritevole, causa bugdet di progetto che non prevedono questi rincari).
Nessuno s'illude di misurare l'usabilità di un sito web come è possibile fare con l'accessibilità: oggettivamente sono due cose diverse, misurabile secondo dei parametri precisi la prima, più impalpabile (s'intenda come meno misurabile oggettivamente) la seconda (tant'è che nella Legge 4/2004 si parla di valutazione oggettiva per la prima e soggettiva per la seconda).
Nessuno s'illude di misurare l'usabilità di un sito web come è possibile fare con l'accessibilità: oggettivamente sono due cose diverse, misurabile secondo dei parametri precisi la prima, più impalpabile (s'intenda come meno misurabile oggettivamente) la seconda - nella Legge 4/2004, in ogni caso, si parla di valutazione oggettiva per la prima e soggettiva per la seconda, resta però inteso che sono presenti nell'allegato B del Decreto Ministriale 8 luglio 2005 i criteri di valutazione per la verifica soggettiva, per'altro trattati anche in precedenza su questo sito.
Sta di fatto che una realizzazione perfettamente conforme ai 22 requisiti tecnici (l'accessibilità prevista dalla normativa italiana) può tradursi in un pessimo applicativo se la progettazione a monte non tiene conto di tutti quei fattori che sono raggruppabili sotto il "tetto" dell'usabilità.
Sembra paradossale ma tanto sforzo "tecnico", magari da parte di sviluppatori esperti di accessibilità, WCAG, Section 508, requisiti tecnici, screen reader e quant'altro può essere vanificato se a monte non si è pensato ad una progettazione realmente "utente-centrica".
Da qui l'importanza delle due figure professionali (e diventasse un unico profilo professionale non ci guadagneremmo tutti?), il progettista di interfacce/ipertesti esperto di usabilità, che pensa, testa e realizza un progetto di ipertesto che poi verrà tradotto in XHtml accessibile dall'esperto di accessibilità (sviluppatore di interfacce e programmatore).
Tutto bene quel che finisce bene, dunque, ma per giungere a tale risultato le due figure professionali si devono parlare, conoscere e devono imparare ad integrarsi.
L'esperto di usabilità - il progettista - dovrebbe conoscere alla lunga i limiti di certe soluzioni magari "usabili" ma non pienamente "accessibili" (o per esempio i limiti di determinate scelte grafiche che costringono lo sviluppatore a realizzare un codice più "sporco" e dunque "piegato" alle esigenze di layout, cosa decisamente non positiva) e vice versa l'esperto di accessibilità - lo sviluppatore - dovrebbe sforzarsi sempre di assecondare la progettazione pensata al meglio dell'usabilità dell'applicativo finale dal progettista, magari spendendo giorni per trovare una soluzione tecnica accessibile che renda implementabile in XHtml ciò che il progettista aveva pensato "su carta" magari dopo interviste agli utenti potenziali, test utente si una simulazione in sola grafica, etc.
Le due figure devono ritenersi vicendevolmente fondamentali, perché lo sono - e quando una delle due sconfina nel campo dell'altra (ma come mai questa pagina non l'avete pensata così - lo sviluppatore al progettista - o viceversa, ma sei sicuro che non si può realizzare in un XHtml accessibile, è la soluzione ideale - il progettista allo sviluppatore) il gesto dev'essere inteso come un'intenzione atta alla miglioria del prodotto finale - nessuno "sconfina" indebitamente, sono proprio questi dialoghi che portano, previa spiegazione argomentata adeguatamente, lo sviluppatore a comprendere il perché di una scelta progettuale che magari gli costa una giornata in più di lavoro e il progettista a comprendere vincoli da rispettare per rendere determinate soluzioni accessibili per tutte le tipologie d'utenza.
Solo un team di lavoro così strutturato può produrre applicativi di successo e realmente accessibili, ossia fruibili dall'utente finale immediatamente, senza modelli mentali pre-costituiti di cui inevitabilmente si troverebbe sprovvisto.
La Pubblica Amministrazione italiana in tempi molto brevi si è trovata a dover realizzare per legge siti internet/intranet accessibili e usabili (cito dal Codice della PA Digitale); organizzarsi in modo da contemplare nel proprio organico (o valutare se la ditta appaltatrice ne è dotata) un gruppo di esperti di usabilità (progettazione ipertesti utente-centrica, test utente, realizzazione grafica che aiuti all'immediata comprensione, etc.) ed un gruppo di sviluppatori esperti di accessibilità (dunque aggiornati su ciò che verrà a livello tecnico ma anche a livello legislativo, su ciò che è in vigore, normative, linee guida, direttive, etc.) è la base per assicurarsi dei risultati vincenti e legalmente pubblicabili.
Ciò che ho notato in questi ultimi anni è che ci si muove ad ondate senza una programmazione ed una preventivazione di ciò che inevitabilmente è dietro l'angolo: la Legge Stanca ha compiuto quasi tutto il suo iter senza che se ne parlasse se non nei forum dedicati (dove già allora ci scervellavamo per capirne i contenuti, le sfumature, per renderla insomma anche più comprensibile a noi stessi, "addetti ai lavori") e nelle realtà aziendali lungimiranti, in cui la si era presa in considerazione sin dall'inizio - entrata in vigore si è scatenata la corsa all'accessibilità, con fraintendimenti ed errori di fondo a volte enormi e con un proliferare di corsi e di attività di formazione in genere molte delle quali non atte alla chiarificazione reale del panorama che si andava delineando.
Ora emerge (giustamente) l'importanza dell'usabilità (anch'essa esistente da tempo, anzi, a dirla tutta, forse come concetto già prima dell'introduzione del concetto di un "web accessibile") e massivamente ci si sposta su questa concezione - e qui la formazione è forse ancora più complessa, non ci sono veri e propri parametri (non parlo delle teoriemaxime e del "Don't make me think", per intenderci) ma è forse più una questione di sensibilità e attenzione a calarsi nel ruolo dell'utente finale che non sa nulla di tutto ciò che sa il progettista dell'applicativo a monte o del know-how che ha ormai acquisito durante la progettazione - l'utente non sa nulle e neanche gli interessa, vuole solo fruire di un servizio web che la PA gli offre senza perdere troppo tempo e senza trovarsi di fronte a qualcosa di faticoso e macchiavellico.
La soluzione, con tutta probabilità, come sempre sta nel mezzo: impostare la propria realtà produttiva (di qualunque dimensione essa sia) provvedendo a dotarsi delle figure professionali necessarie a garantire una realizzazione web per il cittadino realmente "utile".
Parola stranamente inutilizzata in questi ultimi anni, tra accessibile ed usabile ci siamo persi forse un po' negli eccessi dei singoli campi di competenza.
Applicativi web "utili" per i cittadini: progettati tenendo conto dei maggiori principi dell'usabilità e soprattutto dei feedback utente nei test di usabilità che via via andranno creando un preziosissimo bagagli di esperienza per i progettisti, e realizzati seguendo i requisiti imposti dalle normative vigenti considerando quell'indefinibile concetto di "accessibilità reale" che si delinea e diventa meno vago solo con l'esperienza sul campo (tanta...) e anche qui, grazie ai feedback con gli utenti, disabili e non.
Usabilità e accessibilità insomma sullo stesso pianeta: è così che a mio parere va definendosi una nuova figura professionale, l'esperto di accessibilità e di usabilità per arrivare ad evitare la realizzazione di applicativi web perfettamente accessibili ma totalmente inusabili o viceversa per il cittadino, che, inevitabilmente, statene sicuri, ringrazierà.
Buon e-gov a tutti...!
copyright | credits | privacy | accessibilità | valid xhtml 1.1 | valid css | rss