Newsgroup: it.lavoro.professioni.webmaster
Titolo: Sito per ipovedenti

Ragazzi... ho bisogno di una mano...
Mi sono giunte diverse email di persone ipovedenti... dicendo che la lettura
di un mio sito risulta difficile... io vorrei fare qualcosa.. ma cosa?...
Qualcuno sa qualcosa...
grazie
--
bismark
---
Outgoing mail is certified Virus Free.
Checked by NAV anti-virus system

 Qualcuno sa qualcosa...
heee... è giunta l'ora dell'accessibilità;)
dai un'occhiata alla web Content Accessibility Guidelines del w3c all'url:
http://www.w3.org/WAI/Resources/#gl
 in genere conviene fare buon uso dei fogli di stile (ed in qsto
Marco/bazzmann è il migliore in circolazione) e controllare la
linearizzazione delle tabelle...
per fare le prove sulle lienarizzazioni, prova a vedere con tablin, sw che
trovi sempre sul sito del w3c.
per navigare come un ipovedente puoi scaricare uno screenreader (jaws o lo
screenreader della IBM) e fare delle prove di navigazione.
per fare un test rapido e general generico sullo stato di accessibilità del
sito (giusto per averne un'idea di massima), usa bobby per verificare
l'accessibilità di ciascuna pagina 
www.cast.org/bobby
.
poi ci sono le risorse sull'accessbilità, come 
bazzmann.com
,
webaccessibile.org
 e altri siti.
questo in breve ed al volo, se serve altro, chi9edi e ti sarà rispoto;)
pat

 pat
Ti ringrazio...
Ho dato una letta... non e' semplcissimo uff....
Ho provato a verificare l'accessibilita' di alcuni siti istituzionali
(libero,virgilio)... i risultati non sono dei migliori....
Vediamo che riesco a fare....
^_^
--
--
bismark
admin c
www.bismark.it
  # IL primo Portale Security Italiano
.---


 Vediamo che riesco a fare....
se posso dare una mano, chiedi anche in privato, senza problemi, mi fa
davvero piacere aiutare ad avvicinarsi a qsta materia all'apparenza ostica
chi come te ci è arrivato per caso e vuole approfondire;)
ah, altro suggerimento: iscriviti alla ML Humana che trovi su 
bazzmann.com
,
è la community di riferimento per qste cose:)
Buon lavoro:)
Pat

 Ho dato una letta... non e' semplcissimo uff....
ecco .. ne approfitto anche io.
Ma cavolo!!! I documenti del W3c non sono un esempio di chiarezza ... 
moolto arzigogolati ... lunghissimi ...
Non potrebbero renderli più comprensibili anche ai poveri 
webmaster/contadini come me?
Cla
-- 
www.claudioerba.com
 - Consulenza web per l'azienda
www.spaghettibrain.com
 - PHPNUke Italian Mirror (Da oggi anche Hosting!)
www.spaghettilearning.com
 - Piattaforma open Source per l'E-Learning
My ICQ: 14187053
--


concordo, leggerli e capirli richiede più tempo :(
ma io posso fare poco, ditelo al ns Mr presidente universale che ha le mani
inpasta nel w3c, mr scano che sonoc erto non mancherà di darvi ragguagli;)
io al massimo mi offro come "piccola guida umana" per rapide questioni;)
pat

 l'accessibilità di ciascuna pagina 
www.cast.org/bobby
.
Nonostante il mio primo sito, qualche annetto fa, fu validato
sia dal W3C sia da Bobby (mi chiedo perché non l'ho più fatto
da allora), il tema della "linearizzazione" mi è pressocché
sconosciuto. So di cosa si tratta ma non so come va affrontato
dal punto di vista tecnico.
Approfitto della tua disponibilità e chiedo: in quali casi
(casi tecnici, intendo) una tabella può generare risultati
non-lineari? E in quali casi vengono generati risultati
lineari in presenza di molte tabelle, magari pesantemente
nidificate,usate per il layout della pagina?
Grazie in anticipo.
Ciao!
--
Guida al posizionamento dei siti sui motori - 
http://www.motoricerca.info/

 nidificate,usate per il layout della pagina?
mai;)
prova con tablin che linearizza, aspe che ti prendo l'url per
scaricarlo...
www.w3.org/WAI/References/Tablin/
spero di essere stata chiara, e cmq sono a disposizione;)
Pat
ps. oggi giornata fiacca in ufficio ... si vede eh?;)

 inpasta nel w3c, mr scano che sonoc erto non mancherą di darvi ragguagli;)
Qui bisogna scendere nel "volontariato" che richiede il W3C per la
traduzione delle raccomandazioni.
All'interno del W3C si sta sviluppando un gruppo, QA (Quality Assurance) che
si occupa anche di rendere + comprensibili le raccomandazioni... ad esempio
i tips del validatore nascono da li :-)

 layout a favore dei css.
Allora dubito che i CSS offrano grandi vantaggi

 Allora dubito che i CSS offrano grandi vantaggi
