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.

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.

Gli standard web sono inutili (da soli)

Il numero di manuali e siti che si propongono di diffondere l’uso degli standard web sta aumentando di giorno in giorno. La cosa è certamente positiva, visto che qualcuno (il W3c) si è preoccupato di definire gli standard e si presuppone che qualcuno (voi) li impieghi nei propri progetti.

Se analizziamo con attenzione questi manuali e questi siti è però facile notare come le soluzioni proposte, nonché la definizione stessa di standard, non siano in realtà quelli intesi dallo stesso consorzio che li ha proposti. Molto spesso la visione presentata è molto limitata e nasce dal presupposto, quasi sempre errato, che il sito web rappresenti l’intero mondo dei contenuti e dei processi. La soluzione proposta è molte volte la stessa, ripetuta fino alla noia: Xhtml per il contenuto, i fogli di stile per il posizionamento.

Spesso e volentieri le pagine web che navighiamo sono invece il risultato di operazioni e trasformazioni precedenti, la foce di un fiume la cui sorgente si trova molto più a monte. Questo non solo influenza la produzione dei contenuti, ma anche il modo con cui adottare gli standard. Utilizzare esclusivamente gli standard per il web, senza considerare il contesto in cui si lavora è sbagliato, così come sarebbe sbagliato costruire una casa preoccupandosi solo del materiale da impiegare, senza analizzare le caratteristiche del terreno, del clima e del territorio.

C’è sito e sito

Questo articolo si rivolge a chi realizza progetti di media/alta complessità, ovvero siti i cui contenuti provengono da un sistema di gestione o Cms (per quanto semplice possa essere), e il cui aggiornamento sia periodico e composto da un buon numero di pagine. Con questo escludiamo siti di presentazione, siti aggiornati una tantum e siti completamente statici. Quindi, se l’unico progetto nel quale siete coinvolti è il vostro sito o vetrina personale, non occorre che continuiate a leggere oltre: potete infatti permettervi di adottare o escludere tutti gli standard che volete. Siete gli unici giudici del vostro lavoro e come tali potete concedervi il lusso di sperimentare in continuazione nuove soluzioni.

Cosa sono gli standard

Per capire cos’è uno standard, ci possiamo per prima cosa rifare alla definizione del dizionario Devoto Oli, dove tra l’altro si legge:

“Tipo, modello, norma, cui viene uniformata una data produzione o attività”

e anche

“Complesso di elementi che individuano le caratteristiche di una determinata prestazione o processo tecnico”.

Lo standard è un insieme di regole e metodologie da applicare per mantenere i processi di produzione conformi nel tempo. Ma perché farlo? Perché dotarsi di uno standard?

Le ragioni principali sono:

  • aumentare l’efficienza e la capacità produttiva
  • ridurre i costi di produzione
  • aumentare la qualità del prodotto finale

Cosa sono gli standard web

Gli standard web sono di conseguenza un insieme di metodologie e regole applicate alla realtà web allo scopo di ridurre i costi di produzione del sito, velocizzare il processo creativo e al tempo stesso ottenere un prodotto di alta qualità e facilmente modificabile.

L’organo che si è preoccupato di tutto questo nel mondo internet è stato il W3c. In questi anni il lavoro del W3c è stato enorme: definire e aggiornare un insieme di standard per internet (anche se il termine è in verità improprio, in quanto il W3c rilascia “Recommendations”), un mondo che ha vissuto momenti di continua crescita, e soprattutto visite non proprio disinteressate da parte delle software house.

La nascita di questi interessi ha ben presto portato il processo di standardizzazione a livelli e risultati che non sempre soddisfano chi poi deve applicare gli standard. Documenti troppo completi in parti inutili, ma deficitari nel loro cuore, e standard in continuo mutamento, con nuove versioni che rendono subito obsoleto il lavoro di mesi. Molti sviluppatori sono preoccupati quando sentono parlare di nuove versioni degli standard, hanno paura di dover rifare per l’ennesima volta un lavoro di conversione. Vedremo tra breve che in realtà non è così.

