Progettare per l'indipendenza dal dispositivo

Nel glossario delle WCAG 1.0 la voce "indipendente dal dispositivo" (device independent ) è così spiegata:

Gli utenti devono poter interagire con un programma utente (e con il documento che esso riproduce) usando i dispositivi di input e di output supportati, secondo la loro scelta e in accordo con i loro bisogni. I dispositivi di input possono includere dispositivi di puntamento, tastiere, periferiche braille, puntatori a testa, microfoni e altro. I dispositivi di output possono includere monitor, sintetizzatori vocali e dispositivi braille.

Si noti che "supporto indipendente dal dispositivo" [device-independent support] non significa che i programmi utente devono supportare tutti i dispositivi di input e di output. I programmi utente dovrebbero fornire meccanismi di input e di output ridondanti per i dispositivi che sono supportati. Per esempio, se un programma utente supporta input da tastiera e da mouse, gli utenti dovrebbero essere in grado di interagire con qualsiasi funzionalità usando indifferentemente la tastiera o il mouse.

Nelle brevi note di spiegazione a corredo di questa linea guida, le WCAG 1.0 aggiungono:

In generale, le pagine che consentono di interagire tramite tastiera sono accessibili anche attraverso input vocale o interfacce a linea di comando.

Stringendo, la questione dell'indipendenza dal dispositivo si risolve appunto nella capacità di progettare documenti con cui gli utenti possano interagire usando indifferentemente la tastiera o il mouse. Ciò vuol dire adottare una serie di precauzioni, a seconda del tipo di contenuto: per esempio, fornire link testuali ridondanti per le mappe immagine; scegliere gestori di evento a livello di applicazione come onload ecc.

Punto di controllo 9.1, priorità 1

Il motivo per cui le mappe immagine lato server sono meno accessibili della mappe lato client è che non possono essere rese indipendenti dal dispositivo. Come è stato spiegato nel commento al punto di controllo 1.2 (Capitolo 4), l'utente può interagire con una mappa lato server per mezzo del mouse, o di uno strumento di puntamento analogo, ma non per mezzo della tastiera: il server reagisce infatti all'invio delle coordinate che rappresentano la posizione di un puntatore sulla mappa. Giustamente, perciò, il punto di controllo 9.1 suggerisce di adoperare mappe immagine lato client al posto di quelle lato server ogni volta che sia possibile (e non c'è in verità un poligono, per quanto irregolare, che non possa essere descritto su una mappa lato client, associando le opportune coordinate al valore poly dell'attributo shape dell'elemento MAP).

L'indipendenza dal dispositivo nei siti di mappe interattive

Esistono però degli impedimenti oggettivi che rendono difficile, se non impossibile, usare in alcune situazioni, per altro molto comuni, le mappe immagine lato client. Il riferimento è, in particolare, alle applicazioni per la gestione di informazioni cartografiche, quali per esempio i servizi di reperimento di indirizzi e di generazione di percorsi automobilistici forniti da Google Maps , Tuttocittà e altri. La quantità di informazioni presenti in questo tipo di mappe – confini geografici, città, fiumi, laghi, elevazione del territorio, strade, luoghi da visitare, alberghi, ristoranti, centri commerciali, immagini satellitari alternabili alle cartine ecc. – è tale, e le possibilità d'interazione con l'utente così complesse, che non è possibile gestire tutto ciò per mezzo di normali mappe lato client.

Per la verità, anche le classiche mappe immagine lato server sono ormai inadeguate allo scopo. I servizi come Google Maps sono sofisticate applicazioni interattive, che fanno largo uso di JavaScript e AJAX per creare una serie di processi dinamici tra client e server, con lo scopo di minimizzare i tempi di risposta del server e di consentire una gran varietà di interazioni, tra cui l'ingrandimento e il rimpicciolimento dell'area visualizzata, lo spostamento sul piano in tutte le direzioni, la visualizzazione di informazioni accessorie sui luoghi, la sovraimpressione all'immagine del territorio dei percorsi calcolati, il passaggio dalla vista fotografica a quella cartografica, e viceversa ecc. Tutte queste funzioni dipendono strettamente dall'uso di un dispositivo di puntamento come il mouse, ma soprattutto dalla possibilità dell'utente di orientarsi con la vista. Per tale ragione, conferire una vera accessibilità a questo tipo di mappe interattive, indipendentemente dalla tecnologia con cui sono realizzate, è tutt'altro che semplice.

È infatti una questione concettuale, ancor più che tecnologica: non si tratta, cioè, di trovare il modo per consentire all'utente di attivare i collegamenti anche con la tastiera, o meglio non si tratta solo di questo. La questione centrale, per l'accessibilità, è consentire – in associazione con l'esplorazione visiva delle mappe, in cui l'interazione avviene principalmente per mezzo del mouse – anche un tipo d'interrogazione differente, che prescinda dalla vista e dall'uso del mouse e che ottenga risultati anch'essi indipendenti dall'uso della vista e del mouse. Per questo è da considerare un'ottima soluzione quella, adottata da Google Maps e da altri, di fornire, in risposta alla ricerca di un percorso, non solo la visualizzazione del tracciato sulla cartina, ma anche l'elenco testuale delle singole tappe, con l'indicazione di distanze e tempi di percorrenza (Figura 14.1).

Dal punto di vista dell'accessibilità, insomma, la possibilità di un uso indipendente dal dispositivo di input è una delle priorità che i siti che forniscono mappe interattive devono risolvere (l'altra è quella di garantire la possibilità di ottenere informazioni anche in mancanza di supporto per JavaScript, tema che abbiamo già trattato nel Capitolo 11).

