Newsgroup: it.lavoro.professioni.webmaster
Titolo: -promo: webaccessibile.org

E' online la versione 1.0 del sito...
comunicato ufficiale all'indirizzo:
http://www.webaccessibile.org/argomenti/comunicato.asp?id=5
Siamo in fase RFC :-)
Saluti!
--
Roberto Scano
IWA/HWG EMEA Coordinator
W3C Advisory Commitee Representative for IWA/HWG
International Webmasters Association / HTML Writers Guild
http://www.iwanet.org
 - 
http://www.hwg.org
E-Mail: 
em...@iwanet.org
 - 
w3c...@iwanet.org
--------------------------------------------------------------------

 
http://www.webaccessibile.org/argomenti/comunicato.asp?id=5
Beh complimenti, il codice XHTML e' valido.
Ma la validazione non basta certo (anzi) a costruire un buon documento 
in un linguaggio di markup come l'(X)HTML.
L'uso di STRONG per fare i titoli e' discutibile, a quel punto tanto 
vale usare B. Poi buttati li' cosi' in mezzo ai DIV... si', il documento 
e' valido ugualmente, ma visto che STRONG e' un elemento "in linea", 
sarebbe simpatico almeno almeno metterlo in un P.
I nomi delle classi poi, anche se non ci sono certo 'obblighi' in tal 
senso in (X)HTML o in WAI (IIRC), dovrebbero essere legati a cio' che 
rappresenta l'elemento nella struttura del documento, e dovrebbero 
essere anche comprensibili (soprattutto quando le classi vengono usate 
per sopperire alle limitazioni 'espressive' dell'HTML).
Visto che il finto-titolo che lo precede e' di classe "menutitle", il 
nome "menucontent" o qualcosa del genere e' sicuramente meglio di 
"ylwboxdashed" (e almeno in Mozilla il box ha un bordo solido e non 
tratteggiato).
Tra l'altro, visto che il finto-titolo e 'ylwbox' sono legati tra di 
loro, sarebbe meglio esprimere questo legame raggruppandoli con un DIV, 
per costruire una struttura piu' sensata (eventualmente piu' facile da 
sfruttare con il DOM):
<div class="menu">
   <!-- meglio ancora sarebbe farne un vero titolo -->
   <p class="title"><strong>Titolo menu</strong></p>
   <div class="content">
      <p>blah 
      <p>blah blah
   </div>
</div>
Certo cosi' il markup aumenta, ma un buon documento non si costruisce 
lesinando sui tag (eventuale spazio potreste risparmiarlo eliminando 
quell'inutile quanto lungo commento all'inizio). Inoltre in questo modo 
potreste usare piu' facilmente IL TAG CORRETTO PER UN TITOLO, cioe' un 
H1 (o comunque un titolo del livello appropriato) e un selettore 
contestuale nel CSS per formattarlo (".menu h1"). I selettori 
contestuali sono sempre meglio dell'abuso dell'attributo CLASS.
Ah, poi... C'e' sempre quell'inutile META per indicare il charset. 
Inutile, perche' se indicato via META tag serve solo ad evitare un 
warning del validatore del W3C (che tra l'altro, nella maggior parte dei 
casi, non impedisce la convalida).
Usate un linguaggio server-side, non dovrebbe essere troppo difficile 
aggiungere il charset all'intestazione HTTP Content-Type.
In questo modo avreste tutti i vantaggi che si hanno nell'indicare il 
charset, non solo uno (quello di zittire il validatore). L'uso delle 
accentate, cosi' nude e crude, lo eviterei a prescindere, in favore 
delle entita'.
Un'altra cosa, ma questa e' solo una curiosita'... come mai 
contrassegnate come 'private' tutte le pagine? Per impedirne il caching? 
A parte che le pagine non sono realmente protette, ma davvero tutte le 
pagine saranno aggiornate cosi' spesso da non avere, che so, nemmeno 
mezz'ora di validita' per una cache? Cosi' consumate inutilmente banda, 
quella che vi mette a disposizione il vostro provider (che magari e' 
illimitata, ma chissa'...) ma soprattutto quella dei vostri utenti,.

 in un linguaggio di markup come l'(X)HTML.
[cut]
Azz un mito.
Io ero riuscito solo a (leggermente) infastidirmi a guardarlo con
http://www.anybrowser.com/siteviewer.html
col testo troppo attaccato ai bordi.
Ha anche passato il test Lynx, a parte le parole accentate, il cui problema
mi sfugge se è dovuto al discorso delle entità (che citi) o no.
Appiccico qui una domanda a chi ha fatto il sito: ma l'attributo tabindex
non era "obbligatorio" per l'accessibilità?
http://valet.webthing.com/page/v3.1?url=http%3A%2F%2Fwww.webaccessibile.org&
wcag=3&fmt=HTML&xsl=wcag&parse=HTML
Ciao
--
http://www.diodati.org/w3c/html401/index/elements.html
http://dmoz.org/World/Italiano/Salute/Degli_Animali/

 per utenti Apple, il tasto da combinare è CMD
(
http://www.webaccessibile.org/argomenti/accesskey.asp
)
Intanto sulle tastiere Apple non c'e' mai scritto 'CMD' (almeno in 
quelle recenti). Invece c'e' l'icona della mela (infatti e' 
probabilmente piu' famigliare agli utenti il termine "tasto mela") e poi 
un altro simbolo simile a # che non sto a incollare qui perche' c'e' 
solo nei charset/font usati dal Mac.
Poi il tasto Command su Mac e' usato nelle combinazioni di tasti 
principali, tipo Command+W per chiudere la finesta, Command+O per aprire 
i file, ecc.
La scorciatoia Command+H, che dovrebbe riportare alla Home page, puo' 
avere un effetto alquanto disorientante negli utenti di Mac OS X perche' 
nasconde l'applicazione corrente (quindi il browser). Command+M invece 
minimizza la finestra.
Insomma, usare Command per le ACCESSKEY su Mac sarebbe un po' come usare 
Ctrl su Win: porterebbe a un sacco di conflitti.
Chiuso l'OT sul Mac, il tasto da usare con Internet Explorer 5 per Mac 
e' invece Control (ctrl - si', c'e' anche quello). Su altri browser 
sembano non funzionare del tutto o in parte (Mozilla usa solo i numeri, 
associati a Ctrl).
A proposito di numeri e lettere... la dicitura "la combinazione del 
tasto ALT più la lettera elencata qui sotto" e' forse un po' ambigua 
visto che l'elenco comprende sia numeri che lettere (un numero e' 
sicuramente un carattere ma non so se e' definibile 'lettera' :).

 wcag=3&fmt=HTML&xsl=wcag&parse=HTML