Ops... post partito incompleto:
... nel senso che se lo screenreader legge il testo *sullo schermo*
(invece che analizzare il sorgente) riga per riga, che sia incolonnato
con le tabelle o con i CSS, non dovrebbe fare differenza, no?  

 Qualcuno sa qualcosa...
Generalmente devi impostare i font con una misura relativa, in questo
modo le persone possono ingrandire a piacimento la misura, rendendo
la lettura più agevole.
Per fare cio', però, devi essere sicuro che il tuo layout sia flessibile
e fluido, che si adatti alle varie necessità, almeno al meglio di quanto
oggi puoi offrire.
Infatti, se qualcuno aumenta la misura dei font nel tuo sito, può
accadere che i contenuti, le immagini, il layout stesso venga
"sballato".
Nel caso tutto questo sia già previsto e le persone che ti hanno scritto
non lo sapessero, prova ad informarli dell'opzione per ingrandire i
testi che tutti i browser oggi offrono, da IE a Mozilla, da Netscape a
Opera.
Spero di esserti stato utile...  :)
Bai!
Marco
-- 
Bazzmann Labs(c) - Accessibilita', usabilita', webdesign e standard W3C
::--------------------------------::---------------------------------::
http://www.bazzmann.it
      | Il sito ufficiale di Bazzmann Labs.
http://www.bazzmann.com
     | La risorsa per informare e aggiornare.
http://www.dev2dev.it
       | Elemento D2D002

 ps. oggi giornata fiacca in ufficio ... si vede eh?;)
Non ci ho fatto caso, quando non dormo da più di 48 ore ho
difficoltà a notare i particolari, specie quelli temporali.  :-) 



i testi sono sempre lineari... non possiamo leggere un libro partendo dalla
155 riga della 7 pagina (a meno che non lo leggimao per capitoli, ma è un
caso estremo).
ma se i testi vengono attorcigliati divisi e spezzettati in un puzzle enorme
(tabelle annidate) è difficile trovare e mettere insieme tutti i pezzi in
modo rapido ed intuitivo.
se invece usiamo delle pagine numerate per far capire la logica dei
contenuti, ricomporre i contenuti ldel testo sarà più semplice.
ecco: i css sono pagine numerate, le tabelle complesse fanno dei ns
contenuti puzzle scomposti e caotici.
sono stataa chiara>?;)
Pat
Pat

 Allora dubito che i CSS offrano grandi vantaggi
nulla vale più dell'esperienza diretta;)
come si diceva in una vecchia pubblicità: provare per credere;)
Pat

 testo tra <TD></TD> dovrebbe?
Alle spiegazioni di Patrizia aggiungo solo un paio di cose:
Le tabelle sono nate e servono per gestire dati di informazioni,
come nel normale uso delle tabelle (anche su Word, per esempio).
Il problema è nato quando i browser non supportavano correttamente
i fogli di stile e, per creare design complessi, si è dovuto far
ricorso all'uso delle tabelle come struttura grafica.
Da questo concetto, visto l'attuale migliore supporto del markup
e dei fogli di stile, è giusto riportare l'attenzione sulla divisione
strutturale e di layout dei siti.
Sebbene ci sia ancora notevole confusione nei lettori alternativi (pure
loro non supportano a pieno le specifiche), un sito complesso fatto con
tabelle e lo stesso prodotto con fogli di stile non sono eguali come
vantaggi.
Un sito con tabelle annidate offre un maggior peso di pagina che viene
ricaricato di volta in volta, bisogna attendere il completamento della
tabella perchè venga visualizzato il contenuto, per modificare il layout
si deve rivedere l'intera struttura, e altre cose in cui non mi dilungo.
Adottare i CSS e i vari "blocchi" con DIV e SPAN offre molti vantaggi
sia dal punto di vista strutturale che produttivo. Permette una lettura
più ordinata da parte di tutti i browser alternativi compatibili con
le specifiche W3C, non solo vocali e screenreader, permette una maggiore
"maneggevolezza" pratica e produttiva del sito stesso (agendo quasi
esclusivamente sul solo foglio di stile) e fornisce un contenuto già
linearizzato.
Unico neo per gli screenreader che leggono esattamente quello che vedono
a video, la cui soluzione non è ancora stata raggiunta pienamente.
Spero di aver contribuito alla spiegazione... :)


 per mac esiste solo spokentalk, prodotto svedese.
O ha cambiato nome, o ne esiste anche un altro, OutSpoken.

 O ha cambiato nome, o ne esiste anche un altro, OutSpoken.
hai ragione, sorry;)
gaffes mia
Pat

 Alle spiegazioni di Patrizia aggiungo solo un paio di cose:
