Il costo di un sito accessibile

Quanto costa l’accessibilità? Un’analisi dei fattori da considerare nella creazione di un sito accessibile.

Realizzare un sito accessibile ha dei costi, inutile negarlo. Che ci sia da creare un nuovo sito o adattarne uno esistente, non è un’operazione fattibile senza spese, nonostante sia in vigore una normativa come la Legge Stanca che è stata proprio approvata come a costo zero.

Su questo blog l’intervista ad Elena Brescacin, una sviluppatrice non vedente, è stata l’occasione per tornare sull’argomento ed è quindi giusto approfondirlo.

Il costo dipende dal progetto

Sembra una banalità, ma quando si parla di accessibilità molti si tirano indietro immaginando spese enormi. In realtà non è così: si tratta di un investimento. Realizzare un sito che segua gli standard web e sia accessibile non è sempre così complicato o dispendioso in termini di tempo come si potrebbe pensare.

Ovviamente per portali complessi il discorso cambia, ma parlando di blog, siti statici e progetti senza enormi pretese è possibile ottenere facilmente ottimi risultati. Cosa serve? Un team di lavoro (o uno sviluppatore) competente, che conosca gli standard del W3C e realizzi siti accessibili come se fosse una regola, non un’eccezione. L’accessibilità è anche questione di professionalità.

C’è una grande differenza anche se il progetto deve occuparsi della creazione di un sito completamente nuovo o della ristrutturazione di uno esistente. A volte dover progettare da zero è molto più semplice e veloce.

Parlando più concretamente, in certi casi basta veramente poco perchè un sito segua i requisiti minimi: codice ben organizzato, uso coerente dei titoli h1-h6 ed una navigazione intuitiva possono essere quantificati in poche ore di lavoro.  L’accessibilità non è solo questo, ma sarebbe già un passo avanti per la maggior parte dei siti esistenti.

I costi di formazione e manutenzione

Per non essere troppo di parte, è bene comunque mettere in chiaro che un sito accessibile non resta tale se non viene mantenuto a dovere.

Posso fare un esempio pratico con WordPress: realizzare un tema accessibile non è difficile, ma chi inserisce i contenuti deve essere istruito. Il rischio altrimenti è di trovarsi un ottimo contenitore riempito di spazzatura, che renderà inutile il lavoro fatto.

Per questo motivo in un progetto serio è necessario prevedere anche delle spese per la formazione di chi dovrà occuparsi dei contenuti e per interventi di manutenzione successivi, a meno che non si parli di siti statici.

L’accessibilità è un investimento

E’ bene comunque comprendere fin da subito che l’accessibilità è una grande possibilità. Un sito accessibile segue gli standard, viene indicizzato meglio dai motori di ricerca e quindi porta migliori risultati di un sito non accessibile o ancora peggio interamente realizzato con tecnologie come Flash.

La logica conseguenza di tutto questo è che pubblicando un sito accessibile i potenziali clienti di un’azienda aumenteranno, e ci sarà anche un ovvio ritorno dal punto di vista dell’immagine.

Non è un caso che all’estero, dove la situazione è molto più evoluta rispetto all’Italia, numerose aziende abbiano capito l’importanza degli standard web e dell’accessibilità. L’etica non c’entra, perchè non è quello che interessa veramente: certe scelte sono dettate da vantaggi concreti.

Conclusioni

Ho cercato di realizzare un quadro generale sui costi di sviluppo di un sito accessibile, ma a questo punto vorrei avere anche il vostro punto di vista. Le tematiche correlate sono numerose e sicuramente possono essere approfondite: cosa ne pensate?

Dite la vostra nei commenti, anche se non avete esperienze personali a riguardo ogni contributo è ben accetto.

L’usabilità dei link testuali

Una guida per la corretta formattazione dei link di testo, evitando soluzioni poco usabili.

I collegamenti testuali di una pagina sono un elemento basilare; capita spesso però che vengano sottovalutati dagli sviluppatori, dando per scontato la loro riconoscibilità.

Per avere dei link usabili in realtà basta seguire alcune semplici convenzioni: implementarle non richiede molto tempo, ma i vantaggi per i vostri utenti saranno evidenti.

Le convenzioni da seguire