Se e' obbligatorio non ricordo, comunque, su 
webaccessibile.org
 il 




(
http://www.webaccessibile.org/argomenti/accesskey.asp
)





OS X e' invece Control (ctrl - si', c'e' anche quello). Su altri 


 nel codice) e poi nella colonna principale.
[segue una mitica disquisizione sul mac]
Ciao

 sicuramente un carattere ma non so se e' definibile 'lettera' :).
Thank u Mac....geek ;-)
Come dicevo sopra siamo in RFC :-D
Io aspetto ancora una tua risposta alla mia mail :-P

 importanti, IMHO).
Gia', pero' nella simulazione di Anybrowser.com vengono mantenuti sia i 
CSS (rapida verifica: gli :hover funzionano) che eventuali tabelle (che 
in effetti sono previste in HTML 3.2), e allo stesso tempo eliminati o 
modificati dei tag (non ho ben capito secondo quale criterio).
Allora quello vedi e' il risultato dell'interazione tra il CSS originale 
e la zuppa di tag generata dal siteviewer.cgi.
Quanto questa simulazione sia realistica, non lo so dire, pero' mi pare 
alquanto improbabile che un browser, per quanto vecchio, supporti solo 
BODY{magin:0} ma non i margini sui DIV.

 Io aspetto ancora una tua risposta alla mia mail :-P
La posta di questo account la guardo dalla webmail di despammed quando 
mi ricordo di farlo, cioe' quasi mai.
La risposta e' no, cmq. Preferisco il dibattito in aree pubbliche 
rispetto al lavoro di un ristretto manipolo di esperti.

 rispetto al lavoro di un ristretto manipolo di esperti.
Ok... ma significa che non hai capito bene cos'è 
webaccessibile.org
 :-)

 Ok... ma significa che non hai capito bene cos'è 
webaccessibile.org
 :-)
Ah, beh, quello puo' darsi.
Comunque, gia' il fatto che a fondo pagina di ogni articolo sia scritto:
(c) 2002 IWA/HWG (W3C Member) / Bazzmann.Com
Non mi attrae particolarmente.
PS: okkio che in
http://www.webaccessibile.org/argomenti/informazioni.asp
Ci sono un paio di ACRONYM aperti e chiusi in posti sbagliati, che 
rendono probabilmente non valido il codice.

 rendono probabilmente non valido il codice.
Thank u... sistemato... erano + di un paio ;-)
ora vo in stand-by per un po' di ore :-)
notte :D

macgeeek wrote:
Hola macgeeek,
 > Ma la validazione non basta certo (anzi) a costruire un buon documento
 > in un linguaggio di markup come l'(X)HTML.