Inizio pagina

Punto di controllo 9.2, priorità 2

Questo punto di controllo si aggancia alla linea guida 8, col suo unico punto di controllo: mentre lì si chiede di assicurare in generale la diretta accessibilità delle interfacce utente incorporate, qui si chiede di garantire l'utilizzo indipendente dal dispositivo degli elementi di un'interfaccia incorporata. Poiché questo è uno dei requisiti necessari per la diretta accessibilità di un'interfaccia utente, possiamo dire che, se non è soddisfatto il punto di controllo 9.2, allora non è soddisfatto neppure il punto di controllo 8.1, e viceversa.

Per una trattazione dettagliata su come soddisfare le richieste della linea guida 8, si vedano i Capitoli 11, 12 e 13.

Inizio pagina

Punto di controllo 9.3, priorità 2

Gestori di evento logici

Il punto di controllo 9.3 è strettamente imparentato con il 6.4, che richiede che i gestori di evento associati agli script siano indipendenti dal dispositivo di input. Il 9.3 richiede che siano usati gestori di evento logici. Cosa vuol dire logici? Vuol dire che descrivono un'azione, senza alcun riferimento al tipo di dispositivo che la può produrre. Gestori di evento logici sono per esempio onselect e onfocus: uno script a essi associato viene attivato quando un elemento è selezionato o riceve il focus, qualsiasi sia la modalità con cui ciò avviene (tramite mouse, tastiera o altro). Sono invece gestori di evento dipendenti dal dispositivo onclick, onmouseover, onmouseout, onkeypress, onkeydown, onkeyup ecc., che legano gli script ad azioni rispettivamente del mouse e della tastiera (si noti, però, che i programmi utente possono decidere di gestire questi eventi in modo indipendente dal dispositivo).

Dal punto di vista dell'accessibilità, l'uso dei gestori logici è preferibile a quello dei gestori di evento dipendenti dal dispositivo, perché evita agli sviluppatori la necessità di specificare un doppio gestore di evento (uno per il mouse e uno per la tastiera), con le conseguenti differenze di interpretazione da parte dei browser, di cui abbiamo parlato nel commento al punto di controllo 6.4, nel Capitolo 9.

Inizio pagina

Punto di controllo 9.4, priorità 3

L'attributo tabindex e la navigazione da tastiera

Il punto di controllo 9.4 richiede agli sviluppatori di considerare l'ordine sequenziale in cui sono disposti i vari elementi di un documento (ordine che corrisponde alla sequenza dei contenuti nel codice di marcatura). La raccomandazione ha lo scopo di favorire chi naviga in modalità non visuale e chi usa la tastiera invece che il mouse per selezionare gli elementi attivabili della pagina. Si parla di "ordine di tabulazione", perché la navigazione da tastiera avviene, nella maggior parte dei programmi utente, tramite pressioni successive del tasto Tab.

Gli sviluppatori possono modificare la sequenza naturale di attivazione degli elementi di un documento, usando in modo appropriato l'attributo tabindex. Una simile precauzione potrebbe essere utile, per esempio, in una pagina che contiene dei campi modulo, preceduti da un menu di navigazione o da un testo contenente vari collegamenti: impostando valori di tabindex minori per i campi modulo e maggiori per i collegamenti che li precedono, si consentirà a un utente che navighi via tastiera di selezionare per primi i campi modulo, permettendogli così di raggiungere rapidamente il contenuto principale del documento.

Riportiamo di seguito in traduzione italiana il brano delle specifiche HTML 4.01 che definisce le regole di utilizzo dell'attributo tabindex .

Questo attributo specifica la posizione dell'elemento corrente nell'ordine di tabulazione del documento corrente. Il suo valore deve essere un numero compreso tra 0 e 32767. I programmi utente dovrebbero ignorare gli zero iniziali.

L'ordine di tabulazione definisce l'ordine in cui gli elementi riceveranno il focus, quando navigati via tastiera dall'utente. L'ordine di tabulazione può comprendere elementi annidati all'interno di altri elementi.

Gli elementi che possono ricevere il focus dovrebbero essere navigati dai programmi utente in base alle seguenti regole:

Sono navigati per primi gli elementi che supportano l'attributo tabindex e gli assegnano un valore positivo. La navigazione procede dall'elemento con il valore di tabindex minore all'elemento con il valore maggiore. Non è necessario che i valori siano sequenziali né che comincino con un valore particolare. Gli elementi che hanno identici valori di tabindex dovrebbero essere navigati nell'ordine in cui appaiono nel flusso dei caratteri [cioè nella sequenza del codice].