In certi casi il rischio di confondere chi visita la pagina è alto: quante volte vi è capitato di provare a cliccare su un testo che in realtà non era un collegamento? Per evitare questi problemi, bisogna tenere presenti alcuni parametri:

  • Colore – Uno dei fattori principali per distinguere un link dal resto della pagina è il suo colore, differente da quello del contenuto. Attenzione però, perchè il colore da solo non è sufficiente: pensate ai problemi che potrebbe incontrare un utente daltonico.
  • Stile – Ci sono numerosi stili a disposizione, dalla sottolineatura al grassetto, passando per il tipo di font utilizzato. L’importante è che venga usato uno stile differente dal resto della pagina: la pratica comune vede i link sottolineati, ed è bene seguire questa convenzione.
  • Contrasto – Un link deve essere in evidenza, e non deve essere difficile da identificare. Cambiare il colore non basta, il contrasto deve essere elevato.
  • Comportamento – Tra le convenzioni più diffuse c’è quella del cambio di cursore al mouseover. Vedere il puntatore trasformarsi in una mano è indispensabile.

Tenendo presenti questi fattori, è possibile ottenere molteplici combinazioni usabili. Sperimentare è lecito, ma ricordate che innervosire i vostri utenti con dei link non riconoscibili, o ancora peggio dei testi normali che sembrano collegamenti, potrebbe causare la loro fuga. Non aspettatevi di ricevere segnalazioni nel caso ci siano problemi di questo tipo, il visitatore medio lascerà il vostro sito innervosito senza concedervi altre possibilità.

Qual è la pratica migliore?

Di default i collegamenti hanno la sottolineatura con text-decoration: underline, ed un colore blu facilmente riconoscibile.

Personalizzando questa impostazione, tenete presente che la sottolineatura è tuttora la pratica migliore e più diffusa. Se però non vi piace il risultato finale, potreste considerare di utilizzare un border-bottom al suo posto, come viene fatto su A List Apart. Il risultato può essere ulteriormente migliorato con 1 pixel di padding-bottom:

Un esempio dei link testuali di A List Apart

Un’altra pratica piuttosto diffusa, che utilizzavo su questo sito qualche tempo fa, sono i link in grassetto, senza sottolineatura. Il problema è che la distinguibilità dei collegamenti in questo caso dipende molto dal colore. Un esempio chiaro si ha su TechCrunch: guardando la pagina in bianco e nero grazie a GrayBit, i link non sono così evidenti come quelli sottolineati:

Un esempio dei collegamenti testuali su TechCrunch

Ovviamente le varianti possibili sono infinite, l’importante è essere sempre consapevoli di quello che si sta facendo.

Ricordate comunque che in certi casi l’originalità può essere messa da parte e riservata ad altri dettagli: dei link usabili e facilmente riconoscibili sono indispensabili per garantire ai vostri utenti la migliore esperienza di navigazione possibile.

Userfly: uno strumento per i test di usabilità

Test di usabilità accessibili a tutti con una nuova applicazione web.

UserflySembra si siano accorti in molti dell’importanza dei test di usabilità per il successo di un sito: dopo la nascita di un’applicazione desktop come Silverback, è arrivato il suo equivalente web-based, Userfly.

L’obiettivo di questo strumento è quello di fornire test di usabilità utilizzando utenti reali. Basta inserire una linea di JavaScript e le azioni dei vostri visitatori saranno monitorate praticamente in tempo reale.

Sul sito dell’applicazione infatti avrete accesso a dei veri e propri screencast, che vi consentiranno di seguire le azioni dei vostri utenti: movimenti del mouse, click, scrolling delle pagine ed interazioni di base con gli oggetti presenti.

Il test che ho effettuato è stato estremamente positivo: gli screencast sono stati generati quasi in tempo reale e fin da subito sono rimasto affascinato dalle potenzialità di questo strumento.

Qualche difetto c’è: le interazioni con oggetti AJAX, ad esempio, non vengono memorizzate. E’ anche possibile che nei momenti di particolare traffico alcuni utenti potrebbero non venire monitorati, ma considerando che è un tool nato da poco c’è tempo per vederlo crescere e migliorare.

E’ disponibile anche un video per vedere Userfly all’opera e capirne meglio il funzionamento:

Per chi avesse delle riserve dal punto di vista della privacy, c’è da notare che strumenti simili esistono da tempo. Basti pensare a CrazyEgg, ma in realtà Userfly è assimilabile a tutti gli altri tool capaci di tracciare le azioni degli utenti, a partire da Google Analytics.