Se cercate le parole “web standard” con Google e passate un po’ di tempo a visitare i siti trovati, non avrete alcun dubbio che gli standard web siano importanti.

Leggendo con un po’ di attenzione, potreste pensare che un sito standard:

  • utilizzi i fogli di stile (Css) per definire il layout di pagina
  • impieghi Xhtml (invece di Html) come linguaggio per i documenti web
  • sia realizzato in modo tale da essere accessibile e usabile

Tutto questo è certamente vero, ma è sufficiente? Siamo cioè sicuri che non dobbiamo considerare altri fattori prima di preoccuparci della costruzione delle pagine, e che questi non influenzino le nostre decisioni per lo sviluppo di un sito? E quali standard conviene usare?

I paladini degli standard web

Attenzione a chi ponete queste domande. Se infatti avete realizzato o gestite un sito che non sfrutta completamente i fogli di stile (non solo per i colori , ma anche per il posizionamento) e magari non utilizza correttamente lo standard Html, allora è molto probabile che prima o poi qualcuno vi informi che il vostro sito è superato, obsoleto, in poche parole “sbagliato”. Questo qualcuno, con il tipico atteggiamento di chi si considera in una posizione privilegiata, non lesinerà consigli e suggerimenti volti all’adozione cieca e totale degli standard web con il fine, secondo lui, di migliorare il vostro sito in termini di usabilità, accessibilità e user experience. Come biglietto da visita, aspettatevi l’Url del suo sito, naturalmente valido, usabile, accessibile. Se ci fermiamo a capire chi è il nostro interlocutore, noteremmo che rientra in una o più di queste categorie:

  • ha appena scritto un libro che parla di standard web
  • si propone per una consulenza sull’adozione degli standard web
  • si offre di convertire il vostro sito (brutto, retrò, sbagliato), in uno migliore (bello, standard, accessibile)
  • ha partecipato alla stesura di uno standard web
  • ha un sito di poche pagine (e purtroppo solo quello), realizzato in modo conforme agli standard, e lo usa come pretesto per diffondere il verbo degli standard web

Non solo: con tutta probabilità questo signore poco ne capisce della complessità di un progetto web, poiché ha visione solo di una parte, il suo lavoro: creare pagine Html.
Come potete ben immaginare la sua opinione, per quanto del tutto rispettabile e in certi termini condivisibile, è superficiale. Non c’è nulla di male nel promuoversi al ruolo di esperto nel campo degli standard, ma la realtà con cui si confronta chi realizza siti web è più complessa di quello che normalmente si crede.

Gli standard web sono una buona cosa, ma la loro adozione deve essere attentamente valutata, così da capirne l’impatto e i benefici che possono introdurre. Non solo, ogni sito è un caso a parte: lo standard che ben si presta in un’occasione, potrebbe introdurre benefici ridicoli in un’altra, tanto da sconsigliarne l’uso.

È comodo tifare per chi vuole adottare gli standard web a tutti i costi, ma non stiamo guardando una partita di calcio, stiamo lavorando.

Capita spesso di incontrare siti in cui l’autore si diverte a convertire siti esistenti non standard in versioni Xhtml e Css, così da dimostrare ai più scettici che è possibile non solo ottenere lo stesso risultato con gli standard, ma addirittura migliorarlo. L’esercizio è molto utile ai fini didattici, ma è un esercizio. In realtà queste operazioni, che molte volte interessano solo la home page, sono del tutto fuorvianti.

Come vedremo tra poco, la pagina che vedete sul vostro browser è il risultato di un numero a volte elevato di processi e trasformazioni. Fermarsi ad analizzare solo l’ultimo passo, quello che interessa il browser, è indice di miopia. Alcuni dei siti che notiamo non essere standard non lo sono per ignoranza, ma per le difficoltà (inclusi tempi e costi) incontrate nel modificare parti del sito che si trovano ben più a monte rispetto alla pagina che riceve il browser. Non è solo un problema di Html.

