Line Height

Premessa per gli affezionati: Ultimamente, a causa dei lavori in corso sulla nuova nuova versione di LineHeight, non ho più molto tempo da dedicare alla stesura di nuovi articoli. Proprio per questo motivo, finchè la nuova versione non sarà pronta, userò questo spazio con meno frequenza, pubblicando occasionalmente riflessioni varie ed eventuali, ma mai prolisse. Saranno messaggi relativamente brevi, più diretti, meno impegnativi. Questo mi aiuterà a tenere determinati ritmi senza lasciare questo pseudo-blog al suo triste destino.

Come forse qualcuno di voi saprà, Michele Diodati e alcuni suoi collaboratori stanno portando online tutto il libro Accessibilità, Guida completa (libro che consiglio a tutti di acquistare). Il Capitolo 18, fra i tanti, recita:

Cap.18 - Fornire chiari meccanismi di navigazione

Mai più “clicca qui”! Mappe ragionate. L’attributo title. Gli elementi TITLE, ADDRESS, META. RDF, ontologie e Web semantico. Mappare e descrivere i contenuti. Meccanismi di navigazione. Saltare i contenuti ripetitivi. Funzioni di ricerca scalabili. La lettura per “sfioramento”. L’elemento LINK. Rendere accessibile l’arte ASCII

L'elemento LINK in particolare è estremamente importare per arricchire il contenuto semantico di una pagina, così come recitano le specifiche. Opera e SeaMonkey allo stato attuale già dispongono di meccanismi per usufruire di questi contenuti, aggiungendo un'ulteriore barra di navigazione che permette di esplorare le pagine web compatibili così come facciamo quotidianamente con un esploratore di file. I restanti, fra cui Firefox, sono invece ancora un passo indietro.

A questo punto la domanda sorge spontanea: Come riempire il gap? Io ho una proposta: aiutare Firefox ad essere più semantico tramite l'utilizzo (o la creazione) di estensioni. A tal proposito segue una lista di alcuni add-on interessanti che ho trovato:

• Link Widgets

  Facilita la navigazione all'interno di sequenze di pagine (es. specifiche tecniche come quelle W3C o webcomic) fornendo una pulsantiera per saltare direttamente alla prima, ultima, precedente, successiva, superiore o principale pagina del sito navigato.

• Tails Export

  Permette di visualizzare ed esportare eventuali microformati presenti nella pagina.

• Operator

  Opera su microformati ed altri dati semantici già presenti nella pagina per fornire nuoti metodi di interazione coi servizi web già esistenti.

Avete altre idee o già una certa esperienza nella creazione di estensioni? Se volete partecipare a del buon, sano brainstorming, non vi resta che farvi avanti.

Nelle specifiche W3C dei CSS(Cascading Style Sheets) 2.1 è presente un'intera sezione dedicata ai fogli di stile uditivi. Non mi sono ancora imbattuto nella relativa appendice presente nel working draft del consorzio, ma qualche giorno fa è stato pubblicato un interessante articolo di Nicola Convertini relativo a questo argomento, ovviamente made in HTML.it.

Studi recenti stimano in 11 milioni gli statunitensi con problemi di vista di cui 1,5 milioni sono ciechi.

L'articolo inizia con l'introdurre il ruolo degli screen readers, e l'avvento di nuovi dispositivi di rendering. Dopodichè, inizia l'elenco delle proprietà specifiche.

I contenuti sono sicuramente molto esaustivi, nonostante trovi alcune definizioni ancora abbastanza oscure. Ciò che più mi ha colpito di questo piccolo "saggio" è senza dubbio la vastità di parametri offerti per personalizzare la voce del lettore elettronico: stress, frequenza, velocità e molto altro ancora. E' stato anche studiato un metodo per offrire all'utente un ascolto tridimensionale, basato sulla sorgente della voce.