Se avete un sito vi consiglio di provarlo: al momento della registrazione vi verranno dati i crediti necessari alla registrazione di 10 screencast. Successivamente, potrete registrare le azioni dei vostri utenti pagandole 0,05$ l’una, una cifra decisamente accettabile considerando la facilità e l’immediatezza dello strumento.

Aggiornamento del 13 Febbraio 2009: vi segnalo anche una promozione in corso legata a Twitter. Se vi registrate ad Userfly (o siete già utenti) e lo segnalate ai vostri followers su Twitter, riceverete gratuitamente altri 5 crediti.

Intervista ad Elena Brescacin: una Web Developer non vedente

Due chiacchiere con Elena “talksina” Brescacin sull’accessibilità della rete da un punto di vista pratico.

Elena Brescacin è una Web Developer non vedente classe 1980, con cui ho avuto l’occasione di collaborare recentemente per il suo blog personale.

Sono rimasto stupito dalla sua abilità e dalle capacità che ha dimostrato di avere, e così le ho proposto di fare un’intervista per questo sito. Le sue risposte possono essere utili più di tanti tutorial e linee guida, per far capire veramente cosa sia l’accessibilità e quanto sia importante ricercarla nello sviluppo di un sito.

Il risultato è una chiacchierata particolarmente lunga, ma quella di non sintetizzarla è stata una mia scelta. Spero che il risultato finale possa essere interessante per molti.

1. Ciao Elena, puoi fare una breve introduzione su di te?

Ciao, sono Elena Brescacin, 28 anni, cieca dalla nascita. Lavoro come web developer nel settore accessibilità dei siti web, ed ho tanti hobby tra cui la manipolazione dell’audio (realizzo jingle e suonerie), gli scacchi, l’arte marziale taekwon-do e generalmente dare una mano dove possibile ad amici blogger e webmaster.

2. Come sei diventata web developer? Quali strumenti usi per lavorare?

Ho iniziato da autodidatta nel 2000, dopo un paio di esperienze lavorative poco felici avute dopo la scuola superiore. Tramite html.it ho imparato a costruire le mie prime pagine web, il mio primo sito personale, con la possibilità di metterci gli audio e personalizzarlo a mio piacimento e soprattutto di capire che cosa gli altri sbagliassero quando i siti non erano accessibili.

L’interesse per l’accessibilità è venuto da solo, come esigenza di collaborazione tra utente disabile e sviluppatore (non c’è niente di meglio!). Poi ovviamente ho fatto dei corsi sull’argomento, e alla fine ho trovato lavoro nel mio settore.

Come strumenti, dipende dalle esigenze e dal lavoro; passo da prodotti commerciali a prodotti free, anche se la mia maggiore preferenza è per gli editor di codice, più che quelli visuali: questi ultimi mi complicano parecchio la vita in quanto le opzioni sono tutte grafica e punta-e-clicca, cosa che a un vedente aiuta, a un cieco invece crea solo problemi.

3. Quali problemi hai trovato nello svolgere il tuo lavoro, ad esempio con CMS come WordPress?

Come già detto, i problemi sono specialmente imputabili alle funzionalità degli editor visuali; io mi riferisco chiaramente soltanto alla disabilità visiva perché è quella che conosco, ma il problema riguarda tutti.

Che gli editor siano dei programmi per desktop, oppure implementati all’interno di un CMS free o commerciale, spesso gli sviluppatori non tengono conto delle esigenze di accessibilità nelle funzioni facilitate (pulsanti per aggiungere link, immagini, spostare oggetti, ecc) per cui con questi applicativi si possono realizzare siti completamente accessibili lato utente, ma lato amministratore non si riesce a fare quasi nulla.

Il risultato è che un cieco che voglia intraprendere l’esperienza dello sviluppo web, deve avere un’ottima conoscenza del linguaggio di marcatura o programmazione usato per il proprio applicativo. L’unico modo per poter gestire contenuti è quello di disabilitare l’editor visuale e scrivere il codice in formato testo, o comunque trovare degli escamotage che in quanto tali, rallentano di molto il lavoro.

Io sono una lottatrice e non mi lascio certo spaventare da un editor, però molti miei “colleghi” anche loro giovani, si sentono scoraggiati dall’esperienza del web perché costretti in qualche modo ad imparare un linguaggio, mentre i loro compagni vedenti possono sviluppare siti anche senza saper niente di codice.