Un mezzo, non un obiettivo

Gli standard web non sono un santo a cui votarsi, non si presta opera di fede incondizionata senza aspettarsi un ritorno pratico e immediato, che abbiamo definito essere una maggiore produttività unita a un livello qualitativo adeguato. Adottare i più disparati standard web solo per fregiarsene a piè di pagina rischia non solo di essere pacchiano, ma addirittura controproducente.

In dipendenza del tipo di sito da realizzare, infatti, alcuni standard sono più adatti di altri. Per questo motivo è anche inutile proporre sterili liste congratulandosi con i siti che hanno compiuto il grande passo, da sito a tabella con codice non standard a foglio di stile per il layout e codice standard compliant. Ogni sito è diverso, l’equazione “sito costruito secondo gli standard = sito migliore” non funziona, ma va analizzata caso per caso.

È inoltre fuori discussione che l’utilizzo gli standard web nella costruzione di un sito può aiutare a migliorarne l’accessibilità e l’usabilità. Ma si tratta di una condizione che non è né necessaria, né sufficiente. Posso infatti creare un sito completamente aderente agli standard, ma frustrante per chi lo utilizza e tutt’altro che accessibile, come posso realizzare un sito a tabelle realmente usabile e accessibile.

Se il vostro obiettivo è costruire un sito usabile o accessibile state quindi attenti: rischiate di gettarvi a capofitto nella codifica del sito quanto il vostro problema sta a monte. Non solo, tenete presente che come abbiamo avuto modo di dire in altra sede, l’accessibilità di un sito ha un ciclo di vita che comincia con l’analisi dei requisiti.

Quali standard usare

Abbiamo detto che gli standard non sono ricette preconfezionate da consumare sempre e ovunque. La scelta degli standard da adottare è invece il frutto di un’attenta analisi, e dipende da numerosi fattori:

  • Dipende dagli obiettivi
    • Quali sono gli obiettivi aziendali e quelli degli utenti? Esistono degli standard che possono aiutare ad incontrare queste aspettative?
    • Quali benefici possono portare questi standard nell’immediato?
    • Quali benefici possono portare questi standard nel medio/lungo periodo?
  • Dipende dai limiti
    • Il tempo (e quindi il costo) necessario per utilizzare lo standard
    • Le controindicazioni e i compromessi nell’adottare lo standard (funzionalità che si vengono a perdere o modificare)
    • Limiti della tecnologia
      • Sistemi automatici o semiautomatici (es. Cms) che non producono codice standard
      • Parti del sito che non sono in nostro controllo (es. Banner), e che quindi potrebbero non essere standard-compliant
    • Limiti del contenuto, come contenuti pregressi da convertire
  • Dipende dal tipo di sito
    • Sito web
    • Applicazione web

Tutt’altro che impiegare una scatola chiusa, quindi. Da questo elenco è facile capire come la decisione se e come adottare uno standard web non riguarda necessariamente (anzi, quasi mai) solo chi si occupa di realizzare il template delle pagine (Html e Css), ma coinvolge l’intero team di sviluppo. Ecco perché la bontà di un sito web riguardo l’aderenza agli standard non può mai essere valutata “a distanza”, se non in casi idilliaci.

Prendere e criticare un sito web senza conoscerne le complessità e peculiarità è senza dubbio comodo, ma non aiuta chi l’ha realizzato a migliorarlo. Il numero di fattori che influenzano la scelta può infatti essere di tale portata che quello che si vede “sullo schermo” non è sufficiente per esprimersi in una critica costruttiva.

Nell’ultimo punto della lista si parla di differenza tra sito web e applicazione web. Cosa vuol dire, o meglio, cosa intendiamo per sito e applicazione web?