Sono navigati successivamente gli elementi che non supportano l'attributo tabindex o che lo supportano e a cui è stato assegnato un valore di "0". Questi elementi sono navigati nell'ordine in cui appaiono nel flusso dei caratteri.

Gli elementi che sono disabilitati non partecipano all'ordine di tabulazione.

I seguenti elementi supportano l'attributo tabindex: A, AREA, BUTTON, INPUT, OBJECT, SELECT e TEXTAREA.

Dopo la teoria, la pratica. L'esempio che proponiamo, adattato alla lingua italiana, è tratto anch'esso dalle Specifiche HTML 4.01 e applica i concetti appena definiti: un programma utente conforme dovrebbe mettere al primo posto nell'ordine di tabulazione l'elemento BUTTON, anche se condivide il valore 1 di tabindex con il primo dei successivi elementi INPUT: ciò perché BUTTON viene per primo nel flusso dei caratteri. Poi dovrebbero essere attivati, nell'ordine, i tre elementi INPUT e per ultimo l'elemento A, anche se nel flusso dei caratteri viene per primo. Si noti che il valore di tabindex di A è 10: ciò che conta è che sia maggiore del valore immediatamente precedente (3), mentre non ha importanza il fatto che nella sequenza manchino dei numeri.

Va segnalato che i tasti da usare per la navigazione da tastiera, e dunque il modo di giovarsi di un ordine di navigazione definito via tabindex, dipendono dal sistema con cui il browser usato dall'utente implementa questo meccanismo. Non tutti i browser, infatti, si comportano allo stesso modo. Stavolta, però, la colpa non è di una guerra commerciale tra formati proprietari, ma della libertà d'implementazione che le Specifiche HTML 4.01 hanno lasciato ai produttori, riguardo a come gestire la navigazione da tastiera. Il paragrafo su tabindex è infatti concluso, nelle Specifiche, da una nota che avverte:

Tasti di tabulazione (tabbing keys). L'effettiva sequenza di tasti che produce la navigazione da tastiera o l'attivazione di un elemento dipende dalla configurazione del programma utente (per esempio: il tasto Tab è usato per la navigazione e il tasto Invio è usato per attivare un elemento selezionato).

I programmi utente possono definire anche sequenze di tasti per navigare l'ordine di tabulazione al contrario. Quando è raggiunta la fine (o l'inizio) dell'ordine di tabulazione, i programmi utente possono ripetere il ciclo dall'inizio (o dalla fine).

All'atto pratico, la maggior parte dei browser – posto un documento che contiene una serie di valori positivi di tabindex e, insieme con quelli, altri elementi suscettibili di ricevere il focus – si comporterà nel modo seguente: tutti gli elementi ricevono il focus attraverso pressioni successive del tasto Tab, a partire da quelli con i valori minori di tabindex, per finire con quelli che non usano affatto l'attributo. L'ordine di tabulazione può poi essere percorso a ritroso mediante la combinazione di tasti Shift + Tab. La principale eccezione è costituita da Opera. Questo browser può dare all'utente inesperto l'impressione che la navigazione da tastiera sia difettosa: infatti la pressione ripetuta del tasto Tab sposta il focus solo sugli elementi che hanno un valore positivo di tabindex, creando un ciclo dal quale sembra che non vi sia uscita. In realtà, gli elementi privi di tabindex possono essere navigati da tastiera mediante la pressione di Shift + frecce direzionali, con la possibilità di spostarsi in tutte le direzioni tra gli elementi attivabili. È possibile inoltre spostarsi avanti e indietro tra i collegamenti premendo in successione, rispettivamente, i tasti A e Q. In ogni caso, l'esistenza in Opera di due sistemi complementari di navigazione da tastiera non ci sembra una scelta felice dal punto di vista dell'usabilità, dal momento che aumenta il carico cognitivo per l'utente.

Inizio pagina

Rischi di disorientamento per gli utenti di screen reader

L'accessibilità è un sapere giovane e in trasformazione, che, per produrre reali benefici per gli utenti, deve essere di continuo verificato sul campo. Lo sviluppatore, cioè, non può limitarsi ad applicare la teoria in modo astratto, perché la teoria invecchia rapidamente, a causa dell'evoluzione delle tecnologie. Ciò è particolarmente vero per l'uso dell'attributo tabindex: a causa del progresso degli screen reader, la presenza in un documento di un ordine di navigazione definito con tabindex può diventare un ostacolo anziché un aiuto per la navigazione.

Riportiamo a tal proposito la spiegazione che ci ha inviato via e-mail, come comunicazione personale, uno sviluppatore non vedente, Leo Maria Cerreta, che è non solo un utente di screen reader, ma anche un competente conoscitore delle loro complesse funzionalità.