Certo la padronanza di almeno un linguaggio di marcatura, scripting o programmazione, è un vantaggio perché aiuta a costruire meglio i siti e gli applicativi; di contro, lo svantaggio è che ci sono pochissimi sviluppatori ciechi e per questo l’accessibilità del web è poco sentita, considerata solo una cosa da addetti ai lavori, più che un’esigenza di molti. E le associazioni di categoria fanno troppo poco rispetto alle lacune che si dovrebbero colmare.

4. Hai un esempio pratico di problemi con l’amministrazione di WordPress?

Quando parlavo di “escamotage” posso fare un riferimento concreto: il sistema di widget di WordPress.

Nella versione 2.3 era a dir poco impossibile avere una barra laterale dinamica: i widget erano soltanto trascinabili tramite il mouse quindi mi dovevo far aiutare ogni volta.

Dalla 2.5 per fortuna hanno introdotto un link “aggiungi”, “modifica”, “rimuovi”… in modo che io posso anche da tastiera mettere e togliere i widget a piacimento. Il problema rimane nello spostarli: non posso accedere al drag&drop fattibile solo da mouse, quando basterebbe accanto a ogni widget aggiunto un paio di link “sposta su” e “sposta giù”.

L’escamotage sta nel crearsi un file di testo con tutti i nomi dei widget desiderati, poi rimuoverli tutti, e riaggiungerli uno a uno secondo l’ordine nuovo desiderato. Lavoraccio che, uno fa una volta, la seconda non lo fa più!

5. Quali sono i problemi principali con cui ti scontri navigando su internet, nonostante la tua esperienza?

I captcha.

Uno dei maggiori problemi che un cieco incontra navigando su internet, è oramai la quasi onnipresenza dei captcha, nati per impedire a chi fa pubblicità indesiderata di accedere ai vari servizi: dai semplici commenti su siti o blog, alle registrazioni su portali più complessi e piattaforme di commercio elettronico.

Talvolta questi test sono accompagnati da controlli audio, ma anche questi spesso e volentieri o sono solo in inglese, oppure non si sentono e non si capiscono. Il risultato è che le aziende che fanno pubblicità indesiderata hanno le fonti di reddito per aggirare questi controlli come vogliono, costruendo dei sistemi di calcolo sofisticati, oppure semplicemente pagando pochi dollari a studenti adolescenti ai quali, per dire, basta avere garantita ogni mese la ricarica del cellulare per compilare a mano i sistemi anti-robot.

Un cieco, da queste misure, sarà sempre e comunque discriminato per vari motivi:

  • la privacy che i captcha dovrebbero proteggere, viene nel nostro caso automaticamente violata in quanto dobbiamo dare, o far vedere, i nostri dati sensibili a terze persone. Quando si tratta di password o numeri di carta di credito, sinceramente, la fiducia vale ma sempre fino a prova contraria… per non parlare poi del fatto che ci son servizi che chiedono di compilare un test di sicurezza visuale pure per cambiare o ripristinare la password. Lasciamo stare.
  • anche trovando i siti di studenti che risolvono i captcha (onestamente ammetto di aver tentato di contattarne uno), dicono NO, in quanto loro compilano sì i captcha a 3 dollari l’uno, però devono aver la garanzia di doverne compilare almeno 100. E all’epoca me ne serviva uno.

Un altro grosso problema di accessibilità si ha quando si usano certe funzionalità AJAX, in cui i link sono cliccabili ma non sono visualizzati come tali. Un esempio è la versione standard di GMail, o molti siti di home banking, di cui posso usufruire solo navigando la pagina come se fosse un file Word anziché usare tutti i comandi rapidi che gli screen reader mi offrono.

Poi i flash che scorrono o che non hanno etichette nei controlli, i form con il focus che si muove in automatico sulle caselle di selezione o sui campi di testo, ed immagini e controlli senza testo alternativo.

6. Parlando invece di non vedenti senza la tua esperienza, com’è la situazione attuale della rete? Quali sono i problemi più diffusi?

La situazione è abbastanza difficile da due punti di vista: ci sono dei non vedenti senza esperienza che non hanno voglia di imparare e mettono in difficoltà gli sviluppatori chiedendo sempre la pappa pronta; dall’altro lato alcuni web developer pensano che la creatività venga limitata dall’accessibilità, ed i problemi continuano a rimanere.

L’unico modo per avere una rete accessibile è rispettare gli standard, evitando di “inventarsi” i metodi: ad esempio a che cosa serve creare i punti elenco con delle immagini, quando in HTML ci sono gli attributi ben definiti che permettono di mettere pure i disegnini ma lasciando la lista completamente accessibile?