Alcuni attributi non sono ancora pienamente supportati dalle applicazioni destinate alla sintesi vocale dei contenuti, anche se ammetto di aver "fantasticato" molto sull'utilizzo dell'attributo speech/aural. Sarebbe interessante, infatti, poter analizzare del codice scritto esclusivamente per la lettura di un testo teatrale, di una poesia, o di una favola (dove certo non mancano molteplici intonazioni e timbri di voce) e osservare come variano le proprietà e i valori del parlato in base a frasi, interi periodi o persino generi (mettiamo a confronto, per esempio, un racconto dell'orrore con una filastrocca).

I CSS(Cascading Style Sheets) uditivi rientrano in un campo abbastanza inesplorato e pieno di ostacoli (sebbene nell'ambito dell'accessibilità siano stati compiuti grandi passi), ma senza dubbio offriranno ad una buona percentuale di navigatori un motivo in più per usufruire dell'immensa quantità di informazioni e di contenuti che attualmente internet può già vantare.

L'affermazione può sembrare bizzarra. Eppure il messaggio di Derek Featherstone su 24 Ways.org, nell'ambito dell'accessibilità, è molto chiaro: è un metodo (a quanto pare) comune quello di inserire immagini tramite CSS(Cascading Style Sheets), per abbellire gli elementi delle nostre pagine web; ciò non è sbagliato, ma a volte può portare "fuori strada".

Le immagini, come molti sanno, dispongono dell'attributo alt (e longdesc, teoricamente più esplicativo) per fornire un contenuto alternativo ad applicazioni come gli screen readers. Lavorando tramite fogli di stile, questo discorso ovviamente non è più valido, e l'immagine non diventa nient'altro che una semplice decorazione nata per fini esclusivamente estetici.

Non vi svelo altro, buona lettura!

GrayBit è un ottimo strumento per verificare la visibilità ed il contrasto delle nostre pagine. La particolarità dello script sta nella possibilità di mostrarci una pagina in scala di grigio, eliminando quindi ogni tipo di effetto dato dai colori. Il risultato è sicuramente più "piatto" rispetto all'originale, ma è anche vero che ciò ci permette di immaginare, seppur minimamente, come quella determinata pagina viene consultata da chi ha problemi di vista (come il daltonismo).

Riferimento WCAG(Web Content Accessibility Guidelines) ai colori.

Grazie a Edit, blog di HTML.it per la segnalazione.

Eric Meyer ci rassicura: non esiste layout, scelta, o tecnica che regga. Realizzare una pagina accessibile a tutti, consultabile su ogni supporto, o in grado di adattarsi alle variabili portate dai nostri visitatori (risoluzione, browser, ecc...) è semplicemente impossibile.

La visione di questo nuovo Web che Eric ci trasmette tramite il suo articolo Making Popular Layout Decisions non è certo delle migliori, ma come lui stesso specifica, non dobbiamo farcene una colpa.

Every time you make a layout decision - fluid vs fixed, scaled vs percentage, a few more people hate you. How do you make the right decisions and when?

Personalmente ho sempre pensato che con un pò di Javascript fosse possibile "mettere una toppa" a certi stupidi problemi di rendering che affiorano quando si realizza un documento destinato alla consultazione via browser. Il nodo cruciale di questo ragionamento è proprio il browser: basta aprire gli occhi per rendersi conto dell'esistenza di tanti altri supporti per la navigazione in internet. Ed il Web (o meglio, il settore del Webdesign), così come adesso è strutturato, non è in grado di controllare questo boom ([...] has come a long way, but it’s still an immature field.).

Un articolo interessante ed ironico, che non rivela alcuna soluzione, ma fa riflettere molto sull'argomento. Poi, è chiaro, siamo noi a dover decidere.

Nel mio precedente articolo sull'accessibilità ho criticato molto quei siti che non adottano minimamente tecniche di accessibilità ed usabilità, che ritengo essenziali per una buona navigazione, lettura e visualizzazione dei contenuti da parte di tutti.

E' anche vero che realizzare un sito accessibile non è facile, così come viene spiegato nell'articolo 7 errori in tema di accessibilità nella sezione Webdesign di HTML.it: in particolare, la "comunicazione" fra sviluppatore e cliente, che hanno maniere differenti di pensare, risulta ostacolata e complicata da molti fattori. Questo porta ad alcuni problemi, ed inevitabilmente a trascurare quelle metodologie relative alla realizzazione di un sito accessibile.

E' un aspetto in cui non mi ero mai imbattuto, sebbene mi abbia notevolmente incuriosito. Buona lettura!