Naturalmente, il sito è stato testato con varie persone prima di essere
messo "in onda", tra cui non vedenti e ipovedenti. Esistono ancora
alcuni errori strutturali che verranno sicuramente corretti.
Ho dovuto rivedere la struttura generale spesso perchè ad ogni nuovo
collaboratore, ci siamo accorti che necessitava di una nuova aggiunta
o correzione strutturale, che naturalmente si ripercuoteva su più
cose, CSS compresi. Da questo alcuni errori ancora presenti.
In ogni caso, l'uso di STRONG non è la stessa cosa di B.
 > rappresenta l'elemento nella struttura del documento, e dovrebbero
 > essere anche comprensibili (soprattutto quando le classi vengono usate
 > per sopperire alle limitazioni 'espressive' dell'HTML).
Assolutamente no.
L'uso delle classi *non* va a colmare lacune HTML, nè di semantica, nè
strutturali, nè di codice. Casomai è più indicato l'attributo "id", non
ancora applicato in tutte le parti per i motivi sopracitati.
Il nome della classe serve allo sviluppatore per ricordarne la funzione,
senza andarsi a rivedere ogni volta il codice CSS. Posso anche
decidere di usare sigle, questo non andrebbe ad inficiare nè il lavoro
di lettori alternativi, nè l'utilizzo del sito, nè l'interpretazione
delle pagine.
 > "ylwboxdashed" (e almeno in Mozilla il box ha un bordo solido e non
 > tratteggiato).
E' una classe proveniente da Bazzmann.Com, inizialmente era
tratteggiata, poi è stata variata. Questo non significa che io debba
cambiare nome ogni volta che ne vario la tipologia, a meno che non
disorienti il lavoro di chi lavora con me.
Una volta stabilizzata la versione, si può procedere ad affinare
il tutto, pulizia di codice compresa.
 > Certo cosi' il markup aumenta, ma un buon documento non si costruisce
 > lesinando sui tag (eventuale spazio potreste risparmiarlo eliminando
 > quell'inutile quanto lungo commento all'inizio). Inoltre in questo modo
Può darsi che per te il commento sia inutile, i commenti fino ad oggi
ricevuti (non da questo progetto naturalmente) sono positivi, quindi
mi spinge nel continuare ad adottare questo sistema. Quando la
"bilancia" mi farà capire che non è utile o non è ben accetto, lo
toglierò.
 > Inutile, perche' se indicato via META tag serve solo ad evitare un
 > warning del validatore del W3C (che tra l'altro, nella maggior parte dei
 > casi, non impedisce la convalida).
Questo vorrebbe dire che il W3C usa ancora oggi tag inutili e solo
per passare il validatore? :)
Comunque non è proprio così, infatti l'equivalente in META di una
intestazione HTTP veniva usata anche per compensare una certa lacuna
di browser più vecchi nell'interpretare intestazioni derivanti
direttamente dal server, che venivano quindi interpretate più
correttamente "leggendo" il documento.
 > In questo modo avreste tutti i vantaggi che si hanno nell'indicare il
 > charset, non solo uno (quello di zittire il validatore). L'uso delle
Credo di averti già risposto qui sopra per il charset, anche perchè
non starei a perdere tempo con il layout senza tabelle se volessi
davvero *solo* zittire il validatore, non credi? :)
Per quanto riguarda le accentate, probabilmente è saltata qualche
impostazione sul software per la conversione automatica, ora
vediamo di capire come mai e la ripristiniamo.
 > Un'altra cosa, ma questa e' solo una curiosita'... come mai
 > contrassegnate come 'private' tutte le pagine? Per impedirne il caching?
Dove?
 > quella che vi mette a disposizione il vostro provider (che magari e'
 > illimitata, ma chissa'...) ma soprattutto quella dei vostri utenti,.
Vabbè tutto, ma pensi davvero che non sia sottomano tutti i giorni
il problema della banda? :))
Spero comunque di aver chiarito i tuoi dubbi.
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

 il problema della banda? :))
Appunto, favorire l'uso della cache potrebbe essere una buona idea, non 
trovi?

 trovi?
Ma siiiiiiiiiiiiiii.... ti avevo già risposto prima! :D
Ciao,


 Riporti comunque un documento del 2000, 
Il fatto che sia un testo del 2000 e' irrilevante visto che nel 2000 
esistevano gia' l'HTML 4.

 allegare dei CSS a un elemento.
Mi sa che non ci capiamo, o mi spiego male io... :)
Ho già risposto a tutte le tue affermazioni di questo post nel post
precedente, è tutto scritto li, leggi bene... :)
Bai! :)


 > per utenti Apple, il tasto da combinare è CMD
    Inoltre, come gia' segnalato a Bazzmann, non e' vero (almeno per
quanto ho verificato sinora) che sia necessario usare un "tasto
modificatore". le accesskey, ad es. sul sito della Regione veneto e su
Bazzmann.com, funzionano su Macintosh (MacOS 8.6 eng, tastiera ita,
browser iCab 2.8) semplicemente premendo la lettera corrispondente.
-- 
    Nicola "nez" D'Agostino
  <!-- 
nezge...@geocities.com
 --remove/togli "getitout" -->

 modificatore". le accesskey, ad es. sul sito della Regione veneto e su
E' vero laddove non si usa iCab, su IE e Moz per Mac si devono usare,
o almeno dai test fatti e dalle segnalazioni ricevute.
Comunque ho aggiunto anche la tua segnalazione su tutti e tre i
progetti:
- Bazzmann.Com
- Bazzmann.Com/Usability_it
- Webaccessibile.org
Grazie per il feedback!
Marco :)