Parlando dei blog, dovrebbero essere sempre accessibili anche tramite la tastiera, con la possibilità di attivare e disattivare la visualizzazione dei link non indispensabili come i tag: spesso e volentieri questi sono anche una decina per ogni articolo, il che può creare problemi (gli screen reader scorrono tutti i link di una pagina uno ad uno NdTom). Una soluzione per WordPress è in questo articolo di Studio404.

Una considerazione anche sul tabindex: viene messo come requisito di accessibilità, ma mi sento di consigliarlo quasi esclusivamente per i siti statici. In un sito dinamico come un portale o blog non si può mai avere un ordine logico definitivo e la navigazione tramite tab dall’inizio alla fine del blog è fondamentale. Usando il tabindex invece si altera l’ordine di scorrimento, ed il risultato è che un cieco non esperto viene costretto a saltare alcune parti, leggendo come minimo solo un 50% di quello che leggerebbe normalmente.

7. Ci sono dei siti “popolari” a cui vuoi rivolgere delle critiche perchè non accessibili?

Mi creano difficoltà i siti di news: ANSA, Corriere della Sera, Repubblica, Oggitreviso e altre testate giornalistiche che sono piene di Flash e pubblicità che scorrono. Un quotidiano non dovrebbe in alcun modo avere questi problemi! Benedetto chi ha creato i Feed RSS che mi permettono di leggere e scegliere i titoli che mi interessano.

8. Che consigli daresti agli sviluppatori interessati all’accessibilità dei propri siti?

Il consiglio che vale sempre è quello di attenersi più possibile agli standard del W3C, più specificamente alle WCAG 2.0 che, rispetto alla versione precedente, si riferiscono a tutte le tecnologie e non soltanto all’HTML.

Certo non si può imparare tutto a memoria, ma capire e conoscere gli standard è già un buon passo avanti. Inoltre c’è da considerare che non si può parlare di accessibilità senza citare l’usabilità; presentazione e contenuto vanno equilibrati per venire incontro alle esigenze di tutti, non soltanto alla propria creatività.

9. In conclusione, vorresti aggiungere qualcosa?

Solo che sarebbe ora di restituire al web il suo significato originale: worldwide web.

Tutti digitano www sulla barra indirizzi ma non sanno nemmeno cosa significa! La rete dovrebbe essere universale, ma oramai tutti (privati e aziende) vedono il web a modo loro senza rispettare l’accessibilità.

Ci sono situazioni in cui la mancanza di accessibilità può davvero nuocere al diritto sacrosanto di riservatezza delle persone. Basti pensare ai siti riguardanti la salute: un cieco con il bisogno di informazioni su specifici problemi medici sarà costretto a condividere per forza i problemi di salute con qualcuno, magari tutto per colpa di un captcha.

Se tutti gli sviluppatori avessero un po’ più di rispetto e sensibilità verso i fruitori delle loro creazioni, disabili o no, il web sarebbe migliore.

La risoluzione giusta per un sito web

Analisi delle ultime statistiche sulle risoluzioni più utilizzate e consigli per la creazione del layout ideale.

Website mockup

Quello della risoluzione migliore per un sito web è un problema spesso sottovalutato. Negli ultimi anni la situazione si è semplificata visto l’ormai definitivo tramonto dei siti ad 800×600, ma questo non mette al riparo da possibili scelte sbagliate.

Le statistiche aggiornate

Secondo il report aggiornato a Dicembre 2008 di Net Applications, 1024×768 resta la risoluzione più diffusa con il 37%, e lo sarà ancora per diverso tempo.

Seguono valori più elevati, da 1280×960 (20%) a 1280×1024 (13%), per poi passare a risoluzioni ancora maggiori.

Una piccola curiosità: la risoluzione più bassa dopo 800×600 (4.49%) è quella di Safari su iPhone, 320×396 pixel (0.53%), importante segno dell’evoluzione del settore mobile.

Le altre combinazioni esistenti sono innumerevoli, soprattutto con l’avvento dei monitor widescreen, e proprio per questo realizzando un sito web è necessario valutare tutte le possibili situazioni.

Le dimensioni della finestra del browser

