Diego La Monica

Software, standards, accessibilità, usabilità & Web 2.0

Calendario senza tabella? Da oggi è possibile!

Introduzione

Un calendario in genere è costruito con una tabella.

Questa tabella è costruita da 5 o 6 righe (in dipendenza dei giorni delle settimane che costituiscono un mese oltre l’intestazione) e 7 colonne (quanti sono i giorni di una settimana).

L’effetto ottenuto con una tabella è tipicamente tra i migliori che si possono ottenere visivamente. Visivamente…Visivamente!

Visivamente???

E se uno avesse problemi visivi? E se qualcuno non riuscisse affatto a vedere? Ah beh la tabella ci viene incontro. Se qualcuno ha provato a scrivere una tabella e darla in pasto ad uno screen reader ci verrà fornita un informazione simile a quanto vi accingete a leggere:

Tabella, sei righe, sette colonne.
Riga di intestazione.
Colonna uno, Abbreviazione, Lunedì.
Colonna due, Abbreviazione, martedì.
...
Riga uno,
colonna uno, lunedì primo gennaio,
colonna due, martedì due gennaio,
colonna tre, mercoledì tre gennaio,
...
Riga due
colonna uno, lunedì sette gennaio,

Insomma tante informazioni, che ci fanno immaginare una tabella. Ciascuno screen reader potrebbe interpretare tali informazioni in modo leggermente differente. Ma il senso della tabella rimane.

Proviamo insieme ad immaginare un’alternativa alle tabelle. Cosa ci potrebbe essere? Immaginato? Si proprio quello. Un elenco puntato non ordinato.

Una causa inconfutabile

Ok quello che abbiamo detto non ci giustifica completamente nell’utlizzare un elenco puntato non ordinato al posto di una tabella.

Allora prendiamo in analisi gli smart phone. Alcuni utilizzano un sistema di parsing del xhtml che linearizza le tabelle. Quale sarebbe la conseguenza di un azione simile? 

        Lunedì
        Martedì
        Mercoledì
        Giovedì
        Venerdì
        Sabato
        Domenica
        Lunedì 1 Gennaio
        Martedì 2 Gennaio
        Mercoledì 3 Gennaio
        ...

Quante informazioni inutili, sprecate, non necessarie presentate su uno smart phone!

Lo so non siete ancora soddisfatti della spiegazione, allora cercherò di convincere anche i meno convinti di questa soluzione. Ci sono dei siti che si lodano con la frase “This site is tableless”: “Questo sito è senza tabelle”, allora questi “poveracci” (per modo di dire, non me ne vogliano a male!) dovranno fare a meno di usare un calendario che abbia la forma di un calendario sulle loro pagine? Chi ha risposto si, non ha motivo di proseguire in questo viaggio propositivo su cui si basa questo tutorial.

Ok allora proviamo a sviluppare qualcosa che visualmente somigli ad una tabella, semanticamente mantenga la sua struttura gerarchica, e che sia navigabile in modo accessibile.

Grafici a barre accessibili

Lo scopo di un grafico

Il grafico usualmente è utilizzato per mostrare l’andamento di un mercato o comunque di un generico valore nel tempo.
Solitamente un grafico è seguito sui libri da una leggenda che ne descrive velocemente il senso. Un esempio di etichetta potrebbe essere “densità della popolazione negli anni”. Sappiamo cosa contiene il grafico perché lo abbiamo letto, ma non sappiamo quali sono i valori in esso contenuti se questi non sono contenuti nel testo o (se lo fossero) se non lo avessimo ancora letto.
L’esempio più lampante che tutti i giorni abbiamo sotto gli occhi sono i contatori visite, Shinystat, toSend.it, ed altri esempi sono disponibili sulla rete. Attualmente tutti quanti soffrono di un gravissimo difetto: il non essere accessibili o non esserlo completamente. Alcuni perché fanno uso di Flash senza curarsi delle regole di accessibilità che questo mette a disposizione, altri perché fanno uso di una unica immagine elaborata sul server e restituendo quindi una didascalia per l’immagine: “Grafico delle visite per il mese di….”.

L’analisi

La soluzione che andremo ad implementare, fa uso semplicemente di XHTML e CSS.
Come al solito per evitare problemi di compatibilità con alcune policy aziendali, non si farà uso di Javascript. Quindi mettiamoci all’opera!
Il concetto di base è creare un grafico a barre orizzontali in un box.
Ciascuna barra sarà proporzionale al valore che dovrà indicare.
Ciascuna barra riporterà l’informazione sul valore percentuale da rappresentare.
Nel caso non fossero supportati i CSS (browser testuali o screen reader), il significato del grafico non si perderà riportando descrizioni esatte sul cosa si sta rappresentando.

Tooltip senza Javascript

Sponsor:

Introduzione

Era un comune pomeriggio di un comune giovedì, ero al computer che pianificato alcune attività da portare avanti entro i due giorni successivi e durante la settimana successiva quando un amico mi pone un quesito interessante: “come posso rendere degradabile un javascript per creare tooltip?“.

Quella domanda ha fatto accendere in me quella lampadina che qualche volta si illumina, si è azionato quel meccanismo assurdo chiamato logica che scava nei meandri della memoria e della conoscenza per trovare risposte ad altri problemi che ti conducono poi a scoprire che in realtà quello che stai cercando è la soluzione al tuo quesito! Ed infine la trovi!

Alla base fu CSS

