Ajax e l’usabilità

Ho recentemente avuto modo di esprimere qualche pensiero a proposito di Ajax e accessibilità web.

Mi però anche chiesto quali siano i vantaggi e gli eventuali problemi legati all’usabilità di questo tipo di applicazioni.

Il nocciolo della questione è che varia il modo con cui l’applicazione interagisce con l’utente. Invece di essere legati all’ormai consolidato procedimento per cui ad ogni azione dell’utente corrisponde una richiesta al server, che provoca la spedizione di un’intera pagina Html verso il browser, con Ajax è possibile aggiornare parti della pagina senza che sia necessario ricaricarla completamente.

I benefici l’hanno davanti agli occhi chi utilizza un’applicazione basata su questa architettura. Gmail non solo consente di ricercare agevolmente i contatti o di inserire allegati come se stessimo usando un applicativo desktop, ma da qualche tempo è presente un’utilissima funzione di salvataggio automatico.

A livello di usabilità sono sicuramente dei passi da gigante. Quando ho avuto modo di provare in anteprima la nuova versione di Yahoo! Mail sono rimasto stupefatto. Si tratta di un vero e proprio client di posta elettronica all’interno di un browser, con funzionalità di drag & drop (sia dal desktop, sia dalle cartelle della posta), menù contestuali, finestre multiple, ecc.

Mi rendo però conto che questo tipo di applicazioni altamente interattive, se mal pensate, possono d’altro canto ridurre sensibilmente l’usabilità. E chi sbaglia non è lo sviluppatore casuale, ma anche chi normalmente è attento a queste problematiche, come i ragazzi di Google.

Ho utilizzato il loro reader Rss negli sfortunati giorni appena successivi al rilascio, quando l’applicazione era di una lentezza esasperante. Per carità, può succedere, e questa non è sicuramente colpa di Ajax. Il problema è che per tutto il tempo che ho utilizzato il Reader non ero sicuro se la mia richiesta fosse stata ricevuta dal server di Google, e se questo stesse lavorando per esaurire la mia richiesta. Non ero addirittura sicuro di aver premuto il link giusto nel posto giusto.

Il motivo? Il fatto è che, nel bene o nel male, siamo tutti abituati al comportamento di un’applicazione web standard.

Premo un pulsante o un link, il logo in alto a destra del browser comincia a girare e la barra di stato in basso a sinistra indica cosa sta succedendo alla comunicazione tra browser e server. In poco tempo posso capire se ci sono problemi a contattare il server, se sta impiegando troppo tempo a rispondere, o se tutto si è risolto per il meglio.

Ma non con il lettore Rss di Google, costruito completamente con architettura Ajax, dove cambiano le convenzioni a cui siamo abituati. In questo caso la pagina non si ricarica completamente, ed è quindi necessario che sia lo sviluppatore ad avvisare esplicitamente che sta accadendo qualche cosa, che è stata inoltrata una richiesta al server. Altrimenti io utente vedo solo un browser che rimane fermo, senza sapere se ha ricevuto il mio click o no, se il problema è nel server o se è successo qualcos’altro.

Ajax dà quindi la possibilità di migliorare l’usabilità di una pagina, ma se non si pone la dovuta attenzione, è molto più facile peggiorarla. Su questo ci sarà molto da lavorare in futuro.

Ajax e l’accessibilità dei siti web

(Vedi anche Ajax e l’usabilità)

Di Ajax si parla ogni giorno e sono ormai decine i framework per sviluppare applicazioni basate su questo tipo di architettura.

Occupandomi da anni di sviluppo web non posso che esserne contento: finalmente i limiti di interfaccia di una pagina possono essere superati! Subito dopo mi sono però chiesto se sono tutte rose e fiori, se con Ajax ci sono solo risvolti positivi.

Pensiamo a un argomento delicato come quello dell’accessibilità web. Già è difficile riuscire a realizzare una semplice pagina Html accessibile, per non parlare di una pagina con immagini, video e audio. Cosa succede se cominciamo a impiegare massicciamente Javascript e Dhtml?

Ho pensato allora di farmi dare una mano da Nicola, visto che utilizza quotidianamente uno screen reader, sottoponendogli due esempi.

Il primo, più semplice, è Google Suggest. L’aspetto è quello della classica ricerca di Google, ma non appena si comincia a digitare qualcosa, appaiono dei suggerimenti pescati direttamente dal server. Ho espresso a Nicola il dubbio che il suo screen reader non fosse in grado di segnalargli la presenza di questi suggerimenti, dubbio che mi ha subito confermato.

Come era largamente prevedibile, Jaws non dà alcun riscontro della presenza di un’eventuale lista di suggerimenti nella pagina di ricerca di Google.

