Web Design 2007: previsioni per il futuro

Il 2006 sta arrivando al termine, e come è giusto che sia iniziano ad uscire in rete alcune previsioni per il 2007 di web designers e sviluppatori.

Ho letto un interessante articolo a riguardo, che si sbilancia su 5 argomenti, dall’accessibilità all’utilizzo di AJAX nelle pagine web. Questa una sintesi, non necessariamente tradotta dall’originale:

1. AJAX e DHTML saranno usati con cautela

A quanto pare ci si sta rendendo conto che se si è capaci di fare una cosa, non è necessario integrarla per forza nei propri lavori. Nel 2007 dopo la grande crescita di pagine in AJAX, contenuti dinamici, e javascript in abbondanza, ci sarà probabilmente un passo indietro. Meglio ottimizzare le pagine ed evitare l’integrazione di script che pesano più del necessario.

2. Addio angoli arrotondati

Previsione abbastanza azzardata questa.. che vede l’abbandono dei famosi rounded corners per concentrarsi su altri elementi grafici: linee, texture e contrasto.

3. Accessibilità per tutti

Internet continua a crescere, ed in questo processo è evidente l’attenzione sempre maggiore verso gli standard web e l’accessibilità. Nel 2007 queste tematiche avranno ancora più importanza.

4. Diffusione di CSS2 e CSS3

Internet Explorer 7 inizierà a diffondersi, e questo aiuterà l’utilizzo nei CSS di regole e selettori fino ad oggi poco supportati. Non si arriverà probabilmente a sfruttare le potenzialità dei CSS3, ma IE6 resterà solo su una minoranza di computer.
Obbligatorio offrire un’esperienza migliore a tutti gli utenti che navigano con Firefox, Opera, Safari e IE7.

5. Nascita di nuovi talenti

Previsione abbastanza scontata: è facile immaginare la nascita di nuovi talenti nell’ambito del web design, degli standard web e della programmazione. Anche in questo campo, probabilmente arriveranno novità dall’Asia.

Queste sono le previsioni di Ted Drake, pubblicate sul suo blog. Interessanti, anche se quella sugli angoli arrotondati mi lascia abbastanza dubbioso.. sicuramente è un’opinione basata su gusti personali.

E voi quali idee avete sul 2007 che arriverà? Io ritengo molto verosimile la prima previsione: è ora di abbandonare librerie javascript che pesano anche più di 200kb!

L’accessibilità deve essere tutelata

WaSP - Web Standards ProjectLa frase del titolo è stata il mio primo pensiero dopo aver letto l’articolo di Jeff Croft: “Has accessibility been taken too far?”.

L’articolo in questione risale a qualche settimana fa, ed è un’aspra critica all’accessibilità del web, che ha scatenato una vera e propria diatriba sul suo omonimo blog. A questo intervento ne è seguito un secondo dove sono state fatte alcune precisazioni e correzioni, e potete trovarlo qui.

Riassumendo i tratti salienti dell’articolo, l’autore pur dichiarando la legittimità degli standard web e l’importanza delle linee guida per l’accessibilità, sostiene che spesso non valga la pena lavorare per rendere un sito veramente accessibile a tutti, soprattutto per i costi di un processo del genere. Oltre a questo, porta l’esempio della carta stampata dove sono numerosi i casi di testi illeggibili, troppo piccoli o dal contrasto insufficiente, per far capire come non sempre sia necessario preoccuparsi di certe tematiche.

Cercherò di replicare in maniera concisa, pur avendo molto da dire a riguardo, perchè un argomento simile è di fondamentale importanza per quello che sarà internet nel prossimo futuro e oltre.

Il web non è un giornale

Questo concetto è fin troppo semplice da capire, ma a quanto pare non tutti sono d’accordo. Jeff Croft ha portato l’esempio della carta stampata per trovare una semplice metafora a sostegno della sua teoria, ma è impensabile paragonare internet e le pagine web al mondo cartaceo.

Non è solo una questione di costi

E’ impossibile limitare l’accessibilità ad una questione di costi, è proprio per questo che in molti paesi sono state fatte leggi a riguardo per obbligare la realizzazione di siti accessibili. In Italia ne è un chiaro esempio la legge Stanca per i siti delle pubbliche amministrazioni. Un buon designer dovrebbe tenere conto delle linee guida, così come un buon architetto deve eliminare le barriere architettoniche dai suoi progetti.

Non è l’utente a doversi adattare