Con l'avvento del supporto da parte degli screen reader alla semantica del Web e quindi con l'accesso al DOM, gli screen reader hanno aggiunto una seconda modalità di interazione con le pagine web: quella basata sulla virtualizzazione del documento, che altro non è che il caricare in un buffer di memoria dello screen reader il documento HTML attualmente visualizzato dal browser, allo scopo di renderlo navigabile all'utente per mezzo di appositi comandi. Tale modalità viene chiamata modalità virtuale proprio perchè l'utente, pur avendo l'impressione di interagire con il browser, interagisce di fatto direttamente e quasi solamente con lo screen reader, cioè con la rappresentazione della pagina web caricata nel buffer. Cio permette tutta una serie di operazioni, che altrimenti non sarebbe possibile compiere appoggiandosi unicamente all'interfaccia del browser. Tuttavia, essendo la rappresentazione della pagina web nel buffer una rappresentazione linearizzata secondo il sorgente HTML, vi sono ovviamente delle incongruenze in termini di layout rispetto a quanto appare a schermo; ma, del resto, questo non è altro che l'effetto della separazione della presentazione dal contenuto, e quindi è normale che sia così.

Però da qui sorge un problema: se si utilizza tabindex per creare un ordine di tabulazione diverso da quello fornito dal sorgente HTML, al fine di rendere tale ordine di tabulazione maggiormente coerente con il layout della pagina presentata a schermo, si produrrà una soluzione efficace solo per chi vede lo schermo o per chi utilizza uno screen reader appoggiandosi unicamente al browser e ignorando la virtualizzazione del documento. Navigare nelle pagine web senza l'uso dell'ambiente virtuale è ancora possibile con gli screen reader, ma è una modalità usata per lo più solo nel momento in cui vi è la necessità di compilare dei campi in un modulo. JAWS chiama tale modalità "modalità maschere". Per contro, la modalità virtuale è impiegata unicamente per la navigazione e la lettura delle pagine web, visto che si tratta di una navigazione all'interno di un buffer di memoria e che, quindi, non sarebbe possibile editare nulla, motivo per il quale, quando vi è da compilare qualche modulo, risulta necessario passare alla modalità maschere, disattivando così l'ambiente virtuale.

La modalità virtuale degli screen reader è stata già introdotta nel Capitolo 11, nei paragrafi dedicati ai problemi di accessibilità legati all'uso di applicazioni AJAX. Come ha chiaramente spiegato Cerreta nel brano citato, la lettura di una pagina in modalità virtuale segue l'ordine dei contenuti definito nel codice di marcatura.

Pertanto, quel collegamento ipertestuale che, nel Listato 14.1, ha il valore di tabindex più alto (10) e che, perciò, sarebbe letto per ultimo in una navigazione basata sull'ordine di tabulazione applicato dal browser, verrebbe letto invece per primo da uno screen reader impostato in modalità virtuale, qualora l'utente stia navigando la pagina tramite i soli tasti freccia, senza quindi utilizzare il tasto TAB. Ciò può creare un naturale disorientamento in un utente di screen reader. È normale, infatti, per un non vedente costruirsi una rappresentazione mentale dell'ordine dei contenuti, basato sulla sequenza di informazioni lette dallo screen reader. Nel momento, però, in cui l'utente passa dalla modalità maschere, in cui vale l'ordine di tabulazione definito mediante tabindex, alla modalità virtuale, in cui vale la sequenza dei contenuti definita nel codice di marcatura, la mappa mentale del documento va a farsi benedire, perché non c'è più corrispondenza nella posizione degli elementi: si tratta, a tutti gli effetti, di due ordini differenti.

NOTA BENE. Nel capoverso precedente, il brano qualora l'utente stia navigando la pagina tramite i soli tasti freccia, senza quindi utilizzare il tasto TAB è un'aggiunta suggerita da Leo Maria Cerreta dopo la pubblicazione del libro, per chiarire un possibile equivoco: non si noterebbe, infatti, differenza nell'ordine di tabulazione, se si continuasse a usare il tasto TAB anche in modalità virtuale (come è probabile che farebbe uno sviluppatore che usasse JAWS occasionalmente, magari solo per sperimentare la validità di quanto affermato nel testo).

Ecco, allora, che tabindex rischia di diventare una soluzione problematica per l'accessibilità: la raccomandazione del punto di controllo 9.4 delle WCAG 1.0 deve essere attentamente riconsiderata, alla luce degli sviluppi della tecnologia. Cosa fare, allora? Rinunciare definitivamente all'uso di tabindex? Ci limitiamo a riportare di seguito la soluzione proposta da Cerreta, lasciando al lettore la valutazione dei pro e dei contro.

Se in una pagina vi sono elementi che dovrebbero avere un ordine di tabulazione differente, è opportuno modificare tale ordine agendo direttamente sulla disposizione del codice HTML anziché ricorrere al tabindex. L'attributo tabindex è secondo me soltanto un fattore di correzione, da applicarsi a pagine progettate male, la cui linearizzazione non produce un ordine logico di tabulazione. In tali pagine, qualora lo sviluppatore non abbia per varie ragioni la possibilità di riordinare il codice HTML, si ricorre all'elemento tabindex come ripiego al problema.

Inizio pagina

Punto di controllo 9.5, priorità 3

I tasti di accesso rapido (accesskey)