A questo punto sono passato all’opposto e ho scelto un sito che si basa interamente sull’architettura Ajax: il nuovo client web di Yahoo! Mail, in versione beta e utilizzabile quasi esclusivamente oltreoceano.

Graficamente e a livello di funzionalità si tratta di un prodotto stupefacente: sembra quasi impossibile utilizzare questo tipo di applicazione in un browser, tanto è simile a un vero client di posta. Ma, anche in questo caso, Nicola ha evidenziato dei seri problemi di accessibilità.

Per quanto riguarda la mail di Yahoo!, riesco a leggere la tabella contenente il sommario dei messaggi, ma nessuna voce viene vista da Jaws come un link. Mi pare di aver capito che, per leggere un messaggio, bisogna cliccare sull’oggetto. Questo con una manovra si può anche fare. Poi però rimane il problema di riuscire a leggere il messaggio. Mi sembra di aver capito che il testo del messaggio appare sotto alla tabella contenente l’elenco dei messaggi. Tuttavia Jaws legge solo il nome del mittente e quello del destinatario, poi per lui la pagina web finisce lì. Ancora una volta, ricorrendo all’emulazione del mouse, cioè al cosiddetto cursore Jaws, si riesce a raggiungere la zona sottostante e a cliccare. A questo punto si apre una nuova finestra, che Jaws legge normalmente. Conclusione: non accessibile.

Tutt’altro che un successo, quindi. In effetti quella di aver realizzato un vero client di posta dentro un browser è una mossa azzeccata a livello di immagine. Ma la soluzione migliore sarebbe stata probabilmente un’altra, come ad esempio costruire un’applet Java, sempre da presentare dentro un browser. Certo, un po’ pesante da scaricare la prima volta (comunque qualche tonnella di Javascript dovete pur digerirla con Ajax), ma se non altro, se ben sviluppata, completamente accessibile.

E non venitemi a dire che comunque Google può essere usato anche senza suggerimenti, e che la mail di Yahoo! può essere letta anche in semplice formato Html, perché è un problema che ho già affrontato a proposito delle versioni di sito accessibile. A parità di funzionalità anche in questo caso una versione alternativa accessibile può andare bene, l’importante è che chi la realizza non se ne dimentichi dopo qualche mese senza riportare i relativi aggiornamenti (argomento delicato, visto il perenne stato di beta di molti applicativi web).

(Vedi anche Ajax e l’usabilità)

Verificare l’accessibilità dei siti web con Firefox

Ho già avuto modo di presentare qualche utile plugin di Mozilla Firefox in aiuto agli sviluppatori web.

Vale però la pena segnalare un articolo di Patrick H. Lauke, Evaluating Web Sites for Accessibility with Firefox, perché speiga esaurientemente – linee guida alla mano, punto per punto – come si possa verificare l’accessibilità dei siti web utilizzando la Web Developer Toolbar.

Un bell’articolo con molte e significative schermate a corredo.

Lauke surrerisce anche di utilizzare un altro comodo strumento per Firefox, il Table Inspector di Gez Lemon, utile per visualizzare il contenuto “accessibile” di una tabella che normalmente non compare a video.

Leggere una pagina web con uno screen reader

Una delle difficoltà principali per chi si occupa di accessibilità è capire le difficoltà di chi utilizza un sito web. L’utilizzo di scenari, la definizione di gruppi di lettori tipici sono senza dubbio di aiuto, ma se non avete a disposizione qualche utente disabile disposto a darvi una mano con i test, la strada è in salita.

Nel nuovo libro di Steve Krug ho trovato il link a uno studio (per la verità non recente) che cerca di analizzare le problematiche di chi è cieco e utilizza uno screen reader per fruire le pagine.

Vale sicuramente la pena darci un’occhiata, soprattutto per capire le difficoltà di chi si deve confrontare con tre strumenti (il browser, lo screen reader, la pagina) per operare, ma anche per rendersi conto di quanto è semplice, a volte, apportare benifici significativi a una pagina (saltando ai contenuti, utilizzando corretti nomi per i link, ecc.).

Il ciclo di vita dell’accessibilità web (prima parte)

Presentiamo una versione rivista e ampliata dell’articolo “The Lifecycle of Web Accessibility” pubblicata dall’autore su evolt.org in inglese nel dicembre 2002

La costruzione di un sito web è un compito che richiede competenze molteplici e diversificate, ognuna con il proprio ciclo di vita. Lo sviluppo, come abbiamo avuto modo di imparare all’università, ha un ciclo di vita, e così l’usabilità, la progettazione e la creazione dell’informazione.

Discutendo di accessibilità web sembra però che questa disciplina entri in gioco solo quando realizziamo le pagine o scriviamo i contenuti, ma solo a prima vista è così. Quella dell’accessibilità è una vera a propria cultura che deve essere chiara fin da subito a chiunque lavori alla costruzione del sito web, pena risultati scadenti.