Un altro fattore difficile da valutare è quello della dimensione della finestra del browser. Pensate alle vostre abitudini: la tenete sempre a tutto schermo? La risposta in genere dipende dal monitor, io dove lavoro, con un monitor a 1280×1024 ho il browser a tutta pagina, ma questo non succede a casa su una risoluzione di 1680×1050 pixel.

Non è detto quindi che i dati ricavati dalle statistiche corrispondano alla situazione reale: un utente con un grande monitor difficilmente terrà la finestra del browser a tutto schermo.

Le percentuali cambiano anche a seconda del sistema operativo. Gli utenti Mac si comportano diversamente da quelli Windows, come era emerso da questo interessante sondaggio di Roger Johansson. Su Mac Os infatti si è più portati a non massimizzare le finestre.

I problemi con l’alta risoluzione

Avere come target un’ampia gamma di alte risoluzioni è comunque un problema da considerare. Questi sono i principali errori da evitare:

  • Layout a larghezza fissa allineati a sinistra
  • Layout fluidi senza max-width, con aree di testo molto estese in orizzontale o font-size troppo piccolo.

I siti allineati a sinistra possono andare bene fino ad una certa risoluzione, ma su monitor particolarmente grandi l’utente sarà portato a guardare solo un lato dello schermo. E’ una soluzione alternativa, che però mi sento di sconsigliare. Molto meglio mantenere l’allineamento centrale.

I layout fluidi sono più difficili da curare nei dettagli e presentano un grave problema di leggibilità se non controllati a dovere. A risoluzioni particolarmente elevate infatti i blocchi di testo rischiano di diventare troppo lunghi e faticosi da leggere.

Come scegliere il layout migliore

La prima cosa da fare rinnovando la grafica di un sito esistente è guardare le statistiche dei propri visitatori. I dati globali della rete hanno ben poca importanza rispetto a quelli dei vostri utenti e del target che vi siete prefissati. Potete usare le statistiche generali per capire quale sia l’andamento, riportandolo alla vostra esperienza.

Se invece state realizzando un nuovo sito, una larghezza minima intorno ai 960 pixel è la base di partenza ideale. A voi la scelta se utilizzare un layout a larghezza fissa, uno fluido, o addirittura uno elastico (anche se potrebbe essere giunto il momento di abbandonarli).

La soluzione a larghezza fissa in generale è quella più sicura, ma anche la più scontata. Una interessante via di mezzo si ottiene sfruttando il background della pagina per riempire lo spazio altrimenti vuoto. In questa galleria di Web Designer Wall ci sono degli ottimi esempi.

Nel caso invece vogliate un layout fluido, ricordate di impostare sempre una larghezza minima ed una massima, oscillando ad esempio tra i 900 ed i 1400 pixel.

Conclusioni

Queste indicazioni vogliono essere semplicemente un consiglio, non esistono verità assolute. In generale i layout a larghezza fissa sono sempre i più diffusi soprattutto per la facilità di realizzazione e le possibilità di controllo della struttura. Se però volete mettervi alla prova con un layout fluido, i vostri utenti potrebbero apprezzare un sito che si adatta alle loro abitudini.

Quali sono le vostre abitudini? Preferite un determinato tipo di layout o cambiate scelta a seconda delle situazioni? Dite la vostra per condividere pratiche e suggerimenti.

[Web Design Concept – Immagine di Shutterstock]

Web Accessibile: affrontare l’argomento in modo completo

Uno degli errori più comuni parlando di accessibilità è approfondire solo alcuni temi, correndo il rischio di confondere i propri lettori.

Icona accessibilitàL’accessibilità della rete è da tempo uno degli argomenti che mi appassiona di più, e cercare di seguire più fonti possibili sull’argomento è uno dei miei obiettivi principali. Proprio oggi mi è capitato di leggere un intervento in inglese su come rendere accessibile un sito web, intitolato “Paying attention to website accessibility“.

Il testo parla dell’importanza dell’argomento, limitando però il discorso a tre punti:

  • la conformità agli standard web del W3C
  • l’utilizzo di (X)HTML e CSS
  • l’utilizzo di JavaScript in maniera non intrusiva

Se da un lato sensibilizzare sui vantaggi di un sito accessibile è una buona cosa, post del genere rischiano di diventare controproducenti. Il pericolo maggiore è che l’accessibilità venga intesa erroneamente come l’applicazione di poche regole, quando la realtà è ben diversa.

