Diodati.org - Accessibilità e traduzioni dal W3C

Il testo ALT fornisce un testo alternativo o sostitutivo, da usarsi quando l'immagine non viene visualizzata. L'errore più comune (a parte il non usarlo affatto) è di fornire una descrizione dell'immagine, senza considerare quale funzione l'immagine stesse svolgendo sulla pagina, il che porta a risultati che spaziano dall'incongruo all'assurdo. Il testo ALT dovrebbe essere composto come un'appropriata alternativa testuale dell'immagine: talvolta questa potrebbe risultare essere una descrizione dell'immagine, ma in pratica sembra che ciò sia sbagliato più frequentemente di quanto non sia corretto.

I consigli qui offerti sono un buon compromesso che funziona in tutti e tre i tipi di situazioni di visualizzazione, con note sulle conseguenze per i differenti tipi. Gli utenti "Tipo I: immagini attivate" non sono discussi in dettaglio: alcuni browser mostreranno il testo ALT mentre attendono il caricamento degli IMG, per cui i testi ALT suggeriti sembrano per lo meno congrui.

	Raccomandazioni per ALT:	Tipo II: quelli che navigano in modalità testo, ma possono visualizzare le immagini se necessario	Tipo III: soltanto modalità testo (ad es. terminali in modalità carattere, lettori per ciechi ecc., e robot di indicizzazione)