Lo strumento che HTML e XHTML forniscono per creare comandi attivabili da tastiera è l'attributo accesskey, che può essere associato agli elementi A, AREA, BUTTON, INPUT, LABEL, LEGEND e TEXTAREA. Un tale strumento è utile soprattutto per gli utenti che non sono in grado di usare il mouse, ma usano bene la tastiera, come i non vedenti. Leggiamo dalle specifiche HTML 4.01 la definizione e il funzionamento di accesskey :

Questo attributo assegna un tasto di accesso a un elemento. Un tasto di accesso è un singolo carattere, tratto dall'insieme dei caratteri del documento. Nota: nello specificare un tasto di accesso, gli autori dovrebbero considerare il metodo di input dei potenziali lettori.

La pressione di un tasto di accesso assegnato a un elemento dà il focus a quell'elemento. L'azione che si verifica quando un elemento riceve il focus dipende dall'elemento. Per esempio, quando un utente attiva un collegamento definito dall'elemento A, il programma utente segue generalmente il collegamento. Quando l'utente attiva un pulsante d'opzione (radio button), il programma utente ne cambia il valore. Quando l'utente attiva un campo di testo, viene consentito l'input ecc.

Il documento di Tecniche HTML per le WCAG 1.0 fornisce un esempio di applicazione di accesskey a un elemento LABEL associato a un campo di immissione testo. In una pagina contenente il seguente codice, la pressione del tasto "u" consente all'utente di attivare il campo testo in modo da poterci scrivere dentro direttamente:

Il modo di implementare scorciatoie da tastiera con accesskey ha generato nel corso degli anni numerose discussioni tra gli sviluppatori interessati all'accessibilità. Esistono infatti delle variabili per le quali non sono state ancora definite, né tanto meno attuate, soluzioni standardizzate: quali pagine e quali funzioni di un sito web dovrebbero essere rese raggiungibili mediante scorciatoie da tastiera? Qual è il numero massimo di scorciatoie da tastiera che ha senso definire in un documento? Quali tasti andrebbero usati e quali evitati? Quali meccanismi usano i programmi utente per attivare le scorciatoie definite nel codice? Si dovrebbe avvertire l'utente, e come, della presenza di tasti di accesso rapido in un documento?

La presenza di tante variabili non standardizzate rende l'uso delle scorciatoie da tastiera non così semplice e comodo come potrebbe essere: nella migliore delle ipotesi, ogni sito contenente tasti di accesso rappresenta per l'utente un mondo a sé stante, che richiede di essere appreso nella sua particolarità, senza potersi giovare di esperienze precedenti e senza che la nuova conoscenza possa essere estesa ad altri siti.

Uno strumento non standardizzato

Proviamo allora a cercare qualche risposta alle domande poste più sopra, cominciando dalla prima: è possibile definire un elenco-tipo di pagine da associare a tasti di accesso rapido e tentare di farne uno standard? Le WCAG 1.0 non dicono nulla in proposito. Ci pensò il Governo inglese qualche anno fa a promuovere uno standard di fatto, pubblicando la seguente lista di associazioni tra accesskey e pagine ricorrenti, da usarsi nei siti governativi britannici (tratta dal sito Cabinetoffice ):

• S - Skip navigation [salta menu di navigazione]
• 1 - Home page
• 2 - What's new [novità]
• 3 - Site map [mappa del sito]
• 4 - Search [ricerca]
• 5 - Frequently Asked Questions (FAQ) [domande frequenti]
• 6 - Help [aiuto]
• 7 - Complaints procedure [procedura per i reclami]
• 8 - Terms and conditions [termini e condizioni]
• 9 - Feedback form [modulo per i riscontri degli utenti]
• 0 - Access key details [dettagli sui tasti di accesso]

La lista è un ragionevole tentativo di regolamentare la variabilità delle associazioni tra tasti e funzioni, ma non si può dire che a tutt'oggi sia diventata uno standard, neppure de facto, perché persino tra i siti governativi inglesi solo alcuni rispettano tale convenzione. Ma anche se la lista fosse stata largamente adottata, non avrebbe risolto i casi particolari, che ogni sito, o addirittura ogni documento, può presentare: non elimina e non avrebbe eliminato, perciò, la necessità da parte degli sviluppatori di rendere noto l'elenco dei tasti di accesso usati in un qualsiasi documento; né avrebbe diminuito il carico cognitivo che imparare le associazioni extra richiede agli utenti, a meno di non proibire di usare gli accesskey per qualsiasi altra funzione non compresa nell'elenco.

L'accenno al carico cognitivo ci conduce alla seconda domanda: qual è il numero massimo di scorciatoie da tastiera che ha senso definire in un documento? Dal punto di vista teorico, considerando un rapporto di 1 a 1 tra tasti e scorciatoie, il numero massimo di scorciatoie utilizzabili corrisponde all'incirca al numero di tasti alfanumerici disponibili sulla tastiera. Ma, senza voler considerare il problema dei conflitti di assegnazione dei tasti (ne riparleremo più avanti), può avere un'utilità pratica dichiarare una quarantina o più di associazioni tra tasti e link o campi modulo? Chi può ricordare tante associazioni, soprattutto considerando la variabilità tra sito e sito, se non tra documento e documento? Non è più semplice cercare direttamente i contenuti nella pagina o nel sito piuttosto che andare a spulciare un elenco di trenta o quaranta accesskey? Al momento non esistono risposte certe, scientifiche. C'è chi sostiene che non si dovrebbe andare oltre il limite di saturazione della memoria a breve termine di un essere umano (sei o sette elementi). Gli estensori delle linee guida per i siti del governo britannico hanno ritenuto che undici fosse il numero giusto.