Il rischio è soprattutto per i Web Designer con meno esperienza, che giustamente possono avere interesse ad avvicinarsi all’argomento. Basta poco per cadere in errore, soprattutto se si viene consigliati in maniera incompleta o sbagliata.

Tengo a sottolineare come la fonte citata sia semplicemente l’esempio più recente che mi sono trovato a considerare. Esistono tanti altri blog a cui potrei rivolgere le stesse osservazioni: è bene che si parli di accessibilità, ma è necessario affrontare l’argomento nel modo corretto. Un sito non diventa magicamente accessibile se il codice è valido o non utilizza le tabelle per il layout, così come non basta inserire i testi alternativi sulle immagini. Questi sono solo alcuni dei numerosi aspetti che aiutano a raggiungere l’obiettivo.

Gli argomenti da affrontare

Per chi volesse approfondire l’argomento, ho raccolto i collegamenti al materiale indispensabile: se doveste notare delle mancanze aspetto come sempre i vostri suggerimenti nei commenti.

Ecco le risorse principali da considerare:

Altri siti utili:

In conclusione, è bene parlare di web accessibile soprattutto perchè l’argomento non ha ancora l’attenzione che merita, ma va fatto con cognizione di causa. L’ambito è vasto ed affrontarlo in unica volta non è un’impresa facile.

Se non si ha la possibilità di approfondire a dovere tutti gli aspetti, in certi casi è meglio scrivere un post su un argomento più specifico: ci sarà sempre tempo per parlare del resto, senza il pericolo di confondere chi legge.

IA Summit 2009 a Forlì

Il 20 e 21 Febbraio si terrà il terzo Summit italiano di architettura dell’informazione, completamente gratuito.

IA Summit 2009

Quello dell’Architettura dell’Informazione è un mondo affascinante e complesso, che si affaccia su più discipline, compreso ovviamente il Web Design.

Se siete interessati ad approfondire l’argomento, vi segnalo il terzo IA Summit italiano che si terrà a Forlì il 20 e 21 Febbraio (Venerdì e Sabato). E’ un evento importante, i suoi organizzatori sono sinonimo di garanzia, e saranno presenti partecipanti italiani e stranieri (il programma è in via di definizione).

Se considerate inoltre che questo è l’unico evento in Italia sull’Information Architecture ed è totalmente gratuito, i motivi per partecipare diventano veramente tanti. Potete registrarvi per confermare la vostra presenza fin da ora.

HTML5: approfondimenti ed evoluzioni future

Una raccolta di materiale sulla specifica HTML 5, tra problemi di compatibilità presenti ed evoluzioni future.

Sono passati due anni e mezzo dalla pubblicazione dell’ultima bozza sulle specifiche XHTML 2.0 E’ passato più di un anno dalle discussioni su quale dovessere essere la direzione da seguire: XHTML 2.0 o HTML 5?

In questo contesto, sembra che negli ultimi tempi la questione abbia subito una decisa accelerata: si parla sempre più insistentemente di HTML 5 e molto probabilmente il 2009 sarà l’anno della sua affermazione.

Approfondimenti sulla specifica HTML 5

Per chi volesse saperne di più e scoprirne le basi è disponibile una Working Draft che illustra numerosi dettagli, i nuovi elementi a disposizione degli sviluppatori e l’utilizzo che ne dovrebbe essere fatto.

Inoltre proprio in questi giorni è stato pubblicato anche su A List Apart l’articolo Semantics in HTML 5 che affronta diversi argomenti, a partire dalla retrocompatibilità. Come era immaginabile, il problema principale è il mancato supporto di browser come Internet Explorer (6 e 7), mentre gli altri principali concorrenti si comportano egregiamente già adesso.

Parlando invece di nuove funzionalità, sul sempre eccellente Dev Opera è disponibile un articolo che illustra il funzionamento dei canvas, che permettono di creare della grafica direttamente in JavaScript.

In questo contesto, ci sono già stati i primi esperimenti:

  • il sito di An Event Apart, realizzato utilizzando (in parte) HTML 5
  • una pagina di test che comprende elementi come <header>, <nav> e <footer>, resa funzionante anche su IE grazie a JavaScript

Come è possibile vedere su quest’ultimo esempio, l’unico modo per rendere la specifica compatibile anche sul browser Microsoft è l’utilizzo di JavaScript: attenzione quindi perchè potrebbero esserci problemi per alcuni visitatori. Il modo più veloce per implementare questa soluzione è includere nella pagina questo script, tenendo presente i problemi di accessibilità.