Per lo scopo di questa discussione un sito web è un insieme di pagine realizzate da una persona o da un piccolissimo team di persone, ognuna con competenze che spaziano dalla realizzazioni di pagine Html alla programmazione (senza raggiungere livelli estrema). Il risultato è solitamente un sito di modeste dimensioni, con nessun aggancio ad altre realtà (Cms, applicazioni legacy, database, ecc.). In questa categoria, come dicevamo all’inizio, rientrano i siti vetrina.

Un’applicazione web è invece, alla stregua di un programma per computer, un prodotto di ingegneria. In questo caso la distinzione tra le competenze del team di sviluppo è più marcata (ma non netta, questo non lo deve mai essere). In questo caso, più che per pagine, si ragiona per template. Ogni template può produrre più pagine con lo stesso look & feel, ma dal contenuto anche profondamente diverso. Generalmente, ma non è una regola, un’applicazione web è composta da un sito dinamico (collegato ad un database) e ad un certo numero di moduli (community, ecommerce, ricerche) sviluppati come veri e propri prodotti software. In questo caso il browser che riceve la pagina è l’appendice di tutto il processo dell’applicativo. È un po’ come un iceberg: quello che spunta dall’acqua è quello che vede il browser: una piccolissima parte di quella che in realtà è tutta l’applicazione.

Va notato come non usiamo il termine sito “statico” in paragone a “dinamico”, in quanto l’enfasi non è sul risultato del lavoro (posso avere siti complessi e statici, e siti composti di due pagine dinamici), ma sulle competenze richieste per portarlo a compimento e soprattutto sulla complessità del progetto.

In che modo l’adozione degli standard viene influenzata dal tipo di progetto (applicazione o sito web) che intendiamo realizzare? In realtà, più complesso e spaziato è il progetto che andiamo a realizzare, più ampia è la rosa degli standard che possiamo impiegare. Non solo, all’aumentare della complessità del progetto, si riduce il peso che il browser ha all’interno di tutta l’applicazione.

Attenzione: questo non vuol dire che possiamo inviare al browser pagine non standard, senza preoccuparci della resa visiva, tutt’altro. Vuol però dire che la trasformazione e presentazione dei contenuti non deve per forza di cose avvenire sempre e comunque lato browser, ma può essere realizzata a monte ricorrendo ad altri standard, che hanno il pregio di essere completamente slegati dalla periferica di output, e generalmente più potenti.

Non credete a chi vi dice che le stesse operazioni possono essere compiute dal browser, che non ha senso caricare inutilmente i server per problemi di prestazioni: l’hardware non è quasi mai un problema. Probabilmente chi si rifiuta di sfruttare la potenza dei server semplicemente non lo sa fare.

Gli standard caso per caso

Può sembrare strano, ma anche l’efficacia di uno standard varia in relazione al contesto nel quale viene applicato. Vediamo in che modo con un paio di esempi.

Il sito vetrina di un’azienda di abbigliamento sportivo

Immaginate di essere coinvolti nello sviluppo di un sito vetrina, con alcune pagine di presentazione di un’azienda e un elenco prodotti rivolti al pubblico giovanile.