Conflitti di assegnazione dei tasti e possibili soluzioni

La terza domanda è: quali tasti andrebbero usati e quali evitati? È una domanda strettamente correlata alla successiva: quali meccanismi usano i programmi utente per attivare le scorciatoie presenti nel codice di marcatura? Il problema è che è preferibile evitare conflitti di assegnazione dei tasti: definire per mezzo di accesskey una serie di tasti di accesso rapido ai contenuti dovrebbe tenere conto delle scorciatoie da tastiera già assegnate da browser e tecnologie assistive ad altre funzioni, se si vuole evitare che uno stesso tasto finisca per essere assegnato a due usi differenti, uno a livello di applicazione e uno a livello di contenuto web.

Uno studio pubblicato sul sito canadese WATS.ca , risalente al 2002 e aggiornato nel 2005, trovò che, limitatamente alla piattaforma Windows, erano rimasti tre soli tasti - barra ("/"), controbarra ("\") e parentesi quadra destra ("]") – che browser e tecnologie assistive non usassero già, in combinazione con il tasto Alt, per qualche funzione a livello di applicazione: erano dunque i soli tasti a essere veramente liberi per l'uso con l'attributo accesskey (nei sistemi operativi Microsoft, i tasti di accesso vengono attivati in genere premendoli in combinazione con Alt, mentre su Apple Macintosh in combinazione con Ctrl). Lo studio non considerava, tra l'altro, che i tasti riservati a livello di applicazione possono variare a seconda della lingua, il che rende ancora più complessa la questione.

La messa in evidenza di simili conflitti ha portato conseguenze dirette nella pratica dello sviluppo accessibile: per esempio, i siti governativi canadesi hanno deciso di non utilizzare più il meccanismo degli accesskey , come è spiegato sul sito che definisce le loro linee guida.

In realtà, a ben guardare, il conflitto tra scorciatoie di applicazione e tasti di accesso è meno grave di quel che emerge dallo studio di WATS.ca, se consideriamo una particolarità dei sistemi operativi Microsoft, che sono di gran lunga i più diffusi: premendo il tasto Alt da solo, si ottiene l'attivazione della barra dei menu dell'applicazione attiva; successivamente, dopo aver rilasciato Alt, si può premere la lettera che apre un determinato menu (F per "File", M per "Modifica" ecc.). Se invece si premono Alt e il tasto di accesso insieme, si ottiene l'esecuzione della funzione a cui è associato l'attributo accesskey nella pagina web correntemente aperta. Ciò significa che, limitatamente ai browser che attivano i tasti di accesso per mezzo di combinazioni con Alt, il conflitto con le scorciatoie di applicazione può essere evitato, anche se a prezzo di un ulteriore carico cognitivo per l'utente, che deve imparare a usare le combinazioni di tasti in modo diverso, a seconda che intenda aprire un menu del browser o attivare un tasto di accesso rapido (ciò non tiene conto, però, di eventuali conflitti di assegnazione di tasti con le tecnologie assistive collegate al browser).