a) Decorazioni di pagina	Scrivete ALT="" nella maggior parte dei casi; per i pallini, ALT="*" ecc. Evitate di usare un IMG di una linea fantasiosa con dell'"arte ASCII" come suo testo ALT: meglio usare HR e fornire un'immagine decorativa discrezionale tramite CSS.	È improbabile che il lettore voglia vedere l'immagine. Non usate un testo ALT che sia una descrizione dell'immagine ("Una linea bizzarra", "Motivo di riempimento sinistro", ecc.).	Le decorazioni in "arte ASCII" possono essere intrusive per un browser vocale, perciò usate ALT="" dovunque sia possibile. Non affidate unicamente alla forma dell'immagine o al colore la trasmissione di un contenuto informativo rilevante.
b) Icone di navigazione	ALT="Successivo", "Precedente" ecc. ALT="Prima pagina della Ditta Tizio" ("Vai alla Prima pagina della Ditta Tizio", se dovete, ma non "Indietro a.." o "Ritorna a..").	Pensate ai browser grafici che tagliano o sopprimono la visualizzazione del testo se HEIGHT/WIDTH di IMG hanno valori troppo piccoli.	Giova ad alcuni tipi di lettori se voi potete organizzare il tutto in modo che vi sarà non più di un'àncora per ogni riga mostrata.
c) Accessorie o interessanti	Talvolta una breve descrizione dell'immagine risulta appropriata: più spesso è preferibile specificare che cosa l'immagine era destinata ad illustrare. Potete menzionare la dimensione del file immagine, se ciò è essenziale.	Il testo aiuta il lettore a decidere se desidera (o necessita) di caricare l'immagine.	Non generate frustrazione nel lettore pretendendo che egli debba caricare quest'immagine.
d) Essenziali, critiche per la comprensione	Siate onesti con i vostri lettori, dite loro francamente (ad es. nel testo ALT) che quest'immagine è essenziale per la vostra presentazione. Tuttavia non fatelo a meno che non sia proprio necessario, o i lettori potrebbero trovarsi davanti ad un problema supplementare (i lettori non vedenti nel procurarsi l'aiuto di un amico, per esempio) e poi rimanere delusi (si veda l'annotazione precedente).

Queste raccomandazioni erano in origine antecedenti alla disponibilità di TITLE e LONGDESC nei browser. Alcuni dei precedenti compromessi, nei quali si tentava di usare il testo ALT per una quantità di scopi in concorrenza, possono essere evitati sfruttando quegli attributi per fornire le opportune caratteristiche di accessibilità, lasciando ad ALT di fare il lavoro per il quale era destinato, cioè il testo alternativo.

 Meditazioni e declamazioni varie 

Pensate al testo ALT come ad un'opportunità commerciale, che vi offre uno strumento semplice e di facile applicazione, per mezzo del quale potrete comunicare meglio con una porzione di utenti, che altrimenti potrebbe non afferrare il vostro messaggio. O, come qualcun altro ha osservato: Sul Web, l'accessibilità esiste come parte del progetto - eliminarla rappresenta per voi un costo supplementare. Vediamo davvero troppi esempi di approccio negativo al testo ALT, da parte di autori che sembrano considerarlo soltanto come un'incomprensibile scocciatura per ottenere una monotona conformità formale ad una certa norma legalistica, per la quale non nutrono alcuna simpatia: con un simile atteggiamento non fanno altro che gettare dalla finestra un'opportunità di guadagno ed ottenere la concreta garanzia di conseguire risultati inferiori.

Io non sto pretendendo qui di offrire l'unica e sola risposta corretta ad ogni situazione particolare discussa. In ciascun caso potrà esservi un'intera gamma di soluzioni per convogliare il messaggio desiderato verso qualsivoglia genere di lettore. Potrà del pari esservi un ampio spettro di pretese soluzioni (come visto ripetutamente sul Web) che in modo del tutto non necessario fallisce in una considerevole varietà di situazioni di navigazione: nessuno può ragionevolmente trovare qualcosa da ridire in una situazione in cui la natura del materiale medesimo impedisce che esso sia utilizzabile - quel che invece si sta qui criticando è il rendere ottusamente inaccessibile un materiale che è intrinsecamente accessibile.

Il mio scopo principale è stato quello di portare l'argomento alla luce del sole; di provocare ulteriori discussioni ragionate; e di applicarmi ai molti incomprensibili testi ALT che mi capita di vedere sul Web. Nel fare ciò, spero anche di dimostrare che la più volte ripetuta pretesa - che "sviluppare anche per gli utenti in modalità solo testo ci costerebbe un'irragionevole sforzo supplementare che non siamo in grado di sostenere" - è un errore: tale pretesa sembra plausibile soltanto se non sapete cosa state cercando di dire ai vostri lettori e se avete confuso gli aspetti particolari della presentazione (che comunque non possono essere strettamente controllati scrivendo HTML per il Web) con il contenuto del vostro messaggio.

 Lo stile autoriale 

[Nota 1] A proposito della questione dello stile autoriale, esiste una discussione precedente molto istruttiva nella Guida allo stile per gli ipertesti in linea presso il W3C, con particolare riferimento a Non formattare per un particolare browser ed Evitare di parlare della meccanica.

Dopo tutto, l'autore di un libro normalmente non cerca di spiegare al lettore come leggerlo, con quale luce illuminarlo, come usare l'inserto pieghevole, ecc., a meno che non vi sia una ragione molto speciale per fare ciò. Dovreste partire dal presupposto che quest'ultimo sappia già come fare, o che abbia la libertà di scegliere da solo, non vi sembra? Vi chiederei perciò cortesemente di non trattare con sufficienza i vostri lettori dando per scontato che non sappiano come usare il loro stesso browser.

Mentre è vero che in un'epoca di crescita esplosiva del Web molti lettori possono essere dei novellini e non sentirsi forse ancora pienamente familiari con il loro browser, il vostro articolo sui funghi selvatici non diventerà migliore per essersi trasformato nell'ennesima guida all'uso del browser. Se la vostra pagina richiede qualche requisito particolare, vi consiglierei dunque di menzionare educatamente quale browser possiede caratteristiche tali da soddisfare quei requisiti speciali; ma non dimenticate che i vostri lettori potrebbero non servirsi del medesimo browser/piattaforma che voi adoperate, e se cercate di dir loro come si usa il vostro browser, rischierete davvero di confonderli.

 L'elemento OBJECT 

[Nota 2] Non posso esimermi qui dal menzionare il meglio progettato elemento OBJECT (discendente dal FIG dell'HTML3.0-prima stesura), che offre più flessibili opportunità per comportamenti di ripiego. Tuttavia nell'ambito di questa nota il mio interesse specifico rimane l'uso appropriato dell'elemento IMG. Ed in verità l'uso di OBJECT risulta ancora funestato, con varie versioni di browser, da alcune strane anomalie.

 Perché un lettore dovrebbe usare un browser in modalità testo? 

[Nota 3]  Ovvero: perché io, come autore, dovrei preoccuparmi di ciò?

Vi sono molte possibili ragioni. Se voi, in qualità di autori, presumete di conoscerne il motivo (ad esempio, se assumete che la modalità testo sia usata unicamente da persone che dispongono di un basso reddito, e che perciò non vi interessano), allora con ogni probabilità riuscirete a respingere - e ad irritare -, anche se non ve ne sarete accorti, molte persone che in realtà vi piacerebbe avere come clienti. A parte questo, se state rendendo disponibili delle informazioni testuali, allora quale ragione logica potreste avere per rinchiuderle dentro un impenetrabile ginepraio di materiale solo-grafico?

Uno dei più importanti lettori delle vostre pagine Web è il robot di indicizzazione: che è in effetti cieco e non può comprendere le vostre immagini. Il testo ALT è un eccellente modo di aiutare il robot e di assisterlo nel produrre una corretta indicizzazione delle vostre pagine. Alcuni autori sembrano preferire una grande fatica spesa nel comporre METAtag per gli indicizzatori - un'idea abbastanza ragionevole in se stessa: ma tali informazioni non risultano di solito convenientemente accessibili per i lettori in modalità testo, mentre lo sforzo speso sui vostri testi ALT produrrebbe benefici per entrambi i tipi di "lettore" (attenzione: l'uso oppure no dei testi ALT varia da un sistema di indicizzazione all'altro). Vi è stato un tale abuso nell'utilizzazione dei METAtag da parte di alcuni fornitori di pagine web, che alcuni sistemi di indicizzazione attualmente ignorano del tutto i META oppure applicano rigide regole di esclusione, per evitare di essere tratti in inganno da un tale genere di trucco. Con le centinaia di milioni di indirizzi oggi presenti sul Web, avete bisogno davvero anche del più piccolo aiuto da parte di quegli indicizzatori, per avere una possibilità in più di raggiungere dei lettori che siano specificamente interessati a ciò che voi avete da offrir loro. Questi sono i vostri visitatori "di qualità", ognuno di essi ben più degno della vostra considerazione di un esercito di lettori inciampati per caso nella vostra URL durante una qualsiasi "navigazione".

Cibo per il pensiero

1. Il telefono cellulare digitale è oggi d'uso comune. Sempre più spesso questi cellulari vengono equipaggiati con prese per dati digitali, alle quali può essere collegata una più elaborata unità video, ad esempio un portatile o un palmare, sia per visualizzare messaggi SMS sia per una completa connessione digitale ad un Internet provider, ecc. Tuttavia, la velocità di connessione ottenibile è piuttosto limitata, se comparata con un telefono a fili. (Opinione personale: non credo che WAP sia la risposta. C'è un campo di applicazione in cui WAP è chiaramente utile: ma esso fa sorgere almeno tanti problemi quanti ne risolve e presenta il rischio di causare un'ulteriore frammentazione.)

2. In the Hitchhiker's Guide to the Galaxy [= "Guida della Galassia per autostoppisti"] di Douglas Adams, Il Libro è descritto come una maneggevole periferica dotata di un'unità video di circa quattro pollici quadrati, in grado di visualizzare un milione di singole pagine informative. È chiaro che Il Libro è concepito come un sistema indipendente, come sarebbe appropriato per il viaggiatore intergalattico. Qui, nel mondo reale, abbiamo palmari (ad es. Psion, Newton, Palm, ecc.) e telefoni con browser integrati quali il Nokia serie 9000. Date uno sguardo per esempio ad On-line with your Psion presso il sito 3-Lib di Steve Litchfield. Qualcosa, quindi, di abbastanza simile ad Il Libro, ma che dà accesso non semplicemente ad un milione di pagine informative archiviate al suo interno, bensì all'enorme numero di documenti presenti sul Web.

Il supporto per un servizio di accesso a banda larga senza fili su vaste aree di ciascuna nazione sembra ancora molto lontano, a dispetto dei tentativi di potenziare la banda disponibile in zone limitate.

Un cenno va fatto anche per i Wearable computers [= "computer indossabili"].

3. Il sintetizzatore vocale - non soltanto per il non vedente. Ci sono volte in cui è piacevole riposare gli occhi oppure volte in cui questi sono concentrati su qualcos'altro.

4. Alcuni scettici sui gruppi Usenet del Web, quando viene suggerita una periferica di presentazione insolita o futuristica, sembrano credere di poter conseguire un guadagno con l'escludere deliberatamente tali periferiche inusuali, piuttosto che con lo sfruttare le potenzialità dell'HTML di rendere fruibili le proprie informazioni in qualsiasi situazione di navigazione del lettore. Non considerando affatto la pratica (f)utilità di un simile approccio, ciò dimostra vedute meschine e ristrette, indegne degli alti principi del Web. Perché "sviluppare per" una ristretta situazione di lettura, quando l'HTML dispone di una varietà tale di opzioni da consentirvi di "sviluppare per" qualsiasi situazione di lettura? La più volte ripetuta locuzione circa il "pubblico di riferimento" allude espressamente alle persone a cui è rivolto il vostro "argomento del discorso": applicare ancora un altro livello di selezione a seconda della loro situazione di navigazione (eccetto laddove il contenuto, per la sua natura intrinseca, lo richieda) sembra essere un fraintendimento di ciò che s'intende con "pubblico di riferimento" o con "lettori di riferimento".

Persino lo 0,01% di utenti Internet rappresenta ancora una cifra significativa, specialmente se si tratta per caso proprio di quelle persone che hanno interesse per il vostro prodotto: come potete essere certi che non sia così? È stato detto in modo veritiero che molte pagine Web sono state ottimizzate per litigare con i clienti, e le cose sembrano peggiorare, non certo migliorare.

Alcuni particolari

In ogni caso, ecco qui il mio elenco, molto incompleto, di ragioni per cui i lettori potrebbero decidere di usare un browser solo testuale o un browser grafico con il caricamento delle immagini disabilitato.

• Una risposta di rete scadente vuol dire che essi non sono disposti ad attendere il caricamento delle immagini, specialmente se sospettano che l'autore le abbia incluse soltanto come decorazioni non necessarie
• Si trovano fuori sede, stanno usando un portatile o un palmare ed un modem connesso alla linea telefonica; la loro unità video può essere inadatta per le immagini, senza considerare affatto la velocità del modem.
• Palmari e telefoni cellulari digitali. La banda disponibile è strettamente limitata e i costi di chiamata sono alti. Vi sono persone con reddito adeguato, ma in questa situazione non hanno tempo da perdere con le immagini.
• Un panfilo oceanico con collegamento satellitare... (ehi, un rischio per il mio stipendio!)
• I lettori già sanno che le informazioni che desiderano sono intrinsecamente testuali e non vogliono, neppure con una rete ad alta velocità, caricare immagini di cui sanno di non aver bisogno. Questi sono lettori da prendere sul serio, gente. Come potete sapere che essi non vogliano comprare i vostri prodotti?
• Lettori non vedenti (che usano ad es. un browser in modalità testo connesso ad un sintetizzatore vocale o un browser Web vocale appositamente progettato come pwWebSpeak).
• Lettori a cui piace la velocità e la copertura dell'HTML offerti da Lynx o da emacs-w3.
• Gruppi a basso reddito che usano attrezzature di scarto. Paesi del "Terzo Mondo" con inadeguate infrastrutture per le telecomunicazioni (si veda Un sogno di Abigail...).
• Si dispone in ufficio di stazioni di lavoro al vertice delle prestazioni - ma si tiene in auto un portatile di quart'ordine per accessi occasionali mentre si è fuori sede o in giro.
• Sono sicuro che esistono molte ragioni in più che non mi sono venute in mente.
• Non dimenticando quei robot di indicizzazione...

E allora, voi autori intelligenti che dite che non vale la pena di preoccuparsi dei lettori in modalità testo: c'era un solo elemento in comune tra tutte queste categorie di utenti, a parte il fatto di usare la modalità testo (o per scelta o per necessità)? Personalmente ritengo che non ce ne fosse alcuno. Soltanto perché credete di conoscere il "profilo" del vostro pubblico di riferimento, non significa che tutti indistintamente si riconosceranno in quel profilo né che lo faranno per tutto il tempo. Quando mettete della pubblicità sulla rivista sbagliata, state semplicemente perdendo un certo numero di potenziali clienti: nessun danno attivo è prodotto. Quando invece offrite ai lettori sul Web qualcosa che si rivela non leggibile da loro, perché è stata progettata per una gamma ristretta di piattaforme, voi siete stati attivamente scortesi verso dei potenziali clienti. Vi basta contrariarli una volta soltanto per mandarli dai vostri concorrenti. Un solo cliente scontento può generare una quantità di pubblicità negativa e farvi perdere altri potenziali clienti.

 Lettori non vedenti 

[Nota 4] Devo confessare di avere un'esperienza diretta piuttosto limitata del tipo di problemi incontrati sul Web dai lettori privi di vista, benché io tenti di coltivare un intelligente interesse in proposito. Tali problemi rappresentano un argomento caldo per l'area dedicata alla Web Accessibility Initiative presso il W3C.

Francamente molte delle pagine che vedo sul Web sono così ovviamente bisognose di un grado di cura e attenzione, che ciò aiuterebbe tutti i lettori in modalità testo; ed ho ricevuto troppo spesso, da parte di autori indisponenti, risposte che rifiutavano di mostrare la benché minima considerazione per quello che pareva loro essere uno sparuto gruppo di minoranza; per tali motivi mi sono andato concentrando su tecniche che sembrano essere benefiche per tutti i lettori in modalità testo, e implicitamente anche per i lettori ciechi così come per i robot di indicizzazione, piuttosto che tentare di convincere codesti scettici ad evitare di spendere tempo e fatica in tecniche che danneggiano la fondamentale accessibilità, insita nelle caratteristiche progettuali del World Wide Web. Spero che le mie intenzioni nel battere questa via non siano fraintese: va il mio plauso a quegli autori che sarebbero disponibili ad investire del tempo supplementare per rendere vieppiù accessibili i propri documenti, e che sono desiderosi di seguire appropriate linee guide.

Notate che nell'HTML4.0 vi sono tre o quattro attributi disponibili per i loro rispettivi scopi (sto parafrasando le raccomandazioni HTML4.0):

• L'attributo ALT di IMG, per il testo alternativo,
• L'attributo TITLE di IMG, per informazioni supplementari significative per l'IMG,
• L'attributo LONGDESC di IMG, per l'URL di una completa descrizione testuale dell'immagine,
• L'attributo TITLE della circondante ancora A di collegamento, se ve n'è una, per informazioni supplementari significative sul collegamento.

Come utilizzare al meglio questi meccanismi è ancora sotto attiva discussione per quanto riguarda i dettagli, ma possiamo constatare che in generale c'è ora sempre meno ragione di usare l'attributo ALT per mere descrizioni dell'immagine.

Per i browser più datati, il precursore dell'attributo LONGDESC è il collegamento-D, il cui uso pionieristico si deve al WGBH.

 Il colore dei testi ALT 

[Nota 5] Ho ricevuto un'interessante e-mail da parte di qualcuno che stava cercando, senza successo, di usare FONT COLOR per ottenere che i propri testi ALT contrastassero adeguatamente contro uno sfondo piuttosto scuro.

In base alla mia esperienza il testo ALT viene mostrato con il medesimo colore specificato nell'attributo TEXT dell'elemento BODY, o in alcuni browser, se l'immagine è un collegamento, allora esso userà, a seconda del caso, i colori di LINK o di VLINK.

FONT COLOR è pericoloso comunque in Netscape (4.* o precedenti), perché non può essere disabilitato scegliendo l'opzione "usa i miei colori". Così il lettore che si trova in una situazione di navigazione difficile e sta cercando di rendere le cose migliori tramite un controllo sui colori stessi, si ritroverà con il FONT COLOR scelto dall'autore, visualizzato contro lo sfondo scelto dal lettore. In alcuni casi ciò rende il testo completamente invisibile. Questo problema è discusso più approfonditamente nel magniloquente articolo di Warren Steel su FONT.

MSIE ed Opera non sono afflitti da questo baco: quando sono impostati per usare lo schema cromatico del lettore, questo sovrascrive FONT COLOR come pure gli altri attributi di colore.

A causa di questo problema con le versioni di Netscape, raccomanderei di evitare FONT COLOR ogni volta che sia possibile. Fin da ora dovrebbe essere sufficiente usare i CSS per proporre presentazioni distintive del testo, basate sul colore ed altre proprietà, per aumentare le probabilità che il testo modificato venga mostrato distintamente in un'ampia gamma di situazioni di navigazione, e tuttavia in modi che siano meno nocivi quanto a richieste di accesso specializzato.

L'uso degli attributi di colore dell'elemento BODY è, al confronto, innocuo, dal momento che i browser possono sovrascriverli quando il lettore lo ritiene necessario. Naturalmente, se adoperate un'immagine di sfondo, occorre allora che il suo colore si armonizzi con il vostro attributo BGCOLOR.

Raccomandai al mio corrispondente di impostare i colori di base prescelti per la sua pagina unicamente tramite gli attributi di BODY. Secondo la mia esperienza, ciò dà buoni risultati con i testi ALT su una buona varietà di browser.

 Testi ALT a comparsa: una risposta critica 

[Nota 6] In frequenti occasioni s'incontrano autori che suppongono evidentemente che l'intero scopo dei testi ALT consista nel servire da messaggi a comparsa, quando il lettore passa il proprio mouse su un'immagine. Questo ed altri fraintendimenti risultano manifesti nella seguente corrispondenza, che cito qui con le mie risposte, nella speranza di prevenire almeno una porzione di future richieste di informazioni su queste righe. Sto impudentemente citando domande prese da quella che era una corrispondenza privata, ma rese anonime in modo da non offendere nessuno.

Molto spesso, quando costruisco un sito web, sono costretto ad usare un'immagine trasparente per forzare il browser a visualizzare correttamente la spaziatura desiderata.

Devo dirti sinceramente che non mi piace questa terminologia. Sul Web, l'uso di "forzare" è spesso infruttuoso, e non sta scritto da nessuna parte che tu debba usare immagini trasparenti oppure forzare un browser a mostrare una certa spaziatura desiderata. Non c'è nulla di sbagliato nel costruire una pagina web che abbia l'aspetto che tu vuoi che abbia nella situazione di visualizzazione che hai in mente; ma è meglio, secondo il mio modo di pensare, se il tuo HTML (e CSS) è anche sufficientemente flessibile da permettere che la pagina si adatti in modo omogeneo, senza scompigli, ad un'ampia varietà di situazioni di visualizzazione nelle quali potrebbe venire a trovarsi.

Non ho mai neppure considerato di mettere un tag ALT su queste immagini, dal momento che nessuno può vederle.

Su un browser testuale la tua asserzione è falsa: il browser testuale non ha idea di cosa l'immagine mostri, se contenga informazioni significative oppure no. L'attributo ALT è lì proprio per questo scopo.

Tuttavia il programma Bobby mette in risalto questo fatto e lo segnala come un problema.

Certamente; conterà anche come un errore di sintassi HTML il fatto che l'obbligatorio attributo ALT sia stato omesso.

Il tuo articolo sembra suggerire che persino queste immagini dovrebbero contenere un testo ALT che ne spieghi lo scopo.

Certamente non "che ne spieghi lo scopo", questo no. L'attributo ALT dovrebbe fornire un testo alternativo, da usarsi in luogo (invece) dell'immagine.

Se l'immagine non svolge alcuna funzione dal punto di vista del contenuto, allora anche il testo alternativo andrebbe lasciato vuoto. Alcune versioni delle linee guida sull'accessibilità vorrebbero che tu mettessi lì un qualche separatore non vuoto, probabilmente una barra verticale.

Per me, sembrerebbe più seccante che utile il veder comparire la descrizione di un separatore ogni volta che un mouse viene tenuto sopra quella parte dello schermo.

Stai descrivendo quello che attualmente è sempre più riconosciuto come un baco dei browser. L'attributo ALT era ed è inteso come un funzionale rimpiazzo testuale dell'immagine, quando - per una qualsiasi ragione - l'immagine non viene visualizzata. Mostrarlo ugualmente quando l'immagine è visualizzata (ad es. come un testo a comparsa) è fuorviante e controproducente.

È disponibile l'attributo facoltativo TITLE per fornire informazioni aggiuntive su una risorsa, ad esempio su un'immagine. È questo il testo adatto ad essere mostrato sotto forma ad es. di messaggio a comparsa. Se vuoi evitare la visualizzazione del testo ALT come messaggio a comparsa, almeno nei browser che onorano questa convenzione, inserisci allora un attributo TITLE vuoto, cioè TITLE="".

Fortunatamente in MSIE, ed in misura crescente in altri browser, l'attributo TITLE ha la priorità riguardo a questo scopo. Netscape 4.*, benché tuttora usato in misura non trascurabile (io stesso lo adopero, insieme con altri browser), è francamente già morto e non dovrebbe essere preso a modello di come progettare correttamente una pagina web.

Cosa dovrei mettere lì allora: "Spaziatore usato per far scorrere il testo verso destra"?

Assolutamente no.

ALT="" , o ALT=" " o forse ALT=" | " insieme con TITLE="", sarebbe la mia raccomandazione, almeno finché non ti persuaderai ad abbandonare questa pratica, di cercare di ottenere un'impaginazione di precisione per mezzo di questo genere di tecniche.

Anche se non hai intenzione di usarlo per te stesso, il browser Lynx può essere un utile strumento, per ricordarsi di come una pagina "appare" (o suona) a certi utenti. E di sicuro ai robot di indicizzazione, il che rappresenta anche una considerazione significativa, o no?

 Demo di ALT su Lynx. Introduzione 

In una quantità di occasioni, quegli autori di HTML che sembrano non avere accesso ad una copia del browser Lynx, hanno segnalato che sarebbe loro di aiuto se potessero comprendere in che modo Lynx utilizza i testi ALT. Sembra una richiesta perfettamente ragionevole, e sarebbe scortese ricordare che se gli autori seguissero le linee guida autoriali che sono consigliate presso il W3C, non sarebbe davvero necessario per loro acquisire familiarità con nessuno specifico browser (;-).

Così ho fatto ciò che potevo, usando alcuni momenti liberi, per soddisfare la loro richiesta. Questo documento dimostrativo richiede che siano visualizzate le immagini in riga in esso contenute (*). Risulterebbe altrimenti incomprensibile. (Di conseguenza devo chiedervi di non considerare questo documento un buon esempio di come scrivere i testi ALT in generale!!). Le immagini che ho usato qui vengono visualizzate in modo eccellente sul mio browser, ma è possibile che appaiono puntinate o che comunque non siano visualizzate in modo ottimale in alcune altre situazioni di navigazione.

Sarebbe opportuno forse ricordare in primo luogo che Lynx lavora all'interno di una finestra di emulazione terminale (o su un terminale vero e proprio - ce n'è ancora qualcuno in giro) e che l'aspetto dei particolari a schermo dipende dalle caratteristiche della finestra di terminale in uso. Tipicamente, tuttavia, tale finestra dovrebbe essere alta almeno 24 righe ed ampia 80 colonne, ed usa un carattere a spaziatura fissa. Tutti gli esempi qui riprodotti sono basati su tale finestra. Un possibile aspetto per una simile finestra è il seguente:

con i seguenti estratti che mostrano il tipo di variazioni che è possibile ottenere con differenti emulazioni di terminale ed impostazioni di configurazione:

Questo è lo stesso emulatore di terminale di prima, ma è stato configurato usando colori differenti. Nient'altro è stato modificato in questo esempio. In entrambi i casi i collegamenti Web sono evidenziati usando un differente colore a schermo.

Questa è una comune emulazione di terminale DECTERM, che utilizza le impostazioni predefinite che ottengo con una caratteristica installazione. Come potete vedere, in questo caso i collegamenti sono segnalati in neretto.

Questa qui proviene da una certa versione di XTERM. Di nuovo è utilizzata l'evidenziazione per segnalare i collegamenti.

Per variare, ecco anche un esempio realizzato con la versione "gergo-colore" di Lynx.

 Demo di ALT su Lynx. La dimostrazione 

Tanto basti per i preliminari. La dimostrazione qui descritta fu ottenuta usando la versione di sviluppo Foteos Macrides di Lynx 2-4-FM, che ottenni nel dicembre '95. (Aggiunto a gennaio 1997) Naturalmente occorre sottolineare che lo sviluppo di Lynx è proseguito rapidamente dopo quella data; per le ultime novità su Lynx non dovreste davvero guardare in questo articolo, ma per lo scopo di tale dimostrazione ciò che vedete qui servirà quanto meno al fine di illustrare i punti significativi della discussione.

Le versioni precedenti di Lynx differiscono per alcuni aspetti: quelle precedenti ad un certo rilascio (chiedo scusa, non sono sicuro di quale fosse esattamente, ma Lynx 2.3 era come questa) mostrerà [IMAGE] invece di [INLINE] o [LINK] come mostrato qui. Pure, Lynx possiede un'ampia gamma di opzioni di configurazione e qui io ne ho esplorato soltanto alcune.

Per informazioni su Lynx il luogo canonico per cominciare è http://lynx.browser.org/.

Caricate liberamente il documento di prova per voi stessi ed osservate il sorgente HTML; le immagini che esso referenzia, tuttavia, non esistono (ciò non fa differenza, fin quando si tratta di dimostrazioni su Lynx). Abbiamo già avuto modo di vedere la finestra di Lynx che usa le impostazioni predefinite del programma - guardiamola di nuovo:

Come potete vedere, i punti da 1 a 4 mostrano l'effetto di omettere l'attributo ALT: la visualizzazione di [INLINE] davvero non ha altro scopo qui che di annoiare il lettore, e la visualizzazione di [LINK] è appena un po' meglio, se l'autore si aspetta di convincere il lettore scettico che c'è qualche informazione utile da ottenere usando questo collegamento, qualsiasi cosa esso possa riservare. (Vi ricordo che molti utenti di Lynx hanno accesso, se lo desiderano, a strumenti per la visualizzazione delle immagini. Ciò che essi non possono fare con Lynx è visualizzare le immagini in riga. Ma un numero signficativo di essi avrà accesso a strumenti per la visualizzazione delle immagini che sono state scaricate, e/o avrà accesso ad un browser grafico quando ne vorrà adoperare uno.) Penso che dovrebbe essere ovvio che, per un'immagine decorativa, il numero 2 è la scelta migliore; si potrebbe discutere se un utente di Lynx possa voler scaricare occasionalmente delle immagini puramente decorative, ma, come vedremo in seguito, Lynx fornisce agli utenti i mezzi per farlo.

Il punto 5 mostra il risultato di specificare un testo ALT vuoto per un'immagine che è un collegamento (cioè si trova all'interno di un'ancora). Ciò sarebbe stupido se l'immagine costituisse l'intera ancora, ma se c'è anche del testo (all'esterno dell'IMG ma all'interno del contenuto dell'ancora) a fungere da collegamento, allora questa potrebbe essere una scelta perfettamente ragionevole. Di nuovo, vedremo più tardi in che modo il lettore può caricare lo stesso elemento INLINE, se desidera farlo.

I punti 3 e 6 mostrano l'effetto di inserire del testo. Come vedete, il lettore che usa Lynx, con simili impostazioni, non ha modo di distinguere se il testo che sta visualizzando è il risultato di un testo ALT piuttosto che di un testo ordinario, ma in entrambi i casi risulta chiaro a schermo se tale testo è parte di un collegamento oppure no. In molte situazioni questa sarà la cosa giusta da considerare. La mia discussione generale sui testi ALT affronta questo problema più in dettaglio.

 Demo di ALT su Lynx. Alcune altre impostazioni disponibili in Lynx 

Vi sono due o tre variazioni di impostazioni che sono degne di essere qui considerate. Dalle impostazioni predefinite, il lettore può impartire il comando da tastiera "*", che applica dei comandi agli oggetti [INLINE] nel modo seguente:

Come potete vedere, il lettore dispone ora di comandi separati sugli oggetti in riga e sui collegamenti, il che gli dà l'opportunità di recuperare qualsiasi cosa egli desideri, anche in quei casi in cui l'autore ha specificato un testo ALT vuoto. Lynx omette il comando [LINK] quando risulta disponibile un testo ALT non vuoto, perché il testo di per sé già svolge bene la funzione di collegamento. Il succo di questa dimostrazione è che l'autore non deve intraprendere nessun passo aggiuntivo per consentire all'utente di Lynx di accedere ad un'immagine in riga oppure ad un collegamento. Il compito dell'autore - e questo si applica a tutti i browser, non soltanto a Lynx - è di capire quali informazioni vuole effettivamente comunicare a quei lettori che stanno usando la modalità solo testo, e inserire poi quelle informazioni nei propri testi ALT. Questa non è davvero quella grande seccatura che molti autori, all'interno del gruppo di autori di HTML, pretendono che sia: la parte difficile è decidere quali informazioni si vogliono comunicare, e questo dovrebbe essere fatto in ogni caso. Una volta che avete deciso cosa desiderate comunicare, scriverlo in HTML è a mio parere un'appendice banale del lavoro autoriale.

La successiva variazione consiste nell'eseguire Lynx in modalità collegamenti numerati. Mi sono detto che questo è il metodo da preferire per i lettori ciechi, poiché essi possono così scegliere un collegamento per mezzo del suo numero, piuttosto che dovendo muovere il cursore su di esso. La parte significativa dello schermo ha dunque un aspetto di questo tipo.

Giusto per completare il quadro, ecco come appare la modalità collegamenti numerati quando impartite il comando da tastiera "*".

Avrete notato che in questa modalità sia alle immagini in riga sia ai collegamenti vengono assegnati propri numeri separati, cosicché l'utente possa richiamarli tramite il numero. Tutto perfettamente logico e consistente.

Come già detto prima, ciò non esaurisce affatto la varietà di trucchi a disposizione del lettore che usa Lynx, ma dovrebbe essere sufficiente a dimostrare che l'utente di Lynx ha i mezzi per fare tutto ciò che possa ragionevolmente desiderare, tranne che visualizzare effettivamente le immagini in riga con il loro testo.

---

(*) Non solo. Occorre anche conoscere un po' d'inglese, perché i testi delle schermate riprodotte sono appunto in inglese.