Al contrario di quello che molti possono pensare, sono i web designer che devono adattarsi alle esigenze degli utenti, e non viceversa, ovviamente nei limiti del possibile. E’ impensabile obbligare un utente a doversi scaricare un altro browser, o a cambiare sistema operativo, o installare un particolare software come un ingranditore di schermo.
Può esserci un consiglio o un suggerimento su come sfruttare al meglio lo strumento posseduto (che sia il PC o lo stesso browser) ma non un obbligo, perchè una scelta del genere significa perdere definitivamente un utente e spesso provocare il disappunto di chi comunque frequenta il sito e non ha problemi di accessibilità.

I punti elencati fin qui portano ad un’ulteriore riflessione. Il web designer, in tutte le sue molteplici varianti, è un professionista così come può esserlo un medico. Se un chirurgo perdesse sul tavolo della sala operatoria anche solo l’1% dei suoi pazienti, non potrebbe far finta di niente o dire che è una minoranza di casi.

Ognuno è libero di scegliere la propria strada, ma in questo momento se si sceglie di sviluppare sul web è necessario considerare il rispetto di determinati requisiti, soprattutto se si desidera dare un futuro alla propria professione. Puntare il dito contro degli ipotetici zeloti dell’accessibilità non serve a nessuno, ed è un bene che esistano gruppi come il WaSP che la pensino così.

TomStardust.com premiato da Accessites!

Quality Universal Design award

Sono fiero di annunciare che questo sito è stato recensito e premiato da accessites.org, portale che si occupa di accessibilità, con articoli e showcase di siti che seguono gli standard web.

E’ proprio in questo showcase che è stato appena inserito TomStardust.com, con un bel Quality Universal Design award.

Mettendo da parte l’autocelebrazione, mi è stato utilissimo il metodo con cui è stato recensito il sito, con tanto di voti per ogni singola caratteristica e commenti dettagliati su ogni problema evidenziato. Mancanze nell’xhtml, inaccessibilità di alcune sezioni con le immagini disabilitate, tutte cose che mi erano sfuggite e che adesso so come correggere.

Consiglio a tutti gli sviluppatori web con un sito accessibile di sottoporsi all’esame, avere un feedback accurato da parte di altri utenti è utilissimo. Unica pecca l’attesa: per essere recensito ho dovuto aspettare circa 3 mesi, anche se dopo poche settimane avevo già ricevuto l’approvazione e sapevo sarei entrato nello showcase.

Accessible search: Google diventa accessibile?

Accessibilità

La notizia sta facendo il giro della rete: Google ha dato il via ad un nuovo tipo di ricerca accessibile: accessibile search, appunto.

Il nuovo servizio su cui stanno lavorando i Google labs sembra essere nato sotto buoni auspici, soprattutto visto l’interesse che ha suscitato su internet. Sostanzialmente è una nuova funzione di ricerca, che restituisce risultati in base alla presunta accessibilità delle pagine di destinazione. Non viene quindi considerata solo la rilevanza delle parole chiave, ma questa viene combinata con i contenuti, favorendo in teoria i siti costruiti secondo le WCAG e che privilegiano la semantica del codice.

In teoria, perchè attualmente la ricerca accessibile non sembra funzionare ottimamente. Nei miei test ho ottenuto ai primi posti siti con layout tabellare, costruiti con Frontpage o altri editor visuali, insomma non esattamente quello che viene raccomandato dal W3C. Altra stranezza: la stessa parola chiave mi dà risultati diversi a seconda del browser che utilizzo. Decisamente assurdo..

Ci sono anche utenti che non hanno notato alcuna differenza nei risultati tra la ricerca standard e quella accessibile. Di lavoro da fare ce n’è ancora quindi, ma se ben sviluppata questa idea potrebbe rivelarsi molto interessante.
Trovo importantissima però un’altra questione: Google si preoccupa di fornire risultati accessibili per utenti disabili o con problemi di vista, ma la pagina della ricerca non è affatto corrispondente agli standard web! Accessibile sì, ma solo nei risultati e non nello strumento che dovrebbe essere alla base della nuova funzione.. paradossale, non trovate?

Controllo del codice html non standard: B.R.A.T.

Important

Vi è mai capitato di realizzare un sito, creare delle pagine con codice xhtml valido, e poi scoprire che gli editori a cui l’avete affidato l’hanno rivoluzionato? Purtroppo è facile trovarsi in situazioni del genere, con pagine diventate inaccessibili magari a causa di editor di testo visuali, riempite di tag html come font e center che vanno a rovinare il vostro lavoro.

Un rimedio molto semplice ma altrettanto efficace è stato ideato su accessites.org da Marco Battilana, che ha chiamato la tecnica B.R.A.T.: acronimo di Big Red Angry Text.

Nel suo intervento presenta un sistema molto semplice ma altrettanto efficace per controllare il testo inserito dagli editori nei siti che avete pazientemente creato, evitando che venga usato codice non standard ed elementi deprecati, come appunto i tag font, center o l’attributo align.

