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à)

Web design estremo

I motivi per cui la navigazione di un visitatore può inciampare in qualche condizione imprevista sono molti: problemi al server, moduli non compilati correttamente (campi obbligatori mancanti, tipi di dato non previsti), link errati provenienti da motori di ricerca, ecc.

Chi sviluppa il sito deve rendersi conto che per quanta cura è stata posta nel design e nello sviluppo di un sito, prima o poi una di queste condizioni si verificherà.

I ragazzi di 37signals hanno scritto un manuale che presenta 40 linee guida da seguire nello sviluppo di un sito perché sia possibile prevedere e gestire correttamente alcuni punti di crisi, come ad esempio:

E’ importante aiutare l’utente che si trova in queste situazioni anomale perché possa efficacemente uscirne, senza ambiguità e con un linguaggio comprensibile, ma anche presentando le sole informazioni necessarie allo scopo.

L’approccio degli autori è fortunatamente molto pratico: viene brevemente presentata la linea guida e seguono immediatamente alcuni esempi negativi e positivi tratti da siti reali. Non aspettatevi però suggerimenti su come intervenire direttamente sul codice, perché non è una guida di Html o di sviluppo web.

Defensive Design for the Web – How to improve Error Messages, Help, Forms and Other Crisis Point * 37 Signals * New Riders * $24.99

Traduzione italiana:
Defensive Design per il web – Come migliorare messaggi di errore, help, form e altri punti critici di un sito * 37 Signals * Tecniche Nuove * euro 19.90

Il web arriva alla versione 2.0

Una ricerca di Web 2.0 su del.icio.us restituisce una serie di articoli e discussioni di quella che è una (non troppo nuova) visione del web.

Chi lavora pesantemente con il web sta infatti maturando una consapevolezza segnata da un lato dalla diffusione inarrestabile dei contenuti, dall’altro dalla solidità dei servizi che rendono disponibili interfacce per facilitarne l’integrazione da parte del mondo esterno. Questa consapevolezza è che il sito web tradizionale non è più il centro del web e, cosa ancora più importante, non più una scatola a tenuta stagna dei contenuti che ospita.

Diventerà sempre più importante (e per alcuni lo è già) favorire lo scambio di dati tra diverse realtà che siano in grado di trasformare, integrare, presentare e riproporre il contenuto (l’informazione e i dati) nei modi più diversi agli utenti più disparati.

Pensate ad esempio agli sforzi fatti da Amazon e Google per rendere disponibile una serie di interfacce applicative (API) così da facilitare il lavoro di quanti, utilizzando i loro servizi, vogliano costruire delle interfacce assolutamente personalizzate. Rss, Api, Xml, Soap, Web Services sono alcuni degli standard e delle architetture che già consentono di realizzare tutto questo e il cui successo è dovuto principalmente dall’incremento esponenziale dei dati da gestire e integrare e dall’impossibilità per un unico attore di farlo.

Questa nuova strada ha delle ripercussioni non solo sul lavoro di chi sviluppa l’architettura hardware e software di un sito, ma anche di chi si occupa della costruzione dell’interfaccia di presentazione.

Lo dice bene Richard MacManus in un suo articolo per Digital Web Magazine dello scorso Maggio:

In the early days, designers used tricks like aninated GIF’s and table hacks in cliever, interesting an horrible ways. In the last few years, CSS came into fashion to help separate style from structure.[…] Even so, the focus was still on visual design.[…] Designers need to become more like programmers.

Non possiamo che essere d’accordo con MacManus anche perché è da qualche anno che, attraverso questo sito, diciamo la stessa cosa. Lo abbiamo fatto in “Chi ha paura di Xhtml8?“, un articolo in risposta a chi (troppo legato all’aspetto visuale di un sito) si preoccupava dell’obsolescenza di un sito solo per la variazione delle specifiche Html:

Perché preferire Xhtml a Html? Tra tutti i pregi, sicuramente il fatto che un documento Xhtml è anche un particolare tipo di documento Xml.

E qual è il vantaggio di Xml? Perché preoccuparsi di questo standard a prima vista esoterico? Con Xml potete definire accuratamente i dati e la struttura delle informazioni della realtà in esame (un libro, un listino prodotti, ecc.). Non solo: avete la possibilità di trasformare agevolmente un documento Xml per ottenere risultati molto diversi (una pagina web, un file di testo, un documento Pdf, un altro documento Xml). Per farlo si utilizzano le trasformazioni Xsl (Xslt), un linguaggio decisamente potente che è possibile imparare e addomesticare in poco tempo.

Ma lo abbiamo fatto in modo ancora più marcato (suscitando anche qui qualche malumore da parte di chi si preoccupa solo dell’aspetto grafico di una pagina) in “Gli standard web sono inutili da soli“. Ecco cosa abbiamo detto a proposito di un sito complesso, con audience diversificato:

Certo è vero, con i Css è teoricamente possibile servire un maggior numero di dispositivi. Tutto bene fin che si tratta di browser, ma provate ad immaginarvi mentre leggete la pagina di un sito in un monitor grande come il display di un cellulare. Non basta presentare l’informazione in modi alternativi, ma essere in grado di trasformarla (anche ridurla). Nel nostro caso, al browser verrà inviato l’intero articolo, mentre al cellulare solo il titolo, il sommario e un abstract.

Nessun problema comunque: abbiamo infatti scelto di adottare lo standard Xsl e quindi, con semplicissime trasformazioni riusciamo a rendere disponibili diverse interfacce di fruizione. Non solo, mentre con i Css possiamo variare la presentazione, ma il contenuto rimane lo stesso (possiamo al limite cercare di nasconderlo), con opportune trasformazioni l’utente può decidere quali informazioni ricevere, e in che ordine. Riusciamo quindi non solo a presentare in modi diversi le informazioni con documenti Xslt diversi, ma anche a filtrarle in modo da presentare ad un palmare solo la versione essenziale, al posto di quella completa.

Insomma, l’aspetto visivo di un sito è certamente importante, e deve essere realizzato con la massima cura e aderenza agli standard, così da essere accessibile al maggior numero di dispositivi.

Ma in futuro la probabilità che per ottenere questo risultato sia sufficiente cambiare solo l’aspetto dell’informazione sarà sempre minore, perché sempre più spesso è necessario integrare diverse fonti e trasformare lo stesso dato. Cercare di risolvere tutti questi problemi focalizzandosi solo sulla costruzione di uno o più fogli di stile, come se questi rappresentassero la risposta a tutti i mali, è puramente utopistico.

Questo vuol dire che un browser di vecchia generazione, uno screen reader, un palmare o un browser potrebbero ricevere lo stesso contenuto base da siti diversi, ma trasformato e adattato secondo le esigenze, a dei costi irrisori. Il costo infatti non è certamente dato dalla costruzione di qualche foglio di stile o dalla definizione di regole di traformazione, ma dalla produzione dei dati e del contenuto. Per questo lo sforzo principale dev’essere quello di rendere semplice ed efficace la diffusione e il consumo dell’informazione.

Il nostro suggerimento (per la verità già espresso più volte) verso chi si occupa di design di siti e non l’ha già fatto, è quello di affrontare lo studio delle architetture di siti governate dai Cms e di cominciare a realizzare qualche semplice esempio di trasformazione con Xml e Xsl, così da rendersi conto delle potenzialità di queste soluzioni.