Una tra le possibili soluzioni è quella di impiegare Xhtml Strict per la codifica delle pagine e i Css per la costruzione dell’intero sito. La scelta è condivisibile. Benché esistano dei limiti alla soluzione, questi sono facilmente superabili, mentre i vantaggi sono evidenti:

  • separare lo strato di presentazione dal contenuto, così da consentire in futuro il recupero del contenuto senza dover intervenire manualmente
  • rendere più facile e immediata la modifica del layout (come spostare velocemente le barre di menù e la navigazione
  • possibilità di inviare lo stesso contenuto a dispositivi diversi (come personal computer,cellulari e palmari)
  • coerenza visiva delle diverse sezioni del sito
  • diminuire il peso della pagina

Il sito di una rivista online

Immaginate adesso di dover realizzare un sito per un’importante rivista, dove sono caricati giornalmente 20 articoli. Sono inoltre presenti una vetrina per abbonarsi e un’area di community precedentemente utilizzati per un’altra rivista del gruppo.

Non pretendiamo che da soli siate in grado di realizzare tutto il sito, quello che è interessante capire è che in questo caso la realizzazione delle pagine è solo una parte (per quanto importante) dell’intero processo.

Se cominciate subito a realizzare template Xhtml, fogli stile e menù di navigazione non siete sulla buona strada. In realtà quello che avete bisogno di capire è che cosa avete a disposizione per lavorare, cercando di capire:

  • da dove saranno prelevati i contenuti
  • in che formato sono
  • a quali piattaforme si rivolge il sito (computer, palmari, ecc.)
  • quali devono essere le funzionalità degli altri servizi

Anche per un sito statico avete bisogno di sapere queste cose, ma in questo secondo caso la produzione dei contenuti entra a pieno titolo nel processo di realizzazione del sito web, e dovete conoscere perfettamente il suo funzionamento.

Per questo secondo progetto potremmo decidere di comportarci in modo diverso rispetto al sito vetrina, e infatti codifichiamo il sito utilizzando Xhtml transitional per le pagine e i fogli di stile unicamente per i caratteri, i colori e i margini.

Potremmo pensare che abbiamo agito in modo non corretto: perché non usare i Css anche per il posizionamento, dopo tutti i vantaggi che abbiamo elencato e visto che la costruzione del sito parte da zero?

La scelta non è legata ai problemi di compatibilità dei fogli di stile: questi infatti sono normalmente visualizzati con molti limiti nei browser non recenti. In effetti, trattandosi di business, l’azienda che ha commissionato il sito vorrebbe mantenere il bacino di utenza il più ampio possibile. Però ripetiamo: questa non è la causa della nostra decisione.

Per capire il perché di questa scelta, analizziamo come avverrà il processo di pubblicazione del sito. I redattori utilizzano un sistema di gestione dei contenuti (Cms) che gli consente di redigere gli articoli da pubblicare, inserendo non solo il corpo, ma il titolo, sommario, occhiello, le foto, riferimenti ad articoli correlati, ecc. Gli articoli sono memorizzati in un database in un formato Xml.

Ecco che siamo giunti al cuore della questione: esiste uno standard non legato direttamente al sito e che viene utilizzato per memorizzare le informazioni da pubblicare. Questa informazione è a fondamentale per capire quali standard utilizzare per strutturare il sito.

D’accordo con il team di sviluppo software, la soluzione proposta è la seguente:

  • realizzare i template in formato Xhtml, suddividendo le pagine in diverse parti a seconda delle esigenze
  • i menù e le barre di navigazione saranno realizzati in parte autonomamente, in parte manualmente secondo necessità, e la redazione sarà in grado con pochi clic di spostarli da una parte all’altra dello schermo
  • trasformare i template Xhtml in documenti Xslt, che verranno usati per trasformare il dato Xml dell’articolo nella pagina da inviare

In questa nuova ottica, sono anche ridimensionati i vantaggi della soluzione adottata per il sito vetrina. Rivediamoli sotto questa nuova luce:

separazione lo strato di presentazione dal contenuto

Separare la presentazione dal contenuto rende più semplice la manutenzione della pagina. Ma il vero problema è: dove finisce il contenuto e dove comincia lo strato di presentazione? Nel caso più semplice, quello precedente, il contenuto era rappresentato dalla pagina Xhtml e la presentazione dal file Css. In questo secondo caso, però, la visuale è cambiata. Tutti i contenuti provengono da un sistema per la gestione dei contenuti (Cms).

La presentazione è ora data dal template, che verrà opportunamente riempito dai dati provenienti dal database. Vi ricordate il discorso che facevamo poco fa a proposito dell’iceberg? In questo secondo caso potremmo dire che per noi lo strato di presentazione è l’intero flusso diretto al browser, mentre il contenuto è quanto presente nel database. Nel database e nel formato Xml lo strato di presentazione è già totalmente separato dal contenuto, tanto che lo stesso articolo potrebbe finire non solo nel sito, ma anche sulle pagine cartacee della rivista.

personalizzazione del look & feel per l’utente

Con i Css è possibile aiutare l’utente a modificare velocemente la presentazione del sito. Nel primo caso questo si spinge fino al posizionamento, mentre nel sito della rivista esiste comunque la possibilità di modificare font, colori e margini. Questo non vuol però dire che i redattori non abbiano questa possibilità: per come sono stati strutturati i template, infatti, la personalizzazione avviene interamente utilizzando il sistema di pubblicazione, tanto che i componenti possono essere in qualunque posizione, possono essere comuni a tutto il sito, oppure solo ad una sezione, senza intervenire minimamente sul codice. E utilizzando delle trasformazioni Xsl, anche cambiare il layout è estremamente semplice.

possibilità di inviare lo stesso contenuto a dispositivi diversi

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.

coerenza delle diverse sezioni del sito

I Css sono lo strumento migliore per garantire una coerenza visiva all’interno del sito. Anche l’attenta creazione di un template a tabella può però produrre gli stessi risultati. Se la pagina è ben definita e studiata, ad esempio, è possibile suddividerla in più porzioni (include) indipendenti l’una dall’altra, tenute insieme da una semplice struttura a tabella. Il vantaggio di questa soluzione è duplice:

  • la modifica a un include si ripercuote su tutto il sito
  • il team di sviluppo può suddividersi le parti di lavoro (include di ricerca, menù, contenuto, ecc.)
diminuire il peso della pagina

Qui c’è poco da fare: se usate correttamente ed efficacemente i fogli di stile per il posizionamento degli elementi, il peso della pagina è sicuramente minore rispetto al corrispettivo in tabella. Usare i Css per il testo e il colore partecipa a rendere la pagina più leggere, ma il risultato non sarà comunque paragonabile. Attenzione però a non legare il peso della pagina con la velocità di visualizzazione nel dispositivo ricevente: i due elementi sono correlati, ma un sito ben realizzato può essere percepito come veloce anche se il peso della pagina è elevato.

A queste considerazioni va anche aggiunto che la gestione dei fogli di stile da parte degli odierni browser è deficitaria, tanto da richiedere accorgimenti e trucchi anche nei casi di template mediamente complessi. Questo non vuol dire che va scoraggiato l’uso dei fogli di stile per il posizionamento (anche perché le sorprese tra diversi browser non manca neppure nei layout a tabella), ma che nel caso di siti di alta complessità, la prima preoccupazione dev’essere quella di memorizzare correttamente l’informazione da produrre. Fatto questo, possiamo presentare questa informazione a chiunque intervenendo semplicemente nei fogli di trasformazione. Il che vuol anche dire che domani, quando uscirà la versione 8 delle specifiche per i Css o di Xhtml, saremmo pronti ad usarli con poco sforzo.

Quello che abbiamo visto è solo un esempio, che prende in esame i fogli di stile e lo standard Xhtml. In realtà la stessa situazione sarebbe replicabile in altri ambiti con le stesse conclusioni: prima di applicare uno standard è bene conoscere le realtà nel suo complesso.

Conclusione

Chi realizza pagine web non lavora in solitaria. Le soluzioni che propone, non solo dal punto di vista grafico, ma anche di standard adottati, dipendono dal contesto nel quale opera. Con due semplici esempi abbiamo visto come l’impiego degli standard web vada attentamente valutato in base al sistema di produzione dei contenuti, nonché dell’audience e delle aspettative degli utenti.