In questo articolo suddivideremo il ciclo di vita dell’accessibilità di un sito web in 5 fasi e vedremo come queste siano strettamente collegate ad altre discipline, come la progettazione grafica, lo sviluppo e la gestione dei contenuti.

Anche se la trattazione procede per punti è bene sottolineare che questo ciclo non va inteso come una sequenza lineare di passaggi. Ci soffermeremo inoltre ad analizzare le competenze professionali richieste piuttosto che il ruolo delle persone (perchè la stessa persona può aver maturato diverse competenze, soprattutto nel caso di progetti di piccola dimensione).

La prima fase, tema di questa parte, è l’analisi dei requisiti.

Strategia e analisi dei requisiti

Di cosa si tratta

L’analisi dei requisiti rappresenta il momento in cui sono ipotizzati e in seguito definiti gli utenti del sito, vengono espresse le motivazioni economiche ed evidenziati i limiti tecnologici nonché le aspettative dell’utente. Vi troverete a interagire con il cliente per capire qual è l’obiettivo del sito e per assegnare il giusto numero di risorse e di mezzi per costruirlo.

Solitamente, se state facendo un buon lavoro, ipotizzerete diversi scenari d’uso. Uno scenario è un’ipotetica rappresentazione di come una specifica (e immaginaria) persona interagirà con il sito, ed è composto da un profilo utente (chiamato per l’appunto persona), dal programma di una sua giornata tipo e dalle aspettative che ha nei confronti del sito, ma anche molto di più.

Come entra in gioco l’accessibilità web

Dovete definire i profili delle persone che useranno il vostro sito, cercando di essere il più dettagliati possible. Questo significa che dovete prendere in considerazione persone con diversi gradi di abilità, sia fisica, sia tecnologiaca. Potete trovare degli esempi eccellenti leggendo “Dive Into Accessibility” di Mark Pilgrim, una serie di lezioni composta da 4 scenari basata su persone disabili e scritte dall’autore per aiutare gli sviluppatori a realizzare weblog (ma anche siti) accessibili.

Che tipo di disabilità prendere in considerazione dipende dal pubblico del vostro sito, ma non dimenticate che in linea generale una persona disabile interagisce con qualunque tipologia di sito. Potreste pensare, ad esempio, che un cieco non userà mai un sito che vende libri, ma questo è lontano dall’essere vero. E se vuole regalare il libro ad un amico: potete permettervi di escluderlo dalla lista dei vostri clienti?

Non dimenticatevi poi che l’accessibilità significa anche accesso al contenuto da parte di piattaforme (browser, sistemi operativi) tra di loro molto diversi.

Gli scenari che andrete a creare possono influenzare diversi e importanti aspetti del vostro progetto.

Se state riprogettando un sito, ad esempio, dovete decidere se convertire o meno del contenuto scritto per la versione precedente (in quanto potrebbe essere scritto in formato totalmente o parzialmente inaccessibile), o di convertirlo in formato accessibile. Questo potrebbe avere un forte impatto sui costi: è fondamentale prendere la decisione in questa fase.

Se state valutando l’acquisto di un CMS, dovete inoltre verificare la sua aderenza agli standard web e la possibilità che questo crei contenuti accessibili. Un aiuto ve lo può dare CMS Matrix, un sito che presenta un elenco aggiornato di questo tipo di soluzioni.

Attenzione però: CMS accessibile non vuol dire che deve essere semplicemente in grado di aggiungere gli attributi alt alle immagini o produrre codice valido. Se il vostro obiettivo è quello di servire periferiche diverse (telefonini, PDA) quello di cui avete bisogno è uno strumento che permetta di inviare contenuti diversi (ad esempio completi per il web, parziali per dispositivi con monitor limitati) a dispositivi diversi.

Non dimenticate poi che il CMS può aiutarvi a creare un contenuto accessibile, ma non può farlo al vostro posto (su questo argomento ritorneremo più avanti).

Se non riuscite a trovare un prodotto che rispetti le vostre richieste, potreste addirittura voler decidere di costruirlo voi stessi o di commissionarne uno.

In questa fase si tratta infine di individuare i redattori e in generale le figure professionali che prepareranno il contenuto del sito e si preoccuperanno di aggiornarlo. Hanno specifiche competenze in fatto di accessibilità web o devono essere opportunamente formati? Non fate passare troppo tempo prima di svolgere queste verifiche, anche perché prima siete pronti con il caricamento dei contenuti, prima potete inziarlo. Non è quasi mai obbligatorio attendere lo sviluppo di tutto il sito per cominciare a popolarlo di contenuti.

Finisce qui la prima fase del ciclo di vita. Nella prossimo interventi analizzeremo la progettazione contettuale, ovvero la struttura e funzionalità del sito.