Nei sistemi Mac OS X, invece, il focus può essere passato alla barra dei menu del browser qualsiasi siano i tasti di accesso rapido definiti in una pagina web, premendo la combinazione Ctrl + F2 (purché sia stato precedentemente attivato l'accesso universale da tastiera nelle proprietà di sistema). Una volta passato il focus alla barra dei menu, tutte le voci sono selezionabili da tastiera, così come nei sistemi Microsoft, spostandosi tra i menu con le frecce direzionali.

La scelta di Opera

Alla luce delle considerazioni del paragrafo precedente sui potenziali conflitti di assegnazione dei tasti, appare sensata la scelta fatta dai produttori del browser Opera, che hanno implementato, nelle ultime versioni del programma, un meccanismo che permette di selezionare gli eventuali tasti di accesso definiti in un documento, ricorrendo all'insolita combinazione Shift + Esc, che funge da interruttore. Premendo insieme questi due tasti, compare in sovrimpressione sul documento correntemente aperto una finestra (Figura 14.2) contenente l'elenco delle associazioni tra tasti di accesso e funzioni; l'utente, a questo punto, non ha che da premere il tasto assegnato alla funzione che gli interessa attivare.

La soluzione adottata da Opera dimostra che è possibile risolvere il problema della diversità di metodi di attivazione degli accesskey, che attualmente variano a seconda del browser e del sistema operativo. Con Opera 9, infatti, la combinazione Shift + Esc è multipiattaforma, e rappresenta perciò un passo in avanti sulla via della standardizzazione. Inoltre, l'uso di un'unica combinazione di tasti, adoperata come interruttore del meccanismo degli accesskey, riduce grandemente il rischio di conflitti con i tasti riservati a livello di applicazione dalle tecnologie assistive.

Come segnalare la presenza di tasti di accesso

Veniamo, infine, all'ultima domanda: l'utente dovrebbe essere avvertito, e come, della presenza di tasti di accesso rapido in un documento? Sì, dovrebbe essere avvertito, soprattutto considerando che non esiste attualmente un criterio standard di definizione dei tasti di accesso, tale da poter essere memorizzato e applicato dagli utenti abituali di siti accessibili.

I metodi finora utilizzati sono i più vari: si va dal mettere l'indicazione del tasto usato come accesskey dopo il link, all'uso del grassetto o del sottolineato per evidenziare all'interno di una parola la lettera usata come scorciatoia, per finire con una pagina esterna che mostra l'elenco dei tasti di accesso e fornisce le istruzioni per il loro uso.

Di tutte le soluzioni, quella di dedicare una pagina del sito all'elenco dei tasti di accesso e alle spiegazioni per utilizzarli è sicuramente la migliore. Invece, riguardo ai tre esempi riportati nel Listato 14.3, nessuno è realmente soddisfacente. Per gli utenti di screen reader, l'indicazione esplicita della lettera usata come scorciatoia, messa dopo un link (esempio A) o dopo un'etichetta di modulo, è da un lato inutile, perché segue un elemento che è stato evidentemente già trovato, dall'altro ridondante, perché ripete un'indicazione che gli screen reader già forniscono in modo automatico. L'uso del grassetto e/o del sottolineato (esempi B e C) è, dal canto suo, poco accessibile per gli ipovedenti, perché si tratta di modifiche in generale poco visibili, se applicate a una sola lettera all'interno di una parola.

Ancor più della pubblicazione di una pagina dedicata agli accesskey, sarebbe utile se fossero i browser a farsi carico di mostrare direttamente all'utente i tasti di accesso definiti dagli autori. È ciò che fa Opera, che si dimostra così, ancora una volta, all'avanguardia. Purtroppo, almeno per ora, è l'unico browser ad aver implementato un simile meccanismo.

Inizio pagina

Nonostante tutto, gli accesskey sono utilissimi

Giunti a questo punto, immaginiamo che un grosso punto interrogativo si sia formato sulla testa del lettore, che si starà chiedendo: insomma, è utile oppure no per l'accessibilità impostare delle scorciatoie da tastiera mediante l'attributo accesskey?

Consideriamo i seguenti fattori:

• la mancanza di uno standard di riferimento per quanto riguarda sia gli elementi da marcare con accesskey sia il loro numero;
• la mancanza di uno standard di riferimento per la presentazione all'utente dell'elenco dei tasti di accesso rapido usati in un documento o in un sito web;
• le differenze di comportamento dei programmi utente nell'attivazione dei tasti di accesso;
• la possibilità che il tasto scelto dallo sviluppatore non sia presente sulla tastiera dell'utente;
• la possibilità che il tasto scelto come accesskey sia già assegnato a una differente funzione a livello di browser, di tecnologia assistiva, di sistema operativo.

I possibili inconvenienti sono numerosi e sembrerebbero consigliare una rinuncia, almeno per il momento, all'uso di uno strumento di accessibilità che si presenta problematico e non sufficientemente standardizzato.

Tuttavia, merita di essere sentita in proposito l'opinione di chi i tasti di accesso rapido li utilizza davvero, quotidianamente, come facilitatori essenziali della navigazione in un sito web e non come argomento di pura disquisizione teorica. Riportiamo perciò di seguito un'altra comunicazione personale inviataci via e-mail dal "solito" Leo Maria Cerreta, sviluppatore non vedente del quale avevamo citato, nel commento al punto di controllo 9.4, le considerazioni relative all'uso di tabindex. Stavolta Cerreta si profonde in una vibrata e appassionata difesa dell'uso dei tasti di accesso rapido. Gli sviluppatori interessati all'accessibilità ne traggano le conclusioni che preferiscono.

Posizioni drastiche, come quella di non utilizzare più accesskey fino a quando non ci sarà una politica di assegnazione chiara e condivisa, non sono accettabili, visto che, specialmente per le web mail o altre web application, gli accesskey sono utilissimi e senza di essi l'utilizzo di tali applicazioni sarebbe talmente pesante e lento per l'utente, che ciò rischierebbe di tradursi in un'impossibilità d'uso.

[...] Siamo d'accordo che è più complicato ricordarsi tante combinazioni di tasti rispetto a chi con il mouse e due o tre tasti fa tutto, ma la vita da disabile è complessa ovunque, anche col PC; soltanto che la gente che disabile non è e si occupa di accessibilità, scambia tali difficoltà per inaccessibilità, ma sono cose ben diverse. Il fatto è che, se sapeste quali sono le inaccessibilità vere con le quali ci misuriamo ogni giorno, cambiereste le vostre prospettive nel valutare ciò che è inaccessibile e ciò che è accessibile ma con qualche sacrificio in più. Poi, se si vuol lavorare per trovare strategie ancora migliori per alleviare ulteriormente la scomodità di utilizzare tanti accesskey, va benissimo: fatelo, facciamolo, ma, in attesa di trovare un sistema migliore, utilizziamo ciò che c'è.

[...] Un sistema che non consente di sfogliare i menu da tastiera, impone che siano ricordate a memoria dall'utente cieco tutte le shortcut, altrimenti non potrà accedere ad alcun menu. Infatti, chi vede può guardare quale sia la lettera sottolineata, ma chi è cieco, per sapere quale sia la scorciatoia di un elemento, lo deve prima focalizzare e solo allora lo screen reader gli dirà quale è la relativa scorciatoia da tastiera. Motivo per il quale le shortcut, per i ciechi, sono da intendersi solo come un modo per velocizzare la navigazione, ma non come metodo esclusivo di accesso, poiché altrimenti, se non ci si ricorda più una scorciatoia o ci si trova in una nuova applicazione, si rimarrebbe tagliati fuori. Ecco perché, nonostante l'eventuale sovrascrittura di una scorciatoia, si può comunque avere il controllo della funzionalità sovrascritta.

Come sistema alternativo di accesso a una shortcut sovrascritta, esistono ben due strade: la prima è quella di focalizzare la finestra che incorpora tali controlli, in modo che siano passate le shortcut direttamente a essa (per esempio: premere Alt per raggiungere la barra dei menu e poi digitare la scorciatoia di interesse); la seconda, invece, è quella di raggiungere il controllo non ricorrendo più al suo tasto d'accesso, ma utilizzando la navigazione per controlli fatta usando le combinazioni Alt, Ctrl + Tab, Tab, Shift + Tab, le frecce direzionali ecc. Questo secondo metodo è meno rapido rispetto al primo, ma è anche quello utilizzato quando non si conosce o non si ricorda il tasto d'accesso assegnato all'elemento che si desidera attivare.

Tutto ciò mette al sicuro da qualsiasi problema di sovrascrittura dovuto all'uso di accesskey, ma, se ancora ci dovessero essere problemi, entra in funzione lo screen reader, che, tramite apposite macro, forzerà il focus, spostandolo al controllo che si desidera.

Possibilità future

Le specifiche XHTML 2 , allo studio da anni, prevedono di sostituire l'attuale attributo accesskey con un elemento ACCESS, così definito:

L'elemento ACCESS crea un vincolo di accessibilità con elementi all'interno di un documento. Applicare la scorciatoia fa guadagnare il focus all'elemento.

A parte una serie di attributi comuni, quest'elemento prevede tre attributi specifici: key, targetid e targetrole. Mentre key consente di replicare le stesse funzioni dell'attuale attributo accesskey, cioè di associare a un elemento un tasto di accesso scelto dall'autore, targetrole porta un'innovazione: definisce il ruolo strutturale, nel contesto del documento, dell'elemento a cui la pressione del tasto di accesso consegnerà il focus (l'attributo targetrole rimanda al valore dell'attributo role dell'elemento collegato. Tra i valori possibili di role vi sono, per esempio, main, navigation, search, note: cioè "contenuto principale", "menu di navigazione", "ricerca", "nota").