Evoluzioni future

Allo stato attuale, è ancora prematuro parlare di HTML 5 su larga scala, soprattutto per i problemi di compatibilità citati. Dai numerosi interventi che sono stati pubblicati in questo inizio 2009 è comunque facile immaginare che sarà un anno importante per lo sviluppo della specifica.

Tenete presente però che lo stato di Proposed Recommendation è ancora lontano: qualcuno ha parlato addirittura del 2022. E’ sempre utile rimanere aggiornati sull’evoluzione degli standard web, ma le priorità attuali per un web designer sono ben altre.

La mia personale speranza è che ci sia la possibilità di continuare a vedere evolversi anche l’XHTML, ma non so quanto sarà possibile. E’ vero che anche adesso coesistono senza troppi problemi le due soluzioni, ma visto che lo stesso W3C ha voluto seguire con più convinzione una strada, non mi stupirei se questa restasse l’unica.

Come allineare le immagini dei post di WordPress

Alcune semplici istruzioni per risolvere i problemi delle immagini affiancate al testo su Wordpress.

Ultimamente mi è capitato spesso di trovare persone in difficoltà con l’allineamento delle immagini all’interno dei post di WordPress.

Dalla versione 2.5 infatti è cambiato il modo in cui vengono gestite: se prima erano utilizzati gli orrendi tag HTML come align=”left”, ora il funzionamento è diverso e tutto viene gestito tramite le classi CSS aligncenter, alignleft ed alignright.

Se quindi avete dei problemi simili a questo screenshot nell’allineamento delle immagini accanto al testo, molto probabilmente il tema che utilizzate non è ottimizzato per le ultime versioni di WordPress, dalla 2.5 in poi.

La soluzione

Il rimedio è semplice, e si trova anche sul sito ufficiale di WordPress. Infatti è sufficiente modificare il foglio di stile del tema che utilizzate (di solito style.css), aggiungendo le seguenti righe di codice:
.aligncenter,
div.aligncenter {
display: block;
margin-left: auto;
margin-right: auto;
}
.alignleft {
float: left;
}
.alignright {
float: right;
}
.wp-caption {
border: 1px solid #ddd;
text-align: center;
background-color: #f3f3f3;
padding-top: 4px;
margin: 10px;
/* optional rounded corners for browsers that support it */
-moz-border-radius: 3px;
-khtml-border-radius: 3px;
-webkit-border-radius: 3px;
border-radius: 3px;
}
.wp-caption img {
margin: 0;
padding: 0;
border: 0 none;
}
.wp-caption p.wp-caption-text {
font-size: 11px;
line-height: 17px;
padding: 0 4px 5px;
margin: 0;
}

La parte relativa alla classe wp-caption è per i sottotitoli delle immagini, introdotti dalla versione 2.6 di WordPress. Se non li utilizzate potete evitare di inserire quella parte di codice, ma vi consiglio comunque di copiarla per evitare problemi.

Se volete avere un CSS valido, vi faccio notare inoltre che le definizioni sul border-radius non sono standard, quindi dovrete eliminarle e rinunciare agli angoli arrotondati dei sottotitoli.

Aggiornamento del tema Stardust: pronto per WordPress 2.7

Rilasciata la nuova versione del tema Stardust per Wordpress: adesso compatibile anche con i post in evidenza ed i commenti nidificati.

Stardust v2.0Dopo aver ricevuto diverse richieste, ho appena rilasciato un aggiornamento per il tema WordPress Stardust, sia in italiano che in inglese.

Adesso è compatibile con la versione 2.7 di WordPress, e permette di utilizzare tutte le nuove feature di questa piattaforma: dai post in evidenza ai commenti nidificati e paginati.

Visti gli importanti cambiamenti, ho deciso di contrassegnare come versione 2.0 questa release del tema. Restano valide tutte le precedenti caratteristiche, eccole riassunte:

  • tema a 2 colonne
  • larghezza fluida
  • widget-ready
  • XHTML e CSS validi
  • accessibile
  • testato su Pc e Mac
  • cross-browser
  • compatibile con i post sticky
  • compatibile con i commenti nidificati e paginati

Potete scaricarlo dall’apposita pagina, in italiano o in inglese.

Contattatemi senza problemi per lasciarmi i vostri pareri, ho voluto fare l’aggiornamento in questi giorni per rilasciare a tutti gli interessati un regalo di Natale anche da parte mia. Buone feste!