Innanzitutto grazie per la lunga spiegazione.  :-)
Tuttavia, conosco bene le differenze concettuali tra tabelle e uso
dei CSS (non sono del tutto d'accordo con te quando affermi che le
tabelle impongono la completa ricezione del codice HTML, per essere
visualizzate, ma questo è secondario ;-).
Il mio dubbio era un altro, esclusivamente tecnico, e mi accorgo
di essere stato troppo generico nella mia domanda.
Rimedio subito:
Un software per non vedenti, che difficoltà può incontrare nello
interpretare il testo tra due <TD></TD> rispetto al testo tra due
<DIV></DIV>?
Personalmente, se programmassi un software che deve estrarre il
contenuto testuale da una tabella, mi costruirei una gerarchia
di celle, in modo da poter separare chiaramente i contenuti di
una cella da quelli delle celle adiacenti o su livelli di
nidificazione differenti.
Se invece dovessi estrapolare il testo presente tra i
<DIV></DIV>, beh... la routine farebbe esattamente la stessa
cosa!
Quindi mi chiedo: in questo specifico caso, per ricostruire la
linearità del testo, TD o DIV non sono la stessa cosa per
il software di interpretazione/lettura?


 annidata, generando un pò di confusione.
E come si comportano gli screenreader di fronte ai <DIV> nidificati?
Non riesco proprio a capire come possa essere *tecnicamente*
differente per uno screenreader ottenere risultati migliori in
presenza di DIV nidificati invece che TD nidificati.
Grazie molte per la pazienza.  :-)


 <DIV></DIV>?
Credo che il problema sia relativo solo a quei software che si
appoggiano ad un altro browser e leggono il testo che il browser stesso
mostra all'interno della sua finestra.
Esempio:
Due colonne di testo, realizzate utilizzando le tabelle o DIV+CSS
(...)
<tr>
  <td>Questa è<br>la prima colonna</td>
  <td>Questa è<br>la seconda colonna</td>
</tr>
(...)
(...)
  <div>Questa è<br>la prima colonna</div>
  <div>Questa è<br>la seconda colonna</div>
(...)
In entrambi i casi il rendering sara' qualcosa di simile a questo:
  Questa è             Questa è
  la prima colonna     la seconda colonna
Un utente vedente e' in grado di distinguere le due colonne, e a leggere
il testo nella sequenza corretta, grazie ai bianchi di pagina.
Per gli utenti non vedenti direi che esistono diverse possibilita':
a) screen reader che si appoggia a un browser grafico, ed e'
   in grado di accedere al codice HTML
b) screen reader che si appoggia a un browser grafico ma
   *non* e' in grado di accedere al codice HTML
c) screen reader che si appoggia a un browser *non* grafico
   (come lynx) ma e' in grado di accedere al codice HTML
d) screen reader che si appoggia a un browser *non* grafico ma
   *non* e' in grado di accedere al codice HTML
Nei casi b) e d) in effetti si presenta il problema della
'linearizzazione': se lo screen-reader non e' in grado di distinguere
gli elementi HTML, non potra' fare altro che leggere il contenuto della
finestra del browser, da sinistra a destra e dall'alto in basso. 
L'output dell'esempio che ho fatto sarebbe una cosa del genere:
"Questa è Questa è (eventuale pausa) la prima colonna la seconda
colonna"
Nel caso b) il vantaggio nell'uso di DIV+CSS e' dato solo dall'eventuale
possibilita' di disattivare l'uso dei CSS da parte dell'utente. In quel
caso, il contenuto verrebbe presentato su due righe diverse, e letto
nella sequenza corretta:
"Questa è la prima colonna (pausa) Questa è la seconda colonna"
Nel caso d), per quanto riguarda le tabelle usate per il layout, in
genere i browser come lynx mostrano le singole celle su piu' righe,
anche se parte dello stesso TR, quando il contenuto delle celle stesse
eccede la larghezza della finestra, quindi il contenuto verrebbe letto
comunque nella sequenza corretta.
Tra l'altro l'incapacita' dello screen reader di distinguere tra i vari
elementi sarebbe causa di problemi anche per le tabelle che contengono
dati (in caso di celle che contengono testo disposto su piu' righe).
Nei casi a) e c) invece ... beh, se lo screen reader e' in grado di
accedere al codice HTML puo' distinguere le celle e i DIV, e puo'
leggerne *il contenuto* a prescindere dal modo in cui viene 'disegnato'
sullo schermo dal browser.
E allora fara' per i TD la stessa operazione che fa per i DIV, cioe'
leggerli nella sequenza in cui compaiono nel codice.
JAWS, a quanto pare (anche secondo un po' di giri con google), e' in
grado di distinguere tra le singole celle. Nel video 'Screen Readers and
the Web', qui:
http://www.doit.wisc.edu/accessibility/video/index.htm
Si vede come JAWS (a circa 10 minuti dall'inizio del video) sia in grado
di distinguere le singole celle, e leggerne per intero il contenuto.

 mostra all'interno della sua finestra.
[...]
Ti ringrazio molto per l'esaustiva risposta. Erano proprio i
particolari tecnici che cercavo di comprendere.  :-)