Basta aggiungere delle righe di codice nel vostro css, che potete vedere direttamente nell’articolo originale. Non sto a riportarle qui per evitare problemi di copyright, e mi sembra giusto così.
Il risultato? Quando verranno usati i tag che voi indicherete nel css, appariranno delle enormi scritte rosse, che probabilmente convinceranno l’editore a cambiare qualcosa.

Che cosa ne pensate? Avete avuto mai problemi di questo tipo? Io sono quotidianamente alle prese con questioni simili, che possono in parte essere risolte tramite css, ma a volte dipende tutto dall’editore e da quanto è stato ben istruito. Facile trovarsi inserite immagini dal peso di 2mb.. e questo è solo un esempio!

10 ragioni per un sito accessibile

Un recente articolo su accessites.org elenca le 10 ragioni per motivare la realizzazione di un sito accessibile. Ho trovato la lettura molto interessante, anche se si riferisce soprattutto a motivazioni commerciali ed ha alcuni riferimenti validi solo per gli Stati Uniti, ma l’idea alla base è ottima.

Per questo motivo voglio riproporre le 10 ragioni in un articolo in italiano su questo sito, sperando che possano aiutare qualcuno a spiegare ancora meglio le proprie scelte davanti ad un possibile cliente.

  • Coinvolgete il cliente, facendogli capire i vantaggi del considerare tutti i possibili visitatori. La frase esplicativa del concetto è touch on the human side, c’è bisogno di maggiore sensibilità per determinati temi.
  • Avere un sito accessibile è un ottimo spunto pubblicitario, ed un argomento che può sempre essere citato per farsi notare da stampa ed affini.
  • In Italia c’è la legge Stanca: riguarda solo le pubbliche amministrazioni obbligandole ad avere siti accessibili, ma non è un male pensare di portarsi avanti col lavoro in previsione di norme future. In Inghilterra ad esempio ci sono già.
  • I numeri sono dalla parte dell’accessibilità: alcuni tipi di dislessia arrivano al 15%, altri tipi di problemi alla vista al 7%, sono cifre decisamente significative, tali da non poter essere ignorate.
  • L’uso dei CSS in maniera intelligente risparmia il lavoro di gestione di un sito. Sarà più facile aggiornarlo, e le novità generano sempre maggior traffico.
  • L’eliminazione delle tabelle per il layout significa minor spreco di risorse, anche in termini di banda. Risparmiare in questo senso, soprattutto per un sito con molti visitatori, è essenziale.
  • Un sito accessibile, se ben realizzato, non dipende dal mezzo con cui viene visitato. Con sempre nuovi browser, palmari e smartphone che arrivano sul mercato, scegliere un sito accessibile è un’ottima mossa.
  • Miglior posizionamento sui motori di ricerca, grazie anche ad una miglior semantica del codice
  • La popolazione di internet comprenderà fasce di età sempre più avanzate, è importante muoversi anche in questo senso.
  • E’ la cosa giusta da fare, perchè la rete è condivisione e non esclusione. Peccato che questo punto, il più importante, sia quello che in genere meno importa al cliente.

Mi sento di condividere tutti e 10 i punti, alcuni hanno maggiore importanza, altri meno, ma tutti andrebbero sempre ricordati. Se avete idee differenti a riguardo, o altre motivazioni, non esitate a scriverle!

Considerazioni sulle WCAG 2.0

Leggendo un articolo su A List Apart, ho trovato delle inquietanti riflessioni che riguardano le future WCAG 2.0, ovvero le linee guida da seguire per l’accessibilità dei contenuti della rete.

La prima versione delle WCAG risale al 1999, e negli ultimi tempi sono molti gli sviluppatori web che ne cominciano a seguire le indicazioni. Questo va a vantaggio di tutti gli utenti, perchè le problematiche riguardanti l’accessibilità non riguardano esclusivamente i disabili, e sarebbe un grave errore pensarlo.

Perchè allora lavorare su una nuova versione di queste linee guida? Il motivo alla base è fare in modo che le indicazioni possano essere valide in un contesto più largo, senza fare riferimento a tecnologie specifiche o a tipi di contenuti particolari, restando più generici possibile.

Faccio un esempio che sicuramente lascerà interdetti tutti coloro (me compreso) che hanno sempre seguito gli standard, ma che spiega il cambiamento: nelle WCAG 1.0 troviamo chiaro il divieto di utilizzare le tabelle per scopi presentazionali. Vanno usate (giustamente aggiungo io) solo per organizzare dati tabellari. Ma ecco la sorpresa: nelle WCAG 2.0 viene detto di non utilizzare il codice in maniera semanticamente scorretta, e basta. Viene poi semplicemente aggiunto:

“Note that the use of HTML tables for layout is not an example of this failure as long as the layout table does not include improper structural markup”