La prima cosa che ho pensato per poter creare un tooltip è stato: se non posso usare javascript devo sfruttare i CSS (un po’ come dire se non è zuppa è pan bagnato!).
Poi mi sono fatto un’altra domanda: ma conviene? La risposta è stata affermativa… altrimenti non avrei scritto questo breve tutorial!
Queste sono state le considerazioni che ho fatto quando ho valutato l’effettiva validità della soluzione:

  1. Con javascript posso creare infiniti effetti di comparsa del menu, con i CSS no.
  2. Con javascript posso creare un cursore che segue il movimento del mouse, con i CSS no.
  3. Con javascript devo verificare che il codice che scrivo abbia lo stesso effetto su Internet Explorer 5.5, 6 e 7, su Firefox, su Konqueror, Safari, Camino, Mozilla, Netscape, Opera con i CSS, utilizzando caratteristiche standard, no.
  4. Senza javascript le informazioni del tooltip sono sempre presenti sulla pagina (quindi informazioni indicizzabili dai motori di ricerca)
  5. Senza javascript l’accessibilità in quelle realtà dove non sono abilitati gli script o non sono affatto contemplati (alcuni dispositivi mobili) è garantita
  6. Senza javascript e senza CSS l’informazione è sempre disponibile e l’utente non è vincolato all’utilizzo di una tecnologia specifica per fruire la pagina e l’informazione in essa contenuta

Già solo la quarta considerazione per chi si occupa di SEO, è determinante per la scelta mentre per chi è a digiuno di javascript la terza è sicuramente una buona giustificazione. Per chi si occupa invece di accessibilità il quinto punto (ed anche il sesto) sono elementi decisionali fondamentali.
Quindi la scelta è stata ben giustificata a mio avviso!

CSS si… Ma come?

A questo punto ho dovuto pensare quale elemento consentiva di gestire su tutti i browser l’evento mouse over da CSS: la scelta è ricaduta sull’elemento A.
Si perché è l’unico elemento che viene gestito su tutti i browser allo stesso modo (o quasi) e che quindi supporta una serie di “behavior”.

Nel nostro caso dobbiamo gestire sia il mouse over (che deve mostrare l’informazione) che il mouse out (che deve nascondere nuovamente l’informazione).

L’informazione quindi sarà visualizzata quando passiamo col mouse sul link (a:hover) e dovrà scomparire quando non ci siamo più su (a:link o semplicemente a).
A questo punto giocando sulla gerarchia degli elementi in XHTML e l’assengazione di attributi ad elementi tramite classi CSS, ho ben pensato di creare un elemento SPAN (ma poteva essere anche un DIV) all’interno del tag A.

Soluzione per Internet Explorer 7

Mentre su Internet Explorer 6 sapevo che non avrebbe funzionato come tooltip a comparsa (ci sono centinaia di articoli su internet che lo confermano),
su Internet Explorer 7 ero convinto che una soluzione si poteva trovare.
Il CSS iniziale che avevo progettato era il seguente:

a{
        text-decoration: none;
        color: #808080;

}

a span.tooltip{
        color: #404040;
        border: 1px solid #808080;
        background-color: #fffff0;
        font-family: verdana;
        font-size: 12px;
}

a.tooltip>span.tooltip{
        display: none;
}

a.tooltip:hover>span.tooltip{
        position: absolute;
        display: block;
        margin-left: 10px;
        margin-top: 5px;
        padding-left: 3px;
        line-height: 20px;
        width: 200px;
        height: 100px;
}

span.tooltip>span.titolo{
        margin-left: -3px;
        display: block;
        background-color: #404040 !important;
        color:  #fffff0 !important;
}

E sapevo per certo che la gerarchia trattata tramite il “>” non era in nessun modo valutata da Internet Explorer 6. Ma sulla versione 7? Allo stesso modo non viene valutata.

Faccio una prova: Provo a togliere il “>” e…Magia!!! Su Internet Explorer 7 i tooltips funzionano, e funzionano anche su Firefox e su Netscape e su Opera!!!

Provo ad acecderea lla pagina con Internet Explorer 6 (sotto suggerimento di un amico) e…. Al passaggio del mouse sul link il browser mi va in crash!

Allora ho pensato. Se così funziona per tutti tranne che per Internet Explorer 6 devo sfruttare quello che la Microsoft ha previsto: i commenti condizionali!

Ma in che modo?

Ritorno alla versione precedente del CSS (che è quello che leggete sopra) che sapevo che non faceva andare in crash Internet Explorer 6 e poi lavoro sui commenti condizionali creando una soluzione adatta solo ad Internet Explorer 7 che in tal caso era l’unico a non funzionare.

Quindi accodo a quanto avevo fatto il seguente CSS:

<!--[if IE 7]>
<style type="text/css">
a.tooltip span.tooltip{
         display: none;
}

a.tooltip:hover span.tooltip{
        position: absolute;
        display: block;
        border: 1px solid #808080;
        background-color: #fffff0;
        width: 200px;
        height: 200px;
        padding-left: 3px;
}
</style>
<![endif]-->

Formalizzando il tutto

Questo semplice script che ho sviluppato ci consente di avere dei tooltip che funzionano su Firefox, Netscape, Opera, Mozilla, Internet Explorer 7 e con qualche accorgimento anche su Internet Explorer 6, sono particolarmente accessibili in quanto non mi obbligano ad utilizzare javascript.

Questa soluzione ovviamente può essere estesa con degli script in modo da ottenere una degradabilità del tooltip ove non fosse abilitato javascript e una migliore presentazione all’utente finale qualora javascript fosse disponibile ed abilitato.