4.4. Accorgimenti per realizzare un servizio di e-banking accessibile

Moduli

Uno dei punti focali di interazione tra utente e banca nell’home banking sono i moduli (meglio conosciuti come “form”). È necessario applicare alcuni accorgimenti per rendere accessibili i moduli (https://www.webaccessibile.org/argomenti/argomento.asp?cat=295 – “Moduli (Form) Accessibili” – Maurizio Vittoria), cercando soprattutto di rendere accessibili gli elementi come i menu a tendina, sia che vengano utilizzati da utenti con mouse sia da utenti che navigano tramite tastiera.

È opportuno inoltre chiarire brevemente lo scopo del form e distinguere in blocchi separati le informazioni obbligatorie da quelle non obbligatorie. Se il form è suddiviso in più pagine, esplicitare di quante pagine si tratta, possibilmente dando a ciascuna pagina una   denominazione e specificando a che punto della compilazione l’utente è arrivato (es: Dati anagrafici – pagina 1 di 5).

Si raccomanda di non utilizzare automatismi (javascript) per l’invio automatico del form, ma di lasciare all’utente il compito di inviarlo tramite apposito comando. È altresì importante assicurarsi che quanto inserito nel form sia poi conservabile/riproducibile dall’utente.

Nelle opzioni di scelta del tipo “menu a tendina” si possono inoltre raggruppare i termini delle opzioni in modo organizzato, con delle etichette per rendere facilmente fruibili le opzioni e semplificare la scelta.

Tabelle

Per le persone normodotate, la percezione visiva di una tabella di dati è molto importante perché permette una rapida scansione in entrambe le dimensioni della tabella, e ciò consente di focalizzare rapidamente l’attenzione sulle informazioni che interessano. Inoltre, gli accorgimenti adottati per migliorare la visualizzazione della struttura tabellare (allineamenti, linee di separazione tra colonne, diversi colori di sfondo per righe adiacenti) facilitano lo spostamento dell’attenzione da una cella all’altra e rendono agevole capire come cambia il tipo di informazione.

Nel caso la tabella debba venir percepita mediante un altro canale sensoriale (auditivo, nel caso di sintesi vocali, o tattile, nel caso di display Braille), le precedenti considerazioni non valgono più: le tecnologie assistive leggono i dati tabellari una riga alla volta, da sinistra a destra e dall’alto verso il basso. Anche semplicemente capire velocemente che tipo di informazioni vengano presentate e come esse siano correlate diventa un’operazione lunga, noiosa e affaticante, in quanto la persona deve memorizzare una gran quantità di informazioni prima di avere un quadro completo della tabella. Inoltre, lo spostamento da una cella all’altra è decontestualizzato, nel senso che a meno che la persona non ricordi la disposizione delle colonne e delle righe e delle loro intestazioni è impossibile sapere cosa significhi il contenuto della cella a cui si è appena giunti.

Per questo motivo è necessario in primo luogo fornire una breve descrizione del contenuto della tabella, in modo che tale contenuto possa venir letto dall’utente prima di iniziare l’esame dettagliato del contenuto della tabella. Questa sorta di didascalia, che non viene visualizzata dai browser, serve alle persone che utilizzano tecnologie assistive come sommario della tabella per capire se vale la pena esaminarla a fondo oppure se la si può saltare.

È necessario inoltre accertarsi che le tabelle siano leggibili anche se “linearizzate”, cioè quando le celle vengono lette in maniera seriale, una riga dopo l’altra. Inoltre le intestazioni di righe e colonne devono essere identificate correttamente mediante gli opportuni elementi e attributi HTML, al fine di permettere alle tecnologie assistive di associare e presentare correttamente i blocchi di dati.

Aiuti e demo on-line

Si raccomanda di rendere disponibile sul proprio sito una demo on-line del servizio, che dia la possibilità di utilizzare il servizio di Internet banking con un codice utente dimostrativo agganciato a posizioni fittizie e dati di fantasia. Tale demo dovrà replicare lo svolgimento di tutte le operazioni che la clientela abilitata ai servizi di e-banking può effettuare, bloccandosi esclusivamente al comando finale di esecuzione dell’operazione. Questo strumento è necessario affinché la clientela potenziale, disabile o normalmente abile, possa provare il servizio, sapere quali sono le funzioni di cui può disporre e avere una dimostrazione pratica dell’accessibilità del sito. Secondariamente, essa permette di fornire a terzi (associazioni di disabili, consulenti, etc.) un ambiente sul quale effettuare valutazioni inerenti all’accessibilità del sito, senza compromettere la sicurezza del servizio e la privacy delle informazioni.

La struttura di aiuto on-line dovrebbe inoltre permettere in qualsiasi momento un accesso veloce alle pagine di domande frequenti (FAQ), moduli di contatto etc.

Feedback e correzione degli errori

Ogni qualvolta una procedura va a buon fine, è opportuno comunicarlo all’utente in maniera evidente, rassicurandolo con parole incoraggianti come “successo”, “corretto”, etc.

In caso di errore, esso deve essere segnalato in maniera semplice e immediatamente individuabile, veicolando il messaggio non solo tramite il colore (es. rosso) o un elemento sonoro, poiché questi segnali non verrebbero percepiti ad esempio da un disabile visivo o uditivo. Deve essere offerta la possibilità di annullare l’errore più recente, senza necessità di reinserire le informazioni corrette. Si consiglia inoltre di evitare parole come “sbagliato”, “illegale”, “fatale”, “critico”, che scoraggerebbero l’utente.

Finestre pop-up

Alcuni siti di home banking utilizzano finestre pop-up per segnalare ad esempio offerte speciali o nuovi servizi. L’apertura di una nuova finestra, seppure non invasiva, è sempre qualcosa che può generare confusione, specie nei non esperti. A lungo andare, essa può risultare fastidiosa alla generalità degli utenti che accede al sito, distogliendone l’attenzione. A questo proposito, è da notare che ultimamente gli utenti utilizzano spesso programmi che automaticamente bloccano le finestre pop-up e quindi qualsiasi messaggio venga inviato con tale tecnologia raggiungerà positivamente solo una parte della clientela.

All’utente con disabilità le finestre pop-up possono invece causare ulteriori problemi di navigazione, in quanto aprendosi successivamente alla finestra principale si sostituiscono a quest’ultima, disorientando l’utente e causando conflitti con le tecnologie assistive, che, una volta aperta la nuova finestra, non consentono di ritornare alla finestra principale. La perdita di controllo è ancor maggiore con i cosiddetti pop-up di navigazione, quelli che consentono l’interazione o il passaggio di dati con la finestra principale del browser.

È consigliabile inserire eventuali offerte speciali o argomenti su cui si vuole attirare l’attenzione dell’utente in modo facilmente identificabile nella pagina di ingresso al servizio. All’interno delle transazioni, si raccomanda di non utilizzare finestre secondarie che dialogano con la finestra principale del browser e in ogni caso di avvisare l’utente ogni qual volta il collegamento si apre in una nuova finestra.

Tasti di accesso rapido

I tasti di accesso rapido (access key) sono molto utili per consentire di accedere in maniera veloce ad alcune sezioni del sito tramite il solo uso della tastiera. Per la loro creazione vanno definite combinazioni semplici di tasti che risultino di facile memorizzazione e richiedano una modesta abilità manuale per l’esecuzione. Si consiglia comunque di non abusare di questo strumento e di rendere disponibili i tasti di scelta rapida solo per l’accesso alle aree principali del sito: una proliferazione di queste combinazioni le renderebbe difficili da ricordare e porterebbe quindi a non utilizzarle. Inoltre, è assolutamente necessario controllare che tali combinazioni non vadano in conflitto con quelle impostate di default nei sistemi operativi e negli ausili.

Configurazione minima di sistema

Un sito accessibile deve consentire un’ampia compatibilità con tutte le tecnologie, permettendo a chiunque di usufruirne indipendentemente dalla dotazione tecnologica, dallo strumento di accesso, dalla tipologia di connessione e dalla modalità di interazione con la macchina. Considerata la dimestichezza che gli utenti sviluppano nell’utilizzo di una determinata versione del software, nonché gli elevati costi delle tecnologie assistive utilizzate da alcune categorie di disabili, non bisogna dare per scontato l’immediato passaggio della clientela alle versioni più aggiornate disponibili sul mercato.

Se tuttavia alcuni vincoli tecnologici (vedi ad esempio par. 4.5) richiedono per la completa fruizione di un sito web l’utilizzo di una configurazione minima di sistema (versione minima di browser, tecnologie assistive, plug-in, etc.), queste indicazioni devono essere specificate in maniera evidente ed esaustiva all’interno del sito.

Motore di ricerca

Per agevolare la fruibilità del sito, si consiglia di rendere disponibile un motore di ricerca interno. È bene porre la funzionalità di ricerca in evidenza e non complicare il riquadro di ricerca con opzioni avanzate, da rendere invece visibili su una pagina separata di “ricerca avanzata”.

Portali vocali

Si sconsiglia lo sviluppo di portali vocali, cioè di siti dotati di una funzionalità che “vocalizza” il contenuto e i comandi presenti sulle pagine web. Questi siti, molto pesanti nella navigazione, creano ulteriori problemi ai disabili poiché entrano in conflitto con le sintesi vocali da loro utilizzate; non da ultimo, essi hanno un costo di realizzazione molto superiore a quello di un sito accessibile.

 

Potrebbero interessarti anche i seguenti articoli

  • 4.2. Un approccio graduale e scalabile4.2. Un approccio graduale e scalabile Muovere verso l’accessibilità comporta uno sforzo organizzativo, tecnologico e culturale che coinvolge l’intera banca. D’altro canto, è […]
  • 3.1. Accessibilità dei servizi di home banking3.1. Accessibilità dei servizi di home banking L’home banking è il sistema utilizzato dalle banche per l’erogazione a distanza di servizi e prodotti rivolti alla clientela (il cliente “da […]
  • 2.1. Accessibilità e usabilità2.1. Accessibilità e usabilità Al di là degli aspetti tecnici, un sito accessibile è in primo luogo un sito “fatto bene”, usabile. L’usabilità è un concetto […]
  • GlossarioGlossario Accessibilità Proprietà di un sistema informatico (software, sito web, etc.) di essere fruibile da una gamma molto ampia di utenti, tra cui le persone […]
  • Appendice – Il decalogo dell’accessibilitàAppendice – Il decalogo dell’accessibilità Le Web Content Accessibility Guidelines (WCAG) 1.0 (cfr. par. 2.2) comprendono una serie di documenti, tra cui le Techniques for WCAG 1.0 […]
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

Nessun commento

    Rispondi

    Link e informazioni