In pratica basterebbe evitare di mettere tag impropri dentro le tabelle, come th o caption.

La speranza è che questo documento subisca nuove modifiche essendo ancora una bozza, ma la preoccupazione che certi standard subiscano una decisa inversione di tendenza è abbastanza grande. Nell’articolo di A List Apart vengono indicati altri punti che fanno sorgere molti dubbi sulle WCAG 2.0, ne riporto alcuni:

  1. Un futuro sito che risponderà agli standard delle WCAG 2.0, non necessiterà di codice xhtml valido. Sarà però necessario controllare che il risultato sia uguale sui diversi browser.
  2. Potranno essere usate tabelle per il layout (come detto sopra)
  3. La pagina, o parte di essa, potrà lampeggiare per un periodo di 3 secondi (o mostrare animazioni con effetto simile).
  4. Al livello più basso di conformità alle WCAG 2.0, non sarà necessario fornire contenuto alternativo per i video pubblicati
  5. Non potrà essere usato il posizionamento fuori dallo schermo (il famoso position:absolute; top: -9000px; left: -9000px ) per mostrare contenuti solo a certi utenti, come gli utilizzatori di screenreader. Ogni visitatore dovrà vedere gli stessi contenuti.
  6. Non si potrà usare il posizionamento tramite CSS per eliminare elementi della pagina dal normale flusso del codice (ad esempio position: absolute ). L’ordine degli elementi nel codice dovrà corrispondere con l’ordine degli elementi presentati all’utente.

Questo è solo un semplice estratto, ma è abbastanza per rendersi conto di quali cambiamenti ci siano in programma. Se volete documentarvi meglio sulla vicenda, questa è la documentazione (in inglese):

Sicuramente ci saranno altri aggiornamenti sulla vicenda, ma l’impressione generale è che le basi di queste linee guida siano state gettate e difficilmente cambieranno. Aspetteremo notizie a riguardo, sperando in qualche variazione.

Yahoo! e la nuova grafica

Yahoo!

Yahoo! si prepara a cambiare veste grafica, e dalla homepage è già possibile vedere la nuova versione all’opera tramite un collegamento in alto a destra.

Il cambiamento è notevole, spicca il menu verticale a sinistra ed i vari menu a tab interni, che consentono una navigazione nel dettaglio senza dover caricare nuove pagine.

Tutto questo però passa in secondo piano davanti ad una scelta che è decisamente azzardata: la risoluzione minima per questa nuova grafica è 1024×768. Considerando che Yahoo! è un portale assolutamente popolare, non un sito tecnico, e che vi accedono utenti di tutti i tipi, mi pare assurdo non considerare chi naviga ad 800×600.

O meglio, tale risoluzione viene ricordata, ma tramite una funzionalità marginale e seminascosta. Infatti c’è un link sulla destra dell’header che consente di vedere la pagina in versione narrow, oltre a dare la possibilità di cambiare il colore di sfondo.

Come testimonianza basta dare un’occhiata alle statistiche disponibili su w3schools aggiornate a Gennaio 2006. Alla voce Display Resolution c’è ancora un buon 20% corrispondente agli utilizzatori di una risoluzione 800×600.

Dieci peccati mortali del web design

Mi sono imbattuto in un articolo in inglese, intitolato Ten deadly sins of web design sul blog di Roger Johansson.

E’ un intervento che ha la sua importanza, e che a sua volta è stato tratto da una pubblicazione di un magazine svedese chiamato CAP&Design. Mi sembrava giusto quindi riportarlo in italiano, per tutti coloro che con l’inglese non hanno molta praticità.

Questo articolo come potete intuire dal titolo elenca i 10 errori che un buon web designer non dovrebbe mai commettere. Purtroppo è possibile trovare questi peccati in molti siti, e sono molti gli sviluppatori che non sanno nemmeno di sbagliare a compiere certe azioni. Questo è l’elenco:

  1. Non seguire le regole tipografiche basilari
  2. Essere troppo creativi con la navigazione
  3. Creare un sistema di navigazione con troppe voci
  4. Fare in modo che il sito richieda determinate tecnologie per funzionare
  5. Pensare che l’accessibilità riguardi solo i non vedenti
  6. Ignorare gli standard web
  7. Non considerare i motori di ricerca fin dal principio
  8. Basare la struttura del sito sul proprio modello dati
  9. Usare testo grigio su uno sfondo grigio
  10. Non effettuare l’analisi di fattibilità

Penso che i 10 punti siano già autoesplicativi, l’analisi dettagliata di ognuno di essi per il momento è presente solo sul magazine svedese. E’ comunque probabile che in futuro qualcuno riprenda l’articolo traducendolo in una lingua più diffusa.