Proponiamo un esempio di codice di marcatura per l'elemento ACCESS, tratto dall'attuale bozza di lavoro delle specifiche XHTML 2.

Non si può fare a meno di notare che la ridefinizione di accesskey in ACCESS proposta da XHTML 2 non risolve affatto i potenziali conflitti di assegnazione di tasti, che rappresentano il principale ostacolo alla standardizzazione del meccanismo. In proposito, esiste un interessante articolo di John Foliot di WATS.ca, che mette acutamente a nudo il problema. L'articolo riprende obiezioni già inoltrate da Foliot ai responsabili che lavorano alle specifiche XHTML 2, e si intitola significativamente Access + Key Still Equals Accesskey : cioè, l'elemento ACCESS più l'attributo key equivalgono ancora ad accesskey.

La posizione di Foliot è riassunta chiaramente dal principio che egli enuncia nell'articolo: Dichiarate l'intento (l'attributo role) e lasciate l'assegnazione del vincolo all'utente finale. Sottoscriviamo la posizione espressa da John Foliot. L'uso dell'elemento ACCESS di XHTML 2 sarà veramente funzionale agli scopi dell'accessibilità, quando gli autori potranno limitarsi a dichiarare l'intento (per esempio: raggiungere il contenuto principale di un documento), lasciando all'applicazione e all'utente la scelta del meccanismo per forzare l'esecuzione del compito.

Un browser "intelligente" dovrebbe essere in grado di mappare automaticamente gli intenti dell'autore, espressi tramite ACCESS, e di presentare all'utente una lista di opzioni corrispondenti a quegli intenti, tali da non entrare in conflitto con le scorciatoie già in uso a livello di applicazione, e lasciando all'utente la possibilità di ridefinire le assegnazioni automatiche di comandi, così da adattarle alle proprie esigenze/preferenze.

Inizio pagina