title: per una progettazione indipendente dai dispositivi: Introduzione

author: Donato Taddei

text:
                PER UNA PROGETTAZIONE   INDIPENDENTE DAI DISPOSITIVI
                DI
                DONATO TADDEI
            (C) ISTITUTO NAZIONALE DELLA PREVIDENZA SOCIALE (INPS) 2004 -
2005
LA RIPRODUZIONE E DISTRIBUZIONE E' LIBERA E INCORAGGIATA.
        Avvertenza
Per una informativa veloce leggere
        la premessa, l'introduzione, gli scenari di uso  e e la
        "road map"  nell'ultimo paragrafo.
-       oltre che alle liste viene inviato ora a circa 50 persone,
        a vario titolo, come del resto  i capitoli successivi, per
        raccogliere commenti e disponibilita' collaborative,
        anche occasionali.
Comunicare eventualmente la volonta' di non ricevere
        ulteriori messaggi in merito.
Autorizzata la pubblicazione sui siti, con l'unica attenzione di
comunicare l'url.
--------------------------------------------
                       SOMMARIO
               Ringraziamenti
                       Premessa
                              1 -     Introduzione
               1.1 -   Cosa e' questa "indipendenza dai dispositivi?
               1.2 -   Obbiettivi chiave di questa attivita' del w3c
               1.3 -   Sinergie e collegamenti con altre attivita' del W3C
               1.4 -   Rapporti e sinergie del gruppo con realta' esterne al
W3C
               1.5 -   Pubblicazioni del gruppo di lavoro per l'indipendenza
dai dispositivi
               1.6 -   Ingredienti di base e scenari di uso
               1.7 -   La "road map" delle tappe del percorso
-----------------------------------------------------
                                               Ringraziamenti
Nell'accingermi a questo lavoro, di cui non sono nemmeno sicuro di avere
le capacita', ho trovato un forte incoraggiamento nella cortese attenzione
data a questo primo capitolo introduttivo da un esponente di spicco
del Consorzio mondiale del web (W3C), Mr. Charles Mccathienevile, per
questo lavoro di divulgazione in italiano di una  delle attivita'
del Consorzio.
Egli e' tra i piu' attivi componenti del gruppo di lavoro che al W3C
ha elaborato le linee guida per l'accessibilita' (WAI),
come coordinatore della "W3C recommendation" intitolata:
"Authoring tools accessibility guidelines"
http://www.w3.org/tr/2003/WD-ATAG20-20030314/
ed anche della relativa specifica tecnica intitolata:
"Techniques for Authoring Tool Accessibility Guidelines 1.0",
relative ai requisiti di accessibilita' dei tools di sviluppo,
nonche' le linee guida per l'accessibilita' in xml
"XML Accessibility Guidelines"
http://www.w3.org/tr/2002/WD-xag-20021003
Tra l'altro, egli ha fatto parte per un periodo anche del gruppo di lavoro
per l'indipendenza dai dispositivi di cui si tratta in questo e nei prossimi
capitoli, nonche' lavorato per un linguaggio di marcatura per la musica in
xml.
Attualmente partecipa al gruppo di lavoro per il web semantico al W3C,
coordinando un progetto europeo per lo sviluppo di tools per la produzione
di
siti web di elevato valore  semantico, anche nella sua veste di
vicepresidente della Sidar.
Devo inoltre ringraziare per i loro apporti i signori:
- Michele Ledda  ,
curatore del sito molto accessibile del
Sentiero Impresa, Sportello Regionale per la Promozione di impresa della
regione Sardegna, per aver pubblicato questo scritto, ed altri,sul sito
all'indirizzo:
http://82.85.16.147:8080/sentiero/page.jsp?idPagina=396
- Gianluca Affinito,
collaboratore di
webaccessibile.org
, che segue, oltre all'accessibilita',
in modo particolare le problematiche connesse ai palmari e alla degradazione
delle applicazioni su di essi, derivante da una progettazione
sostanzialmente
disegnata adottando il personal computer come esclusivo meccanismo di
accesso.
  Oltre ad aver pubblicato e pubblicizzato questo scritto
ne ha anche curato la versione xhtml:
http://www.frosinone.org/palmari/dii.htm
- Andrea Crevola
dottore in Scienze della Comunicazione. Insegna "d Informatica e
Comunicazione"
presso l'Università degli Studi di Torino.
Inoltre è un professionista attivo sui temi quali usabilità e accessibilità
dei sistemi informatici, architettura dell'informazione,
progetto e sviluppo di soluzioni per Internet Mobile,
applicazioni per la gestione dei contenuti e della conoscenza, applicazioni
del Semantic Web, ricerca e valutazione delle information and communication
technologies emergenti
Ha curato la traduzione integrale del "device independence principles"
reperibile all'indirizzo:
http://mobilewebsites.it/w3c/indipendenzadevice.htm
e da cui viene riportata la traduzione della  "motivation" (1.9)
e l'intera section 2 del documento.
                       Premessa
Questo scritto scaturisce da una mia personale necessita' di approfondire
il tema, oggetto di una delle "attivita'" del World Wide Web Consortium
(W3C),
in quanto la ritengo  di fondamentale importanza sia per losviluppo
di applicazioni  flessibili e adattabili alla sempre maggiore offerta
di funzionalita', di servizi e dispositivi, sia per  processi
di contestualizzazione, personalizzazione e adattamento ai diferenti
contesti di veicolazione e recapito della informazione attraverso la catena
di
intermediari tra il server e il "client" finale, sia per quanto concerne il
processo di interpretazione e adattamento a livello "user-agend" e quindi
anche a livello delle tecnologie assistive.
In realta' queste ultime sono il movente di questo mio lavoro.
Esse infatti presentano una ben nota "criticita'": il ritardo
con cui si adattano alle nuove tecnologie.
Per implementare infatti una soluzione di tecnologia assistiva, e'
necessario che prima sia disponibile sul mercato la versione "normale",
su cui la tecnologia assistiva si appoggia ed e' altresi' necessario
il tempo richiesto per la implementazione, il test e la commercializzazione
per cui tende a riprodursi continuamente un "gap" tra l'uso di una
funzionalita' da parte di un utente normale e il corrispondente uso adattato
da parte di un disabile, attraverso la tecnologia assistiva.
Tale "gap" e' quantificabile in termini temporali, dal tempo in cui
un prodotto software fa il suo ingresso sul mercato fino al rilascio
della soluzione adattativa basata sulla tecnologia assistiva
(tempo stimabile tra i sei mesi e i 2 anni),
cui va aggiunto  lo scarto temporale necessario al disabile per
familiarizzare
con la stessa soluzione di tecnologia assistiva, in quanto essa e'
necessariamente "mediata", anzicche' tendenzialmente il piu' possibile
"immediata", come appunto la soluzione standard o normale.
Io ritengo che un modo per ridurre questo "gap" sia appunto ridurre
questo scarto temporale e che cio' sia facilitato dalla adozione degli
opportuni criteri progettuali nello sviluppo delle applicazioni e dei
servizi. Per tale motivo ritengo interessante questo materiale,
di cui propongo una riduzione italiana alquanto casereccia, rimandando
per l'originale alla apposita sezione del sito del W3C da cui e'
liberamente tratto.
Dalla sezione "technical reports" la si raggiunge facilmente selezionando
"activities" e poi "device independence": e' tra i primi links.
Il materiale proposto e' presentato in forma di "faq" che divulghero'
a puntate sulle liste tematiche da me frequentate, recando nel subject
il relativo numero, per evidenti motivi di "digeribilita'";
scopo dichiarato: promuovere scambio e informazione sul tema.
Quando, dopo le prime 6-8 puntate, emergera' un quadro abbastanza completo
sottoporro' quanto fin qui prodotto a un certo numero di persone che stimo
professionalmente nel campo infotelematico, per tentare di avere
qualche forma  di coinvolgimento:
da un benevolo cenno di attenzione, a suggerimenti, ad ospitare questo
scritto
sul proprio sito, fino ad eventuali condivisioni e/o partnership,
in quanto questo materiale serve solo a mettere le carte in tavola,
possibilmente per la realizzazione di progetti e servizi, anche inseriti
o raccordati nell'ambito di progetti UE, che soffisfino il requisito
appunto della indipendenza dai dispositivi.
               1 -     Introduzione
               1.1 -   Cosa e' questa "indipendenza dai dispositivi?
fino a pochi anni fa l'accesso al web avveniva quasi esclusivamente
attraverso un personal computer o una stazione di lavoro.
 C'erano si' delle differenze tra i vari browsers, alcuni  dei quali
 fungevano da terminali testuali, e, date le velocita' di connessione
 dell'epoca, erano spesso piu' performanti rispetto ai loro analoghi
 grafici: (questo ai tempi di telix e di mosaic!).
Tuttavia, quasi sempre l'accesso al web, per persone senza particolari
necessita', ha significato disporre di monitor a sempre maggiore
risoluzione,
con un maggior numero di colori, e completo di tutte le capacita' grafiche.
Cio' e' stato sostanzialmente vero fino alla meta' del 2000;
ma da allora il numero di dispositivi che possono connettersi al web
e' cresciuto da un piccolo numero di dispositivi che presentavano
essenzialmente  lo stesso  nucleo di funzionalita', a molte centinaia di
dispositivi e con caratteristiche e funzionalita' diversificate.
Ora devono poter accedere al web telefonini, smartphone,  palmari, PDA,
sistemi di televisione interattiva, sistemi a risposta vocale, kiosks e
perfino alcune applicazioni domestiche, con un proliferare di meccanismi
di accesso, di dispositivi di input e di output, di linguaggi di marcatura,
di servizi di rete a supporto;
Cio' rende piu' complicato il lavoro di sviluppo di siti e di
applicazioni  utilizzabili con l'uno o l'altro di questi dispositivi,
secondo le preferenze e/o necessita' dell'utente.
Per affrontare questa realta' e' stata costituita presso il  w3c
una specifica attivita' per l'indipendenza dai sispositivi
per focalizzare le tecniche che possono essere utilizzate e piu' in
particolare il metodo con cui le  caratteristiche dei vari dispositivi
possono essere rese disponibili per un uso generalizzato
e per questa via supportare gli sviluppatori di siti e di applicazioni
rendendo loro piu' semplice la vita.
Senza infatti questa iniziativa c'e' un rischio sempre maggiore
di "esclusione" dal web per interi sottoinsiemi di utenti che non utilizzino
determinati dispositivi.
Insediato nel 2001, il gruppo di lavoro formula una prima  "bozza" o "draft"
contenente i principi per una progettazione indipendente dai
dispositivi, che sostanzialmente identifica due aree di interesse per
l'analisi:
quella relativa al contesto del trasporto, fruizione e adattamento
"delivery context" delle informazioni e  quella piu' specificamente centrata
sui problemi di sviluppo e sulle soluzioni tecnologiche esistenti
nell'ambito dei lavori del W3C, adottando lo schema xml per la
formulazione di specifiche.
Per quanto concerne la definizione, il trasporto e l'uso delle
informazioni  relative alle funzionalita' specifiche dei singoli
dispositivi "client", il gruppo di lavoro CC/PP
(Composite capability/Preference profiles), poi integrato in quello per
l'indipendenza dai dispositivi, ha definito  un quadro generale
per la rappresentazione di tali funzionalita', giunto quest'anno allo
stadio di "recommendation".
Ma accanto a questa specifica vengono altresi' individuate altre aree
di lavoro:
-       Tracciare una panoramica delle problematiche correlate al contesto
di
inoltro/ricezione/adattamento, raggruppando sulla base dei requisiti
le risultanze del dibattito interno, viene prodotta una nota contenente
una visione d'insieme delle differenti tecniche che possono essere
utilizzate per la definizione, lo scambio e l'utilizzo
delle funzionalita' i dispositivi ed apparati, focalizzando, dal punto
di vista del sistema, che  in questo contesto:
- esistono degli specifici attributi  che saranno oggetto  della
pubblicazione: "Caratteristiche di base di una presentazione indipendente
dai dispositivi".
- tali informazioni sono oggetto di richiesta, scambio, e se necessario
negoziazione, cache e risoluzione come proposto  nella specifica prima
citata sui profilo di funzionalita' e preferenze, e cio' pone il problema
di uno specifico protocollo.
La formulazione di tale protocollo tuttavia esula dall'ambito del gruppo
di lavoro e deve passare attraverso l'internet enginering task force (IETF).
- Molte funzionalita' dei dispositivisono accessibili agli sviluppatori
tramite "fogli di stile" e "profili dei documenti", per cui e' ovvia
la sinergia con i relativi gruppi di lavoro dedicati;
-       Attributi di base dei dispositivi
a seguito dell'interesse dimostrato per l'analisi dei contesti di
trasporto, ricezione e adattamento, viene avviato l'iter  per una
"recommendation" su una serie di attributi base dei dispositivi di
presentazione, con i seguenti obbiettivi:
- consolidare precedenti inconsistenti tentativi di definire un
vocabolario standard per i dispositivi;
 (Conneg Media Feature Sets, CC/PP  example vocabulary, UAProf, Media
Queries)
- definire, in forma modulare, una serie di attributi di base che
possano essere utilizzati dagli sviluppatori per programmare l'adattamento.
- proporre un modo con cui questo vocabolario di base possa essere
esteso in maniera flessibile;
- supportare molteplici rappresentazioni per gli attributi,  (XML, RDF, CSS)
in funzione del contesto d'uso, evidenziando le relazioni tra gli
attributi di base e gli analoghi esistenti in altri vocabolari.
- definire i fondamenti per la definizione delle classi di dispositivi:
alcune tecniche per la creazione di vocabolari sono gia'  descritte nella
"Composite capability/preferences profile recommendation".
Lo scopo non e' creare un altro vocabolario bensi' individuare una serie
di attributi di base e i loro significati semantici, come essi sono resi
in altri vocabolari esistenti  (UAProf,  CSS Media Queries, etc) e di come
possano essere rappresentati in xml o rdf, attraverso la definizione di
"data types" che usino lo schema xml, producendo anche
una serie di requisiti e di casi di test e di utilizzo.
-       sviluppo di applicazioni indipendenti dai dispositivi
Esso e' correlato al modo con cui  i linguaggi di marcatura esistenti
possono essere usati per garantire l'accesso a dispositivi diversificati,
e alla adozione di nuove marcature per descrivere tali proprieta'.
In questo ambito sono stati individuati ulteriori aree tematiche, oggetto
di relative "note di lavoro":
-       scenari di sviluppo
al fine di indurre  ulteriori apporti di analisi in questa area viene
prodotta una "nota" che analizza da un capo all'altro lo scenario
connesso allo sviluppo di contenuti web e di applicazioni adattabili
ai differenti contesti di uso, con l'obbiettivo di sviscerare
finalita' e criticita' connesse allo sviluppo, partendo dalle piccole
applicazioni a contenuto statico per arrivare a siti complessi a contenuti
dinamici, e dunque per definizione adattabili, che erogano servizi
attraverso complesse interazioni, come per esempio quelle connesse
alle transazioni commerciali.
-       tecniche di sviluppo
partendo dai precedenti scenari di sviluppo analizzati,
indicare delle soluzioni tecniche capaci di aumentare e migliorare
l'indipendenza dai dispositivi e dunque l'adattabilita' e flessibilita'
complessiva di applicazioni e interazioni, innanzitutto utilizzando le
tecniche esistenti;
- descrivere come gli sviluppatori possono utilizzare i linguaggi di
marcatura e le tecniche di adattamento esistenti per veicolare
contenuti fruibili tramite differenti dispositivi;
- In secondo luogo mostrare come possa raggiungersi la separazione del
contenuto dalla presentazione in presenza di dispositivi di varia
funzionalita';
- analizzare gli approcci  all'adattamento, a livello del server di origine,
a livello della catena di intermediari e a livello del "client"
dell'utente finale,analizzando anche quegli approcci che comportano
un modello distribuito di tale processo di adattamento attraverso
i vari stadi dell'interazione "request - response";
- fornire esempi basati sui linguaggi di marcatura esistenti e sulle
tecniche utilizzabili per l'adattamento.
- fare il punto sulla insufficienza delle attuali tecniche per arrivare
agli obbiettivi di lungo termine oggetto dell'attivita' del gruppo di
lavoro.
Inoltre, con l'utilizzo di tecniche basate  su XForms:
- mostrare come la navigazione possa essere descritta in modo indipendente
dai dispositivi finali, ad esempio per dispositivi non visuali o visuali
con risoluzioni molto differenti;
- mostrare come l'interazione possa essere espressa in maniera
indipendente dai dispositivi;
- mostrare come configurare applicazioni capaci di adattarsi a contesti
molto diversificati di trasporto e ricezione;
-       marcature per l'interazione
L'attuale sviluppo del web presenta in maniera crescente la necessita'
di veicolare applicazioni interattive agli utenti.
Si tratta quindi di focalizzare i requisiti sintattici e semantici
atti a descrivere le interazioni in una maniera indipendente dai
dispositivi.
Cosi', dopo aver definito gli scenari e le tecniche di sviluppo, sara'
forse possibile o necessario adattare la presentazione delle interazioni
alla molteplicita' dei dispositivi.
Per questo l'attenzione viene focalizzata  su come utilizzare allo scopo
le specifiche   XForms, XHTML e XML Event e loro combinazioni per
esprimere le interazioni in maniera astratta, dunque svincolata
dai dispositivi.
Pertanto sono possibili commenti, proposte di modifica e di ampliamento
ai gruppi di lavoro per tali specifiche.
Altre estensioni, che necessitino di esprimere  le interazioni in
maniera indipendente dai dispositivi, dovranno confluire in ulteriori
raccomandazioni del W3C; in particolare, assumendo   l'adozione di
un ulteriore linguaggio di marcatura, viene agganciato il gruppo di
lavoro per la "multimodal interaction".
-       profili dei documenti
Il "profilo" di un documento e' costituito da una serie di attributi,
definiti tramite un vocabolario xml o rdf, che possono essere utilizzzati
ad esempio in fase di "negoziazione" per l'adattamento dei documenti
in funzione dei diferenti conteti di trasporto e utilizzo.
gia' nel 99 il gruppo di lavoro sull'html aveva propostto una "draft"
contenente alcuni requisiti di tali profili. Nel 2001, a seguito del
lavoro svolto dal gruppo CC/PP, viene demandato ad esso e quindi al
gruppo per l'indipendenza dai dispositivi, l'ulteriore approfondimento.
Si tratta di identificare una serie di attributi idonei allo scopo e di
definirli in una prossima "recommendation".
Cio' significa:
- esplorare  quali metadati sarebbero richiesti per esprimere
la compatibilita' dei media, nonche' lo stile delle interazioni
e gli altri attributi dei documenti necessari alla negoziazione e
adattamento dei contenuti;
- usare lo schema xml, rdf e/o lo schema rdf per la definizione dei profili;
- garantire la compatibilita' con le trasformazioni CSS Media Queries e
XSLT.
Si riporta qui l'elenco dei membri piu' attivi di questo gruppo di lavoro
per mostrare quali realta' industriali e di ricerca concorrono a questo
lavoro:
  Stephane Boyera (W3C)
  Steve Farowich (Boeing)
  Roger Gimson (HP)
  Yoshihisa Gonno (Sony Corp)
  Guido Grassel (Nokia)
  Rotan Hanrahan (MobileAware Ltd)
  Kazuhiro Kitagawa (W3C)
  Markus Lauff (SAP AG)
  Tayeb Lemlouma (INRIA)
  Rhys Lewis (Volantis Systems Ltd)
  Roland Merrick (IBM)
  Franklin Reynolds (Nokia)
  Andreas Schade (IBM)
  Ryuji Tamagawa (Sky Think System)
  Luu Tran (Sun Microsystems)
  Michael Wasmund (IBM)
  Stan Wiechers (Merkwelt)
  Jason White (University of Melbourne)
  Candy Wong (NTT DoCoMo)
  Amy Yu (SAP AG)
Hanno altresi' partecipato al lavoro del gruppo, magari come membri del
gruppo  CC/PP, ora integrato in esso:
  Yasser AlSafadi (Philips Research)
  Abbie Barbir (Nortel Networks)
  Einar Breen (Adaptive Media)
  Shlomit Ritz Finkelstein (invited expert)
  Vidhya Golkar (Argogroup)
  Luo Haiping (Comverse)
  Eric Hsi (Philips Research)
  Lynda Jones (SHARE)
  William Loughborough (Smith-Kettlewell Institute)
  Stephane Maes (IBM)
  Kaori Nakai (NTT DoCoMo)
  Hidetaka Ohto (W3C/Panasonic)
  Garland Phillips (Motorola)
  Lalitha Suryanarayana (SBC Technology Resources)
  Yoshifumi Yonemoto (NTT DoCoMo)
I
               1.2 -   Obbiettivi chiave di questa attivita' del w3c
La missione di questa attivita' e' evitare che il web si vada frammentando
in compartti stagno accessibili soltanto attraverso  uno specifico
sottoinsieme di dispositivi.
Il gruppo di lavoro per l'indipendenza dai dispositivi del w3c
- raccoglie i requisiti tecnici delle varie categorie di dispositivi;
- rivede le specifiche correlate all'obbiettivo, dentro e fuori il w3c,
proponendo casi di studio e di test in materia di indipendenza dai
dispositivi, ad altri gruppi di lavoro del w3c con cui coopera;
- indica tecniche che possono aiutare gli sviluppatori a migliorare
la gestione di dispositivi differenti;
- in particolari aree che non rientrano gia' nella attivita' di altri gruppi
di lavoro, esso puo' proporre delle raccomandazioni specifiche per una
progettazione il piu' possibile svincolata dalle caratteristiche
dei dispositivi di accesso.
Vi sono anche delle mailing-list pubbliche:
www...@w3.org
  specifica per la device independence:
per iscriversi inviare un messaggio vuoto, con oggetto subscribe, a
www-di-s...@w3.org
c'e' poi l'archivio della ml, ora chiusa, su mobile access
http://lists.w3.org/Archives/Public/www-mobile/
e per quanto riguarda televisione e web:
http://lists.w3.org/Archives/Public/www-tv/
               1.3 -   Sinergie e collegamenti con altre attivita' del W3C
Il gruppo di lavoro coopera con i seguenti altri gruppi di lavoro del W3C:
 - XHTML
LE PROPOSTE DI NUOVE MARCATURE PER GARANTIRE L'INDIPENDENZA DAI DISPOSITIVI
DOVRANNO ESSERE COMPATIBILI CON XHTML2;
-  XForms
Le marcature proposte per l'indipendenza dai dispositivi dovranno altresi'
essere compatibili con XFORMS;
-  MultiModal Interaction
Le proposte associate al complesso del trasporto e inoltro dell'informazione
"delivery context" dovranno tener conto delle necessita'
dell'interazione multimodale;
Inoltre i componenti del gruppo di lavoro partecipano
al "Hypertext Coordination Group"
che ha la responsabilita' di assicurare che le revisioni effettuate dai
vari gruppi  di lavoro siano coerenti con i  piani generali del Consorzio:
di esso fanno parte rappresentanti del gruppo di lavoro per il coordinamento
dell'xml, e del gruppo di lavoro delle  WAI, nonche' dei gruppi di lavoro
che si occupano di "Document   Formats Domain" e"Interaction Domain".
Il gruppo di lavoro coopera altresi' col gruppo di lavoro per la
"web accessibility initiative (WAI)" per assicurare che  i suggerimenti
per una progettazione indipendente dai dispositivi soddisfino altresi' i
requisiti di accessibilita'. Inoltre collabora con la Wai per assicurare,
nelle forme appropriate, che i meccanismi suggeriti  per l'indipendenza
dai dispositivi possano essere utilizzati anche per supportare
l'accessibilita'.
Dal marzo 2003 ha inoltre assorbito il gruppo di lavoro CC/PP,
(composite capability/preference profile)  arrivando su questo a
una "Recommendation".
               1.4 -   Rapporti e sinergie del gruppo con realta' esterne al
W3C
Questo e' un elenco parziale di realta' che si occupano di  integrare
tecnologie web in vari tipi di dispositivi, all'esterno del Consorzio
Mondiale del web.
Per problemi concernenti gli obbiettivi di interesse del gruppo di lavoro
viene stabilita una coordinazione tra lo stesso e tali realta'.
IN particolare con:
- The Internet Engineering Task Force
Con questo nome (IETF) si identifica una grande comunita' internazionale
aperta di sviluppatori di reti, operatori, venditori, ricercatori ecc.
interessati all'evoluzione della architettura di internet.
Il punto di contatto e' la "negoziazione dei contenuti" per quanto
riguarda la definizione di uno specifico protocollo per la negoziazione
dei profili dei dispositivi (CC/PP).
 -        Wireless technologies WAP Forum (Wireless Application  Protocol
Forum)
Il consorzio di industrie per lo sviluppo dispecifiche per dispositivi
mobili e servizi associati che ha definito UAProf (basato su CC/PP
per rappresentare i profili dei dispositivi mobili.
Punto di contatto:
le specifiche WAP 2.0 sono esaminate dal gruppo p  lavoro sotto
il profilo dell'indipendenza dai dispositivi: di particolare interesse
lo sforzo per la definizione di standardper i servizi di download dei
contenuti.
- Wireless Village
 The Wireless Village Initiative for Mobile Instant Messaging and  Presence
e' un consorzio di industrie wireless che ha  lo scopo di stabilire
rapporti con organizzazioni giuridiche e di standardizzazione,
per stabilire un  pubblico protocollo per lo scambio di contenuti e di
informazioni sul terminale dell'utente attraverso dispositivi mobili,
servizi da postazioni mobili, servizi basati su messaggistica istantanea
basata su internet.
- 3GPP (The 3rd Generation Partnership  Project)
Il progetto  3GPP mette in sieme standard per la telecomunicazione,
sotto la direzione del  "Mobile Competence Centre" per produrre
sistemi mobili di terza generazione, basati sugli standard
GSM broadband, largamente utilizzati in Europa.
Esso ha stabilito collegamenti con altri gruppi e consorzi come:
ITU, IETF, ISO MPEG, OMG,  SyncML, WAP, W3C, GSMA (il maggiore operatore
GSM)
ed altri consorzi di industrie della televisione.
- 3GPP2 (The 3rd Generation  Partnership Project 2)
Questo progetto, sponsorizzato da ITU e da  ETSI, si propone la
realizzazione di sistemi mobili di terza generazione basati
sulla tecnologia CDMA, largamente utilizzata invece in America ed IN Asia.
Entrambi questi progetti hanno comunque stabilito di collaborare insieme
per assicurare l'accesso  trasparente ai servizi basati su sistemi
di terza generazione, indipententemente dal luogo e quindi dalla
tecnologia utilizzata.
-               media di informazione
Operatori di radio e televisione oggi si pongono il problema di  integrare
i tradizionali contenuti audiovisivi con i contenuti e le possibilita'
del web della terza generazione di internet, DOVE  IL PALINSESTO E' IN
EFFETTI CREATO  LIBERAMENTE DALL'UTENTE, CON LE NECESSITA' DI
SINCRONIZZAZIONE MULTIMEDIALE CHE IMPLICA, NONCHE' DI INTERAZIONE
MULTIMODALE.
Organizzazioni come  ARIB, ATSC, ATVEF, EBU, OpenCable, e WorldDAB
sono al lavoro per realizzare l'integrazione tra questi differenti media,
attraverso la definizione di un protocollo di trasporto interoperabile,
la definizione di metadati per la "negoziazione" dei contenuti e dei
profili di utenza, nonche' per la gestione dei diritti digitali connessi.
In Particolare sono in corso elaborazioni di specifiche per la veicolazione
di
contenuti nonche' delle informazioni relative al contesto di
inoltro/ricezione
come per esempio il  TV-Anytime Forum o il DVB (The Digital Video
Broadcasting
 Project)
-       Contesti interattivi
Molti consorzi ICT hanno posto l'accento sulla interoperabilita'
attraverso piattaforme terogenee, che complicano il mondo dei dispositivi
mobili.
Il gruppo di lavoro intrattiene in particolare rapporti  con quei gruppi
che lavorano nel campo della negoziazione di contenuti e profili di utenza,
dati di sessione, sincronizzazione dei dati, metadati e oggetti standard,
come:
- MMF (The Open Group  Mobile Management Forum)
- SyncML (The SyncML Initiative)
- WSIA (Web  Services for Interactive Applications)
- WSRP (Web Services for Remote Portals)
-       gruppi connessi alle stampanti
le stampanti rientrano tra i dispositivi di cui si occupa il gruppo
di lavoro CHE dunque segue al w3c due gruppi:
quello per la definizione di mark-up di stampa  (XHTML-Print)
e quello per la descrizione delle funzionalita' delle stampanti
 PWG(The Printer Working Group)
               1.5 -   Pubblicazioni del gruppo di lavoro per l'indipendenza
dai dispositivi
-       Raccomandazione (dunque diretta  a tutti):
-       profili composti di funzionalita' e preferenze
  15 gennaio 2004
  Composite Capability/Preference Profiles (CC/PP):
  Structure and Vocabularies  1.0
http://www.w3.org/tr/2004/REC-CCPP-struct-vocab-20040115/
Un profilo CC/PP e' una descrizione delle funzionalita' supportate da un
determinato dispositivo, integrato dalle "preferenze" di un  determinato
utente.
Il documento Descrive la struttura di tale profilo e mostra come
utilizzare e mantenere vocabolari per la loro definizione.
E' altresi' disponibile una serie di test ed anche un  "report" delle
implementazioni disponibili;
-       Glossario dei termini per l'indipendenza dai dispositivi
  25 agosto 2003
  Glossary of Terms for Device Independence
  (documento interno al gruppo: draft).
http://www.w3.org/tr/2003/WD-di-gloss-20030825/
contiene un glossario dei termini utilizzati nel contesto della attivita'
per
l'indipendenza dai dispositivi; (bozza di lavoro per il gruppo).
-       NOTE all'attenzione dei vari gruppi di lavoro
-       Tecniche di sviluppo indipendente dai dispositivi
  18 febbraio 2004
  Authoring Techniques for Device Independence
http://www.w3.org/tr/2004/NOTE-di-atdi-20040218/
  Questa nota presenta un sommario di alcune tecniche e soluzioni che gli
  sviluppatori di siti e i gestori di servizi possono adottare per creare
  contenuti accessibili attraverso differenti meccanismi di accesso
-       Principi per l'indipendenza dai dispositivi
  1 Septembre 2003
  Device Independence Principles
http://www.w3.org/tr/2003/NOTE-di-princ-20030901/
propone una formulazione dei principi per l'indipendenza dai dispositivi;
identificando due specifiche aree di intervento, approfondite in  altri
documenti: la panoramica sui contesti di trasporto/ricezione ele tecniche
di sviluppo per l'indipendenza dai dispositivi.
-       Criticita' nello sviluppo di applicazioni indipendenti dai
dispositivi
 1 settembre 2003
Authoring Challenges for Device Independence
http://www.w3.org/tr/2003/NOTE-acdi-20030901/
La nota esamina le criticita' connesse allo sviluppo di materiale che
deve essere acceduto attraverso una vasta gamma di dispositivi con un
ampio e diversificato spettro di funzionalita'.
-       Dragts  (documenti interni per il gruppo e gli altri collegati)
-       Caratteristiche tipiche di una presentazione indipendente
        dai dispositivi: requsiti e casi di utilizzo
10 maggio 2003
Core Presentation Characteristics:Requirements and Use Cases

http://www.w3.org/tr/2003/WD-cpc-req-20030510/
-       Panoramica sui contesti di inoltro/recapito dell'informazione
13 dicembre 2002
Delivery Context Overview for Device Independence
http://www.w3.org/tr/2002/WD-di-dco-20021213/
               1.6 -   Ingredienti di base e scenari di uso
riporto una descrizione, il "longdesc" del grafico contenuto  nella sezione
del sito del W3C, nella  "introduction to device independence",
per dimostrare l'efficacia comunicativa degli "equivalenti testuali",
per dare una pallida idea dell'ambito architetturale in cui si muove,
per introdurre alcuni termini del glossario per l'indipendenza dai
dispositivi, oggetto della prossima puntata.
I componenti AD alto livello coinvolti  dall'indipendenza dai dispositivi
possono essere cosi' schematizzati:
un utente "client" del web,
chiede di accedere  ad una risorsa "resource"
su un particolare server detto "origin server".
Tale accesso potra' essere diretto, o avvenire attraverso uno o piu' altri
server intermediari, come gateways, proxies, tunnels, redirectors ecc..
Il "client" dell'utente effettua una richiesta di accesso tramite
protocollo http "http request";
Tale richiesta, oltre a contenere l'indirizzo della risorsa desiderata,
opportunamente codificata, conterra' anche una serie di informazioni
utili a identificare il "client" e/o le sue funzionalita', NOte come
l'ambiente di ricezione, "delivery context",
per fornire le informazioni che potranno essere utilizzate per adattare la
risposta del server "http response", adeguata al dispositivo "client".
La richiesta e le specificazioni relative al contesto di ricezione arrivano
al server anche attraverso uno o piu' servers intermediari, che a loro volta
possono elaborare, filtrare, adattare la stessa.
Il server "origin server" usa i suoi archivi per costruire la risposta
nel modo richiesto ed essa ritorna al "client" ripercorrendo a ritroso la
eventuale catena di intermediari.
In altre parole il processo di adattamento alle possibilita' del "client"
puo' avvenire sul server origine il quale, utilizzando le informazioni
relative al contesto di ricezione "delivery context" seleziona il materiale
piu' adatto al contesto di ricezione, gestendo  il layout e lo stile
in modo adattato all'utente.
Se l'adattamento puo' avvenire attraverso intermediari potrebbe non essere
necessario che avvenga a livello "server origine" con l'adattamento
dei contenuti.
Se al server viene richiesto materiale che ha bisogno di adattamento
esso potra' avvenire anche esclusivamente a livello del client o
prevedere un modello distribuito in cui tale adattamento possa essere
fatto a vari livelli successivi della catena delle interazioni.
Abbiamo visto gli ingredienti di base che  entreranno nella ricetta.
seguono  ora una serie di scenari di uso che mostrano i modi differenti
con cui gli utenti interagiscono col web, per mostrare i benefici
di una progettazione indipendente dai dispositivi,
che cioe' sia in grado di garantire loro:
-      scelta tra differenti dispositivi di accesso
-       scelta  tra differenti modalita' di connessione
-       scelta tra differenti modalita' di interazione
-       scelta tra differenti modalita' di presentazione
-       utilizzo di interazioni multimodali
-       possibilita' di transazioni e accessi da dispositivi differenti
Gli esempi costituiscono l'Appendice A del documento:
  Device Independence Principles del 1/9/2003
http://www.w3.org/tr/2003/NOTE-di-princ-20030901/
-      scelta tra differenti dispositivi di accesso
la signorina Kaseem  e' una adolescente un po golosa, con problemi di
ipovisione, che usa il web per trovare sempre nuovi ristoranti cui andare
con gli  amici e i compagni di classe.
A casa usa un ingranditore e/o uno screen-reader con barra braille.
Ha un display braille portatile con capacita' di connessione e lo usa
quando va fuori, in locali o ristoranti.
Ulteriori dettagli sul contesto di uso sono descritti  in:
"How People with Disabilities use the Web", [PWD] (Brewer) del 4/1/2001
http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web
Dal punto di vista "indipendenza dai dispositivi" nel seguito "DI") questo
utente deve poter scegliere tra differenti meccanismi di accesso per
interagire col web; l'accessibilita' puo' essere potenziata dalla
indipendenza dai dispositivi.
Dal punto di vista "sviluppo" la pagina web deve essere
accessibile alla signorina, supportando le diverse funzionalita'
e interazioni dei differenti dispositivi.
-       scelta  tra differenti modalita' di connessione
Peter e' il capo dell'ufficio vendite di una compagnia della Silicon Valley
,
responsabile per gli USA centro-occidentali. quando non e' in giro,
egli lavora spesso in posti diversi dalla sua sede: in alcuni uffici
utilizza la procedura interna per la gestione delle vendite, attraverso il
suo portatile e una connessione ADSL a 1.5 mbps. Quando invece si reca
dai clienti usa il modem   interno GPRSP CMCIA del suo portatile per
connettersi
alla rete wireless dell'azienda.
Dal punto di vista (DI) rientra negli scopi della sua indagine il cambio
del contesto di trasporto derivante dalle differenti condizioni
di connettivita'; dal punto di vista "sviluppo" la presentazione dovra'
variare in funzione della velocita' di connessione disponibile:
ovvero la percezione dell'utente sara' magari sempre la stessa,
ma quello che cambia e' la personalizzazione di tale percezione in funzione
del contesto d'uso: per esempio con una connessione veloce non e' un
problema scaricare velocemente grosse immagini ma si deve pero' poter
abbassarne la risoluzione per velocizzare  i trasferimenti se si opera
ad esempio con un modem a 28.8 k.
-       scelta tra differenti modalita' di interazione
Nancy ha tutti i giorni solo 45 minuti per cambiare lavoro, spostandosi
da un capo all'altro della  citta'.
appena fuori si informa sulle condizioni del traffico presso il suo
servizio web preferito attraverso il suo telefonino abilitato al web.
Una volta in macchina sincronizza il telefonino col suo computer dibordo,
che ha anche il GPS per la localizzazione.
essendo in ritardo, oggi usa questo sistema per trovare itinerari
alternativi
che la portino in tempo in ufficio, utilizzando una interfaccia vocale
per avere le mani libere nella guida.
Dal punto di vista (DI) e' importante che la modalita' di interazione
sia diversa quando e' ferma o quando e' in viaggio;
dal punto di vista "sviluppo" la modalita' di interazione, influenzando
il contesto di trasporto, deve essere tenuta nella giusta considerazione
per comprendere come poi la pagina sara' percepita dall'utente.
-       scelta tra differenti modalita' di presentazione
Il signor Wright ha comprato due schede prepagate da 30 dollari per
i PDA abilitati al GPRS dei suoi figli, Jimmy e Tommy, perche' non
litighino quando scaricano i  "cartoons" di Dennis dal loro  sito preferito.
Litigano perche' quasi sempre Jimmy preferisce scaricarsi le immagini
ad alta risoluzione, impiegando piu' tempo  e consumando piu' presto la
scheda prepagata, mentre invece Tommy preferisce scaricarseli
sotto forma di piccole immagini a bassa risoluzione grafica che
memorizza nel pda e in seguito invia agli amici via "chat" a
messaggeria istantanea.
Dal punto di vista (DI) LE PREFERENZE DELL'UTENTE INFLUENZANO IL CONTESTO
DI TRASPORTO E PERTANTO RIENTRANO NEL CAMPO DI INDAGINE DEL GRUPPO DI
LAVORO;
DAL PUNTO DI VISTA "SVILUPPO" L'AUTORE PUO' DESIDERARE DI FORNIRE
DIFFERENTI MODI DI PRESENTARSI DELLA PAGINA IN FUNZIONE DELLE SCELTE
DELL'UTENTE; QUESTO NON DEVE ESSERE CONFUSO CON L'ADATTAMENTO CHE
AVVIENE A LIVELLO "CLIENT", ATTRAVERSO LE PREFERENZE IMPOSTATE
NELL'USER-AGEND DALL'UTENTE.
-       utilizzo di interazioni multimodali
Mr. Gray e' un esecutivo che fa il pendolare con la sua sede centrale
per partecipare a riunioni di coordinamento. oggi pero' la riunuione e'
durata piu' del solito ed egli deve cambiare la prenotazione  per il volo di
ritorno, cercandone uno successivo in serata.
si Connette dal suo telefonino abilitato al web, comunica in voce
al sistema le sue preferenze (compagnia, classe, fascia oraria,
con o senza scalo),sceglie tra le possibilita' proposte dal sistema quella
che gli aggrada attraverso scorrimento e selezione dal display grafico.
Il sistema gli conferma in voce l'avvenuta prenotazione inviando altresi'
un messaggio scritto, utilizzabile in seguito come riferimento.
Dal punto di vista (DI) il problema e' assicurare  differenti  percezioni
dell'utente in funzione della modalita' di interazione, ivi compresa
quella multimodale, mentre da un punto di vista "sviluppo" l'autore deve
tenere  nel debito  conto la possibilita' che durante una sessione di
navigazione possono essere attive anche piu' modalita' di interazione
e quindi tener conto della loro armonizzazione e sincronizzazione.
-       possibilita' di transazioni e accessi da dispositivi differenti
Angela ha sottoscritto un servizio presente sul web di una sala di
concerti che gli comunica per tempo la disponibilita' di biglietti a
prezzi scontati.
Al lavoro, la mattina, riceve l'avviso che sono disponibili  biglietti
per un concerto che include anche la quinta sinfonia di Maaler.
Era da tempo che stava aspettando l'occasione di portare sua madre,
grande estimatrice di Maaler, a un suo concerto.
Usando il suo pc prenota due biglietti in prima fila sapendo di avere 6
ore per confermare la prenotazione e provvedere al pagamento;
annota sul suo pda  il messaggio di conferma col riferimento e la relativa
url, e nel corso della giornata, ritornando in ufficio dopo l'incontro  con
un cliente, contatta la madre che si dice ben contenta della proposta e
quindi provvede tramite il pda alla conferma e al pagamento.
Da un punto di vista (DI) il sito della sala concerti e' progettato
in modo da consentire l'accesso attraverso differenti modalita' e
dispositivi,  per cui Angela ha bisogno solo di memorizzare una "uri",
indipendentemente dal dispositivo e/o meccanismo di accesso utilizzato.
Dal punto di vista "sviluppo" Il sito e' veramente "amichevole"
in quanto consente l'accesso attraverso dispositivi differenti ai suoi
servizi, inclusi quelli di criptazione  degli identificativi delle
transazioni. Una transazione puo' essere iniziata attraverso un dato
meccanismo di accesso e proseguita attraverso una o piu' altre modalita'
di interazione.
               1.7 -   La "road map" delle tappe del percorso
Come detto questo lavoro rappresenta innanzitutto un mio personale
percorso di studio, ancora nello stato iniziale, finalizzato
alla proposta, tendenzialmente collaborativa.
Dunque l'indefinito e' attualmente prevalente.
Le fasi individuate sono:
1)      Inquadramento della problematica
Il presente scritto rappresenta l'introduzione, il primo  stadio
in cui si articolera' la disamina in dettaglio delle  pubblicazioni
di cui al punto 1.5, ciascuna oggetto di relativa puntata sulle liste.
2)      Prima "last call"
alle persone che mi mostrassero interesse particolare o professionale
alla materia, ed a un certo numero di informatici, a mio giudizio,
spediro' l'intera disamina come "richiesta di commenti".
3)      definizione della mappa dei vincoli e delle dipendenze
Da solo o in compagnia disegnare la rete delle dipendenze e delle
connessioni
implicite nella analisi di cui al punto 1, utilizzando uno  schema
descrittivo tipo "pattern language".
4)      esplorare corrispondenze e sinergie tra i  pattern individuati
e i vari progetti europei, nazionali, e anche aziendali, per quel che
concerne
l'azienda da cui dipendo. Tracciare una mappa delle possibili sinergie
e collaborazioni, finanziamenti, ipotetiche partnership e
sponsorizzazioni, e quant'altro possa essere utile a motivare individui,
organizzazioni e servizi, al di fuori del semplice volontarismo
che da queste parti pero' e' sempre benvenuto.
5)      Passare finalmente alla progettazione e/o realizzazione, anche
parziale, meglio se condivisa, meglio se gestita con rigidissima metodica
costi-benefici, di una serie di servizi che soddisfino i requisiti di
indipendenza dai dispositivi, con priorita' assoluta per  applicazioni
e sviluppi di tecnologia assistiva, che soddisfino altresi'  i seguenti
vincoli progettuali di carattere generale:
- Organicita', ovvero processi costruttivi che sappiano essere parte
di un tutto;
- Partecipazione, ovvero gli utenti devono essere i protagonisti
della progettazione di tali servizi, attraverso un processo di
autocostruzione, che e' il solo in grado di assicurare una  qualita'
superiore,  nonostante (o proprio forse perche') non discenda da una
operazione pianificata in astratto, perche' riesce a esprimere
una specifica coerenza formale e culturale proprio attraverso il
linguaggio delle esigenze che manifesta.
- la crescita per parti, ovvero la capacita' di crescere attraverso
piccoli progetti limitati nel tempo, ma che permettano una crescita
unitaria del progetto attraverso  l'organizzazione gerarchica dei pattern.
- il monitoraggio periodico per seguire l'evoluzione dello sviluppo e
individuare  i contesti piu' dinamici da quelli che perdono di motivazione,
di utilita' e di gradimento.
6)      promuovere collaborazioni e partnership.
N.B. Come ben sa ogni progettista questo schema  ha solo valore
espositivo in quanto in realta' le singole fasi che qui ho delineato
non sono collegate tra loro in serie, (in cascata)  ma piu' spesso
in parallelo.


title: infoAccessibile news

author: enrico bisenzi

text:
+ Stanca: Una direttiva per la pluralita' informatica.
I documenti della PA (Pubblica Amministrazione) devono essere
disponibili e memorizzati attraverso almeno un formato aperto. Nuove
disposizioni anche per favorire il riuso del software nelle PA
<
http://web.vita.it/articolo/index.php3?NEWSID=35334
>.
+ Normativa sull'accessibilita'.
In attesa di un positivo traguardo per il ddl governativo
<
http://www.innovazione.gov.it/ita/news/2003/cartellastampa/documentazione_ddlstanca.shtml
>
oppure per l'iniziativa Campa-Palmieri
<
http://www.senato.it/leg/14/Bgt/Schede/Ddliter/18816.htm
>, le uniche
due normative redatte per ora in Italia sono la CIRCOLARE FUNZIONE
PUBBLICA e la CIRCOLARE AIPA
<
http://www.pubbliaccesso.it/sector.asp?idsezione=214
>.
+ Corso Online sui motori di ricerca.
Da settembre disponibile grazie alla piattaforma ADA sviluppata dalla
Lynx di Roma per i corsi di AltraScuola un modulo on-line sui motori di
ricerca
<
http://corsi.altrascuola.it/modules.php?name=Sections&sop=viewarticle&artid=93
>.
+ World's poor to get own search engine.
People in poor countries could soon have a new and cheap way to get hold
of the wealth of information on the internet. Researchers at the
Massachusetts Institute of Technology (MIT) are developing a search
engine designed for people with a slow net connection
<
http://news.bbc.co.uk/2/hi/technology/3065063.stm
>.
+ LIFT 2.0 in italiano.
Elimina i falsi positivi in fase di analisi del sito, genera anteprime
istantanee di come il sito verra letto dai dispositivi per disabili,
supporta il test dei template di Dreamweaver, gestisce in modo globale
tutti i tag ALT del sito, rende accessibili in automatico qualsiasi
tabella e form, integra il processo di conformita` alle legge
sull'Accessibilita Web direttamente all`interno di Dreamweaver
<
http://www.usablenet.com/frontend/demoform.jsp
>.
+ Search Engine Strategies Conference.
La prima "4 giorni" americana della Search Engine Strategies Conference
si terra' a San Jose, California, fra il 18 e il 21 del prossimo agosto.
Le prossime date ancora non sono state stabilite, ma i luoghi dovrebbero
essere Monaco e poi Chicago <
http://www.jupiterevents.com/sew/summer03/
>.
+ Crawler Microsoft avvistato in Rete.
L'azienda conferma a meta' le operazioni che il suo MSNBot ha iniziato a
compiere, per dare vita ad un indice con il quale Microsoft potra'
liberarsi di Inktomi e simili <
http://punto-informatico.it/p.asp?i=44555
>.
+ GIF libere piu' vicine.
Nei prossimi giorni il brevetto per LZW negli USA scadra' e a quanto
pare non verra' rinnovato da Unisys. Entro un anno GIF libere anche in
Europa. Cambiera' il destino di PNG
<
http://punto-informatico.it/p.asp?i=44387
> ?
+ HTML 4.01, specifiche tradotte in italiano.
I responsabili del sito Diodati.org dedicato ad accessibilita' e
internet annunciano la messa online di un importante pezzo di
conoscenza. Quasi 400 pagine da consultare <
http://punto-informatico.it/p.asp?i=43769
>.
+ Via libera all'accesso gratuito alle leggi e agli altri atti normativi
via internet.
Lo prevede un decreto del Presidente del Consiglio dei ministri,
pubblicato nella Gazzetta Ufficiale n.35 del 12 febbraio 2003. Il
provvedimento d attuazione a una norma contenuta nella Finanziaria del
2001, che dispone la costituzione di fondo presso la Presidenza del
Consiglio per promuovere l'informatizzazione e la classificazione della
normativa vigente, cosi' da facilitarne la ricerca e la consultazione
gratuita da parte dei cittadini. Il decreto prevede inoltre, la
realizzazione di portali e siti internet, corredati da motori di ricerca
<
http://www.cittadinolex.kataweb.it/Article/0,1519,22805|540,00.html
>.
--
[
http://www.infoaccessibile.com
 ]
  >>> top-ranking, corsi, consulenze, informazione accessibile in Rete


title: Scusate...

author: Overflow

text:
Ciao a tutti!!! Ma è qui che si parla di Web Usability? No perchè un
annuncio me lo fa pensare ma gli altri sembrano + spam che altro... mmm...
Beh.. Qualcuno mi faccia sapere.. :) Grazie!!!
-------------------------------------------------------
Messaggio inviato da
http://www.sandlab.org/newsgroup/
Accesso gratuito via web ai Newsgroup


title: Scusate...

author: rattus norvegicus

text:
> Beh.. Qualcuno mi faccia sapere.. :) Grazie!!!
Ovviamente nelle intenzioni questo era un gruppo che avrebbe dovuto
occuparsi di accessibilita'. Concetto originariamente piu' esteso di  web
usability. Nei fatti l'argomento, al momento, non attecchisce. Per la
questione dello spamming si dovrebbe rovistare il gruppo del GCN, ad averne
il tempo e la voglia, per capire se si puo' evitare questa iattura.
 Saluti
Rattus


title: Scusate...

text:
rattus norvegicus wrote:
> Ovviamente nelle intenzioni questo era un gruppo che avrebbe dovuto
> occuparsi di accessibilita'. Concetto originariamente piu' esteso di  web
> usability.
grazie.. sisi, lo so che sono due cose diverse, anche se personalmente
preferisco il tema dell'usaabilità
> Nei fatti l'argomento, al momento, non attecchisce. Per la
> questione dello spamming si dovrebbe rovistare il gruppo del GCN, ad averne
> il tempo e la voglia, per capire se si puo' evitare questa iattura.
dai, cerchiamo di farlo partire... mmm... vediamo che si può fare...
>  Saluti
> Rattus
Ciao!
Overflow



title: aiuto tesi di laurea

author: tsubasa

text:
Salve a tutti,
mi chiamo Emanuele ed ho bisogno di un aiuto per la mia tesi di laurea.
Sono un laureando della Facoltà di Psicologia 1, all'università di Roma "La
Sapienza", in collaborazione con la cattedra di "Psicotecnologie per
l'integrazione della disabilità" sto svolgendo parte di una ricerca
sull'usabilità di siti Internet.
Ho bisogno di utenti di Internet che siano disabili e studenti di liceo o
universitari, per rispondere ad un questionario che si trova on-line.
Quello che dovrete fare è visitare un sito che vi verrà indicato e
rispondere a delle domande, il tutto vi porterà via al massimo una decina di
minuti ed è possibile farlo dal proprio computer.
Chi fosse disposto ad aiutarmi può trovare questionario e istruzioni sul
sito
http://web.tiscali.it/tsu451/
Grazie.


title: Accessibilita' a tutto tondo.

text:
A due anni dall'approvazione della legge Stanca non si registrano
adeguamenti di rilievo sul Web italiano. Eppure l'accessibilita' Web
e' materia viva e socialmente utile ed anziche' del rispetto delle
regole si sente sempre piu' il bisogno di adeguare nuove interfacce e
tecnologie alle necessita' mutevoli delle persone e dispositivi che
accedono al Web. Ecco proposta una nuova chiave di lettura che
affronta il problema da molteplici punti di vista.
+ Teoria sull'accessibilita' Web.
Si puo' ipotizzare l'accessibilita' dell'informazione su Web come un
ciclo ricorsivo di condizioni che devono essere tutte soddisfatte
indipendentemente dalle caratteristiche sensoriali e tecnologiche
della persona o del dispositivo che accede al sito stesso.
Percezione.
La condizione di percezione e'quella piu' importante da soddisfare:
percepire e' cio' che riusciamo a recepire come informazione.
A seconda del tipo di dispositivo o di utenza ci sono diverse esigenze
di percezione: ad esempio una finestra di pop-up sara' percepita da
una persona vedente come elemento inserito in un contesto piu' ampio
dato che la finestra principale con le relative informazioni e
funzionalita' sara' sempre visualizzata anche se in background,
viceversa per un non-vedente la finestra di pop-up diventa la sola ed
unica informazione che viene percepita in quanto lo screen-reader
interpreta il solo oggetto pop-up ma non nel contesto generale e
quindi le informazioni e le funzionalita' contenute nel pop-up
diventano strategiche per il buon proseguimento della navigazione;
ancora per un vedente una pagina Web viene percepita nel suo complesso
tutta insieme mentre per un non-vedente vi e' una lettura lineare
effettuata dallo screen-reader in alcuni casi privilegiando l'elenco
dei link come lettura iniziale.
Attenzione.
L'attenzione e' la condizione che ci porta a privilegiare la lettura
di una porzione di una pagina Web piuttosto che un'altra.
Relativamente alle possibilita' sensoriali e tecnologiche delle
persone e dei dispositivi e che accedono a una pagina Web alcune
porzioni della pagina Web attraggono maggiormente l'attenzione di
altre: per un normodato la parte in alto a sinistra dello schermo, per
una persona non-vedente i link (collegamenti), per uno spider dei
motori di ricerca gli elementi strutturali e le meta-informaizoni del
sito.
Comprensione.
Un sito Web per essere considerato accessibile e' fuor di ogni dubbio
che debba essere anche comprensibile dal soggetto-target del sito: ad
esempio una comunicazione di lutto dovra' essere associata al colore
nero per la cultura nord-occidentale ma viceversa al colore bianco per
la cultura cinese, ancora... la scrittura sara' orientata da sinistra
a destra ma da destra a sinistra per le persone arabe.
Utilizzazione.
Un sito per essere utilizzabile dovra' essere usufruibile da chiunque
e l'interazione dovra' essere garantita per chiunque,
indipendentemente dalle caratteristiche sensoriali e tecnologiche
della persona o del dispositivo che accede. Ad esempio funzionalita'
dove e' richiesto l'utilizzo del mouse oppure di determinate
tecnologie come java oppure flash necessitano di alternative per chi
non ha accesso alle suddette tecnologie o non ha la possibilita' di
utilizzare il mouse. Inoltre alcune caratteristiche di usabilita' del
sito quali la presenza di una mappa del sito stesso diventano
fondamentali per permettere un utilizzo ed un'interazione corretta col
sito stesso.
Apprezzamento e stimolo.
Un sito Web per poter essere considerato accessibile deve farsi
apprezzare dall'utente finale di leggibilita' e soprattutto soddisfare
le aspettative anche estetiche di chi accede al sito. Non solo, deve
anche comunicare un messaggio di qualche tipo che sia di stimolo
all'utente finale ed invogliare una ulteriore navigazione sul sito
stesso.
Memorizzazione e tracciabilita'.
Alcuni tratti dell'informazione ospitata su un Web che ambisca ad
essere accessibile devono essere originali e fortemente mnemonici a
cominciare da nomi ed acronimi utilizzati nel titolo, dominio ed url
del sito stesso affinche' si faciliti una memorizzazione ma anche una
comoda rintracciabilita' del sito Web e dell'informazione ospitata
anche attraverso un buon posizionamnto del sito sui risultati dei
motori di ricerca relativamente ad una selezione di parole chiave
considerate strategiche rispetto al proprio target di riferimento.
Enrico Bisenzi di <
http://www.infoaccessibile.com
>, portale di
approfondimento delle tematiche trattate.


title: Accessibilita' a tutto tondo.

text:
Tutto giusto in teoria ma costoso in termine di persone e denaro.
La legge Stanca è esageratamente irrealizzabile.
Daltronde l' ha fatta Stanca che di Internet ne sa quanto Gasparri di
telecomunicazioni


title: Accessibilita' a tutto tondo.

text:
On Thu, 26 Jan 2006 16:49:23 +0100, "Kyashan71" <
kyas...@yahoo.com
>
wrote:
>Tutto giusto in teoria ma costoso in termine di persone e denaro.
sono daccordo, avendo dovuto affrontare la tematica non solo da un
punto di vista teorico ma anche come impegno professionale posso
confermare che ci deve essere sempre una mediazione fra risorse ed
obiettivi
non esistono - imho - lavori svolti bene o male ma esistono casomai
lavori svolti al  massimo delle risorse a disposizione
>La legge Stanca è esageratamente irrealizzabile.
diciamo che i requisiti sono allo stesso tempo interpretabili ma
esigenti...
e-bisenzi <
http://www.infoaccessibile.com
>


title: it.city e i terminali pubblici del Comune di Parma

author: Paul

text:
Brutti tempi a Parma per quei turisti, studenti e cittadini senza
collegamento Internet a casa che erano soliti usare i terminali
pubblici messi a disposizione dal Comune nelle biblioteche e altrove.
Una buona percentuale di terminali (al DUC) e' stata eliminata e, nel
clima antiterroristico attuale it.city ha ricevuto l'incarico di
blindare i terminali, con tanto di nickname e password e varie
limitazioni (alcune assurde, come
msn.it
 in lista nera e il poter
accedere solo ai minuti 0-15-30-45), piu' o meno giustificate, ma con
il risultato che il sistema non solo e' sorvegliato (e fin li' potrebbe
passare, se fosse sorveglitato davvero bene ...), ma spesso non
funziona o funziona male, si disconnette all'improvviso, accetta certi
siti o servizi EMail un giorno si' e uno no e a seconda del terminale,
con conseguente valanga di proteste degli utenti, una pubblicata anche
sulla Gazzetta di Parma (nella quale ci si chiede tra l'altro se simili
dissesti siano da annoverarsi tra i grandi successi della politica di
privatizzazioni etc), alla quale il Comune ha risposto che in alcuni
mesi (non giorni, ma mesi) it.city dovrebbe riuscire a sistemare tutto
nel migliore dei modi. Viene da chiedersi perhe' certa gente metta su
un'azienda prima, e non dopo, aver imparato bene il mestiere. E perche'
altri diano incarichi proprio a costoro.
Paolo


title: Touchpad esterno

text:
Ciao a tutti!
Sto cercando un Touchpad esterno per PC da collegare alla porta PS2 al
posto del mouse, per utilizzarlo come sistema di puntamento.
Qualcuno sa chi li vende o li produce? Magari mi potreste dare dei
suggerimenti.
Siccome è una richiesta per me importante, in caso di risposta per
favore replicate anche alla mia e-mail:
sava...@tin.it
 .
Grazie a tutti. Ciao!
sava...@tin.it


title: Touchpad esterno

author: Informahandicap Orzinuovi

text:
ti segnalo il sito della ditta cirque, americana... io ho un touchpad loro
che funziona benissimo. http://
www.cirque.com
ciao
Renata
<
sava...@tin.it
> wrote in message 3afbfc24...@news.libero.it...



title: Touchpad esterno

author: Cristina Sassi Vittoria Stucci

text:
guarda anche alla voce "sistemi di puntamento" di questa pagina
http://www.easylabs.it/homepage.htm
Ciao
Cristina
<
sava...@tin.it
> wrote in message 3afbfc24...@news.libero.it...



title: problemi con norton

author: mala

text:
  Salve chi ci puo aiutare a risolvere un piccolo/grande problema . E' da un
po' di settimane che il ns antivirus non fa' piu' la scansione del sistema .
Anche dopo che abbiamo rinnovato l'abbonamento nulla , funziona tutto tranne
quello . Chi ci consiglia cosa fare ????
 grazieeeeeeeeeeee
--------------------------------
Inviato via
http://arianna.libero.it/usenet/


title: campioni del mondo

author: delfino

text:
campioni del mondo
forza italia
--
--
http://www.italiansky.net/
http://it.groups.yahoo.com/group/blucoppie/
http://it.groups.yahoo.com/group/bludreamesibizioni/
http://it.groups.yahoo.com/group/bludreampiemonteamori/
http://www.ragazzeinvendita.com/index.php?refer=bludream


title: Forum senza Frame per disabili

author: BERLICCHE

text:
Salve a tutti,
sto preparando un sito web in ASP per studenti
portatori di Handicap ed ho bisogno di integrare
un forum gratuito in asp che sia sviluppato senza
l'uso dei frame (usabile se possibile)
Mi sapete indicarmene qualcuno?
Grazie mille
Alessandro


title: Forum senza Frame per disabili

author: Roberto Scano - IWA/HWG

text:
"BERLICCHE" <
berl...@hotmail.com
> ha scritto nel messaggio
news:aENQd.36111$lB4.9...@twister1.libero.it...

Sorry Phorum è in PHP :-/


title: Forum senza Frame per disabili

text:
"BERLICCHE" <
berl...@hotmail.com
> ha scritto nel messaggio
news:aENQd.36111$lB4.9...@twister1.libero.it...

Usa Phorum: noi l'abbiam testato nel sito IWA:
http://edizioni.iwa-italy.org/forum


title: [news] infoAccessibile luglio 2005

text:
Le News di infoAccessibile <
http://www.infoaccessibile.com/news.htm
>
+ Concentriamoci sulle palle…degli occhi.
... La maggior parte degli utenti che utilizza il motore di ricerca si
concentra su un ìtriangolo dorato' quando legge i risultati. Questo
triangolo attraversa tutta la riga che corrisponde al primo risultato
della pagina, passa poi alla parte sinistra della pagina stessa e
termina al di sotto in prossimita' della terza-quarta posizione – cioè
poco prima che inizi lo scorrimento naturale della pagina. Diciamo che
più che un triangolo, il percorso somiglia più ad una 'F'.
Il risultato naturalmente si ripercuote sull’efficacia dei link
sponsorizzati nella parte destra della pagina. Pochi utenti spostano
lo sguardo e li notano.
Questo conferma che gli utenti preferiscono sempre i risultati
ìnaturali' del motore di ricerca, quindi l’ottimizzazione per le
ricerche 'organiche' deve prevalere in un progetto di web marketing.
Perche' pagare per qualcosa che gli utenti notano poco ?
+ Seekport, il nuovo motore di ricerca europeo, apre in Italia.
Seekport offre un’alternativa di qualità rispetto ai motori
tradizionali. Team locali di indicizzazione, gestione attiva della
qualita' e tecnologia avanzata proteggono gli utenti dallo spam. In
contemporanea va online
www.seekport.com
, il sito per le ricerche
europee.
+ Uno dei primi siti Web ospedalieri a norma accessibilita'.
La versione accessibile del sito Web dell'Ospedale di Cefalu' e' stata
sviluppata tenendo conto delle esigenze delle persone con disabilita',
rispettando i requisiti tecnici della legge Stanca e raggiungendo
l'obiettivo del massimo livello di accessibilita' (la tripla A)
raccomandato dal W3Consoritum. Il sito e' stato sviluppato per essere
interpretato correttamente anche ingrandendo caratteri ed immagini e
allo stesso tempo diminuendo la risoluzione dello schermo inoltre e'
stato organizzato in maniera tale da offrire vari contrasti di colore
con l'intento di accontentare le esigenze di ipovedenti e persone
affette da disturbi di interpretazione dei colori di vario tipo. Gli
standard sono stati adottati con accorgimenti che facilitano
l'interpretazione corretta del sito Web: per fare un esempio le
scorciatoie da tastiera sono state appositamente indicate con dei
numeri per non entrare in conflitto con altre eventuali scorciatoie da
tastiera gia' utilizzate per il browser o per ausili di vario tipo. Il
sito Web rispetta gli standard del W3Consortium relativi alla
correttezza formale dei linguaggi di codice xhtml e css utilizzati
cosí come le raccomandazioni dello stesso W3Consortium sulle linee
guida da adottare per realizzare un sito Web realmente accessibile.
+ KDE 3.4 acquista la parola.
Il progetto KDE lancia una nuova major release che punta soprattutto a
migliorare l'accessibilita' dell'interfaccia per mezzo di una
tecnologia di sintesi vocale integrata.
+ ATutor1.5RC1 Released.
What is ATutor? ATutor is an Open Source Web-based Learning Content
Management System (LCMS) designed with accessibility and adaptability
in mind. Administrators can install or update ATutor in minutes, and
develop custom templates to give ATutor a new look. Educators can
quickly assemble, package, and redistribute Web-based instructional
content, easily retrieve and import prepackaged content, and conduct
their courses online. Students learn in an adaptive learning
environment.
+ Pubblicato il Regolamento di attuazione della Legge n.4 del 2004.
Il Regolamento di attuazione della Legge n.4 del 2004 e' stato
pubblicato sulla Gazzetta Ufficiale n.101 del 3 maggio 2005 con
Decreto del Presidente della Repubblica 1 marzo 2005, n.75.
+ Nuovo studio sulle linee guida dell'accessibilita'.
Terza versione datata dicembre 2004 per i requisiti obbligatori della
legge Stanca in attesa di essere pubblicati in Gazzetta Ufficiale.


title: [OT] Videoregistrare i sottotitoli

author: Kintaro

text:
Salve,
esiste un videoregistratore che permetta di registrare un film con i
sottotitoli del televideo, magari anche automaticamente puntandolo ad una certa
ora?
Grazie.
--
Posted from
a-bo22-62.tin.it
 [212.216.140.253]
via Mailgate.ORG Server -
http://www.Mailgate.ORG


title: corso I.Li.Tec

text:
Salve amici,
come forse saprete I.Li.Tec (Indipendent Life Technologies) si occupa
da diversi anni di tecnologie per persone con disabilita'.
Mi permetto quindi di informarvi sull'avvio di questo corso
autorizzato e finanziato dalla Regione Lazio e dall'Unione Europea per
"Esperti in ambiente Web" che si svolgera' in cinque citta' del Lazio
e che si rivolge in particolare a disabili motori e a normodotati
appartenenti a classi svantaggiate (categorie protette, disoccupati di
lunga durata).
Di seguito una parziale  bozza del bando con i riferimenti necessari.
Con preghiera di darne ampia diffusione.
Un caro saluto
Rattus
******
In data 31 Ottobre 2001 avra' inizio un corso per la formazione di
ESPERTI IN AMBIENTE WEB autorizzato e finanziato dalla Regione Lazio e
dall'Unione Europea, tenuto da I.Li.Tec, C.I.R.P.S., Enel, Hochfeiler,
nelle sedi di Civitavecchia, Latina, Frosinone, Citta' ducale (Rieti),
Viterbo.
Il corso e' riservato a candidati di eta' superiore a 18 anni iscritti
al collocamento e residenti nella Regione Lazio, con particolare
riferimento a disabili motori e normodotati appartenenti alle classi
svantaggiate (categorie protette, disoccupati lunga durata).
Il corso avra' durata complessiva di 600 ore, da suddividere in 420
ore di docenza (8 ore accademiche al giorno) e 180 di stage (per un
totale di circa 4 mesi), con obbligo di frequenza. Per ogni sede sono
disponibili 20 posti discenti piu' altri 5 per uditori.
Le domande di iscrizione dovranno pervenire entro il 20 Ottobre 2001
alla sede di Hochfeiler sistemi s.r.l., via Salaria 280, 00199 Roma.
Per quanto riguarda le preventive informazioni ci si puo' rivolgere ad
I.Li.Tec. , via Eudossiana 18 Roma, telefono 06/44585310, e-mail
Ili...@hotmail.com
.
La partecipazione al corso prevede una diaria per i discenti.


title: Checkpoint 4.3

author: Cris

text:
Per aumentare l'accessibilità di un sito web sviluppato con Domino 6, devo
settare l'attributo "lang" del tag HTML per passare il checkpoint 4.3
previsto dalla normativa. Ho fatto diversi tentativi ma non ho trovato una
soluzione per forzare Domino a generare questo attributo senza perdere la
formattazione del documento. Qualcuno ha qualche idea?
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news
 segnala gli abusi ad
ab...@newsland.it


title: Checkpoint 4.3

text:
"Cris" <
c.pi...@argonet.it
> ha scritto nel messaggio
news:csj2cq$t38$1...@news.newsland.it...
> Per aumentare l'accessibilità di un sito web sviluppato con Domino 6,
> devo
> settare l'attributo "lang" del tag HTML per passare il checkpoint 4.3
> previsto dalla normativa. Ho fatto diversi tentativi ma non ho trovato
> una
> soluzione per forzare Domino a generare questo attributo senza perdere
> la
> formattazione del documento. Qualcuno ha qualche idea?
Sembra non sia previsto (sic!):
http://www-10.lotus.com/ldd/nd6forum.nsf/0/25c68c67d9c0c8f185256f7e007a9f6d?OpenDocument
Non so per quale progetto stai lavorando ma comunque il checkpoint (aka
punto di controllo) 4.3 è richiesto dalle WCAG, non dalla legge 04/2004.
Quindi se il sito è sviluppato per le P.A. tale attributo non è
necessario (anche se è auspicabile l'utilizzo dei cambi lingua).


title: Checkpoint 4.3

author: Stefano

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:oEwHd.426788$b5.20...@news3.tin.it...

Spero che anche il DTD *Strict* dell'XHTML non sia necessario...


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:eyVHd.5729$fq5....@news.edisontel.com...
> Spero che anche il DTD *Strict* dell'XHTML non sia necessario...
Per i siti delle PA? é il requisito 1.


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:ukMId.441986$b5.21...@news3.tin.it...

Intendevo dire: "spero che ritorniate sui vostri passi e rimuoviate
quell'inutile e dispendioso vincolo"


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:VNyJd.6930$fq5....@news.edisontel.com...
> Intendevo dire: "spero che ritorniate sui vostri passi e rimuoviate
> quell'inutile e dispendioso vincolo"
Se lo chiami inutile e dispendioso, significa che purtroppo non conosci
molto bene il significato di HTML e XHTML. La DTD Strict è raccomandata
al posto della Transitional già dalle prime versioni di HTML 4.0,
proprio per garantire la separazione tra contenuto e presentazione.
Se poi gli sviluppatori non sanno produrre codice valido e/o i CMS
utilizzano MSHTML o altre amenità varie per generare contenuti, è
compito dello sviluppatore adeguare i prodotti.
E non è una fissazione italica: se guardi tutti i cms opensource seri si
stanno muovendo verso XHTML e verso lo strict.


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:t8JJd.454772$b5.21...@news3.tin.it...

http://www.cmsmatrix.org/
quali sarebbero questi CMS seri? Due o tre al massimo e a pagamento?
Scegli duecento siti web di amministrazioni pubbliche a caso e guarda quanti
di essi sono in XHTML Strict.
Inoltre se proprio vogliamo fare i seri, controlla tutti i siti dedicati
alle persone cieche e vedi quanti usano l'XHTML Strict.
Un conto è la separazione tra contenuti e presentazione ed un altro è la
fruibilità dei contenuti. Tu probabilmente fai finta di non conoscere
l'XHTML 1.0 Transational dal momento che sai benissimo che si può realizzare
un sito accessibile *realmente* a livello AAA (non solo con le solite
validazione automatiche approssimate...) anche usando quel DTD.
Le WCAG 1.0 per *non* obbligano infatti all'utilizzo della versione Strict
del XHTML. La traduzione delle parole dall'inglese è per giunta esplicitata
nel testo delle linee guida stesso (ed ovviamente sai anche questo).
Quindi "è una fissazione italica:".
Per quanto riguarda i CMS opensource uno lo sto convertendo allo strict, ma
continuo a pensare che questa imposizione per legge sia una inutile
complicazione (e con me lo pensano anche molti *tuoi* colleghi del w3c...).


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:A5VJd.7249$fq5....@news.edisontel.com...
[CUT]
> del XHTML. La traduzione delle parole dall'inglese è per giunta
esplicitata
> nel testo delle linee guida stesso (ed ovviamente sai anche questo).
mi riferisco al significato di "should" e "must"...


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:A5VJd.7249$fq5....@news.edisontel.com...
> Per quanto riguarda i CMS opensource uno lo sto convertendo allo
> strict, ma
> continuo a pensare che questa imposizione per legge sia una inutile
> complicazione (e con me lo pensano anche molti *tuoi* colleghi del
> w3c...).
Fammi nomi e cognomi... l'unico collega del W3C che sta scrivendo le
regole č il rappresentante italiano, e mi pare sia d'accordo.
Poi sai, la scelta č stata fatta da un gruppo di lavoro altamente
rappresentativo di sviluppatori, associazioni di disabili e produttori
di applicazioni.


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:D7VJd.7250$fq5...@news.edisontel.com...

Certo.... should è in raccomandazioni, must è in normative.
Uno should del 1998 è un must nel 2005... Se ti leggi per bene la storia
di come è evoluto l'HTML capirai che il transitional è una versione
"tampone" finché gli sviluppatori non inizieranno a sviluppare come si
deve...
Non per nulla in XHTML 1.1 non vi sono distinzioni.


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:hs5Kd.774543$35.30...@news4.tin.it...
>
> "Stefano" <
n...@nd.com
> ha scritto nel messaggio
> news:D7VJd.7250$fq5...@news.edisontel.com...
> >
> > "Stefano" <
n...@nd.com
> ha scritto nel messaggio
> > news:A5VJd.7249$fq5....@news.edisontel.com...
> > [CUT]
> >> del XHTML. La traduzione delle parole dall'inglese è per giunta
> > esplicitata
> >> nel testo delle linee guida stesso (ed ovviamente sai anche questo).
> >
> > mi riferisco al significato di "should" e "must"...
>
> Certo.... should è in raccomandazioni, must è in normative.
> Uno should del 1998 è un must nel 2005...
Questa frase ha lo stesso valore della frase: "un'auto volante nel 2005 è
stata creata, ma nel 2010 è obbligatoria per legge"
> Se ti leggi per bene la storia
> di come è evoluto l'HTML capirai che il transitional è una versione
> "tampone" finché gli sviluppatori non inizieranno a sviluppare come si
> deve...
> Non per nulla in XHTML 1.1 non vi sono distinzioni.
La storia l'ho letta, ma tra *storia* e *obbligo* c'è un mare in mezzo.


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:Rq5Kd.774537$35.30...@news4.tin.it...
>
> "Stefano" <
n...@nd.com
> ha scritto nel messaggio
> news:A5VJd.7249$fq5....@news.edisontel.com...
>
> > Per quanto riguarda i CMS opensource uno lo sto convertendo allo
> > strict, ma
> > continuo a pensare che questa imposizione per legge sia una inutile
> > complicazione (e con me lo pensano anche molti *tuoi* colleghi del
> > w3c...).
>
> Fammi nomi e cognomi... l'unico collega del W3C che sta scrivendo le
> regole è il rappresentante italiano, e mi pare sia d'accordo.
Parlo dei "colleghi" che hanno scritto le WCAG 1.0. Che in maggioranza hanno
deciso
di non obbligare, ai fini della conformità alle linee guida, l'utilizzo del
DTD Strict
dell'xhtml 1.0.
> Poi sai, la scelta è stata fatta da un gruppo di lavoro altamente
> rappresentativo di sviluppatori, associazioni di disabili e produttori
> di applicazioni.
Si, mi sono letto "Lo Studio" e a tale proposito vedo che hai sorvolato
opportunamente
la parte tecnica(potrei definirla "obiettiva") del post precedente.


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:xuyKd.7688$fq5....@news.edisontel.com...
> Parlo dei "colleghi" che hanno scritto le WCAG 1.0. Che in maggioranza
> hanno
> deciso
> di non obbligare, ai fini della conformità alle linee guida,
> l'utilizzo del
> DTD Strict
> dell'xhtml 1.0.
Si certamente. Si parla di WCAG 1.0 e 1999 e non si è mai parlato oggi
come oggi di questo nel gruppo di lavoro, se non di passare tutti gli
esempi delle techniques in XHTML 1.0 Strict.
> Si, mi sono letto "Lo Studio" e a tale proposito vedo che hai
> sorvolato
> opportunamente
> la parte tecnica(potrei definirla "obiettiva") del post precedente.
Ovvero?


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:7JRKd.788151$35.30...@news4.tin.it...
[CUT]
> > Si, mi sono letto "Lo Studio" e a tale proposito vedo che hai
> > sorvolato
> > opportunamente
> > la parte tecnica(potrei definirla "obiettiva") del post precedente.
>
> Ovvero?
Ovvero questo:



title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:qKTKd.7877$fq5....@news.edisontel.com...
>
http://www.cmsmatrix.org/
>
> quali sarebbero questi CMS seri? Due o tre al massimo e a pagamento?
> Scegli duecento siti web di amministrazioni pubbliche a caso e guarda
> quanti
> di essi sono in XHTML Strict.
Ho detto che stanno iniziando. Se poi vuoi il vantaggio nella
separazione tra contenuti e presentazione, fai un fischio ad Eric Meyer.
> Inoltre se proprio vogliamo fare i seri, controlla tutti i siti
> dedicati
> alle persone cieche e vedi quanti usano l'XHTML Strict.
I ciechi come tutti i soggetti con specifiche disabilità si basano solo
su ciò che va bene a loro: a loro basterebbe pure il sito solo testo
(anche se ora cominciano a capire che il sito parallelo è una porta di
servizio).
> Un conto è la separazione tra contenuti e presentazione ed un altro è
> la
> fruibilità dei contenuti. Tu probabilmente fai finta di non conoscere
> l'XHTML 1.0 Transational dal momento che sai benissimo che si può
> realizzare
> un sito accessibile *realmente* a livello AAA (non solo con le solite
> validazione automatiche approssimate...) anche usando quel DTD.
Certamente... ma a livello di normativa significa imporre maggiori punti
di controllo. Giriamo la domanda: per quale motivo, visto che si parla
di separazione tra contenuti e presentazione, non consigli lo strict a
favore del transitional?


title: Checkpoint 4.3

author: Gimpi

text:
fruibilità dei contenuti. Tu probabilmente fai finta di non
conoscere
l'XHTML 1.0 Transational dal momento che sai benissimo che
si può realizzare
un sito accessibile *realmente* a livello AAA (non solo con
le solite
validazione automatiche approssimate...) anche usando quel
DTD.
peccato che per farlo anche solo AA devi eliminare i target
... quindi finiresti per dichiarare una dtd transitional
come fosse una strict, in cui l'attributo target non è
valido. ha senso? oppure andiamo avanti ad libitum con le
finestrine e i popup?
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-avoid-pop-ups


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:L58Ld.792045$35.30...@news4.tin.it...
[CUT]
> > Inoltre se proprio vogliamo fare i seri, controlla tutti i siti
> > dedicati
> > alle persone cieche e vedi quanti usano l'XHTML Strict.
>
> I ciechi come tutti i soggetti con specifiche disabilità si basano solo
> su ciò che va bene a loro: a loro basterebbe pure il sito solo testo
> (anche se ora cominciano a capire che il sito parallelo è una porta di
> servizio).
Guarda che la legge è sull'accessibilità dei siti da parte di persone
disabili
o con problemi fisici.
Il DTD strict non porta ad alcun miglioramento in tal senso.
> > Un conto è la separazione tra contenuti e presentazione ed un altro è
> > la
> > fruibilità dei contenuti. Tu probabilmente fai finta di non conoscere
> > l'XHTML 1.0 Transational dal momento che sai benissimo che si può
> > realizzare
> > un sito accessibile *realmente* a livello AAA (non solo con le solite
> > validazione automatiche approssimate...) anche usando quel DTD.
>
> Certamente... ma a livello di normativa significa imporre maggiori punti
> di controllo.
Maggiori punti di controllo nei confronti dell' *Accessibilità* e non nei
confronti
della corsa alle novità del W3C!
Se tale DTD non porta miglioramenti immediati non ha senso obbligarne l'uso.
Per i miglioramenti futuri, sono tutti capaci di tirarli fuori: basta che si
creino altri
obblighi di legge in modo da far risultare lo Strict come vantaggioso, ma
ciò non è molto onesto
e spero non lo si faccia mai (anche se sono un po' pessimista in proposito)
> Giriamo la domanda: per quale motivo, visto che si parla
> di separazione tra contenuti e presentazione, non consigli lo strict a
> favore del transitional?
Perchè non stiamo parlando di suggerimenti ma di imposizioni normative.
Se fosse un suggerimento per il futuro potrei anche pensare di spingere
verso l'utilizzo
del DTD Strict, ma imporre con forza di legge questo significa solo perdere
del tempo
inutilmente su delle modifiche che nulla hanno a che fare con
l'accessibilità.
Ti parlo adesso con una metafora:
Non è che per ottenere 30 una legge debba richiedere 40. Se la legge
richiede 40 tale cifra devi ottenere.
Ora, poichè gli obiettivi erano il 30 non ha senso (per il raggiungimento
del 30) richiedere 40.
Questo a maggior ragione dato che il 40 non è meglio di 30.


title: Checkpoint 4.3

text:
"Gimpi" <
gi...@email.it
> ha scritto nel messaggio
news:wV8Ld.472650$b5.22...@news3.tin.it...

Perchè secondo te eliminando l'attributo target il codice diventa
automaticamente
conforme al DTD Strict???
Prova a convertire un CMS "da transational a Strict" è poi puoi parlare
con cognizione di causa delle problematiche.


title: Checkpoint 4.3

text:
Prova a convertire un CMS "da transational a Strict" è poi
puoi parlare
con cognizione di causa delle problematiche.
ok, visto che te sei bravo, esponi quali sono le
problematiche reali ... son proprio curioso. Comunque, è
transitional, non transational.


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:V3fLd.8062$fq5....@news.edisontel.com...
> Guarda che la legge è sull'accessibilità dei siti da parte di persone
> disabili
> o con problemi fisici.
E quindi?
> Il DTD strict non porta ad alcun miglioramento in tal senso.
Ah no? Non obbliga persone che forniscono strumenti che non separano
contenuto e presentazione, che utilizzano dimensioni fisse anziché in %
per le tabelle, che applicano colori a testi, sfondo, ecc. ecc.
direttamente nel markup?
> Maggiori punti di controllo nei confronti dell' *Accessibilità* e non
> nei
> confronti
> della corsa alle novità del W3C!
Guarda che non stiam parlando di XML e XSLT... stiam parlando di
XHTML... 26 gennaio 2000.
Anzi volendo stiam parlando di HTML 4.01 strict, 1999:
http://www.w3.org/TR/REC-html40/sgml/dtd.html
"This is HTML 4.01 Strict DTD, which excludes the presentation
attributes and elements that W3C expects to phase out as support for
style sheets matures."
E mi pare che il supporto ora vi sia.
"Authors should use the Strict DTD when possible, but may use the
Transitional DTD when support for presentation attribute and elements is
required."
La necessità del transitional è eliminata dall'applicazione della
sentenza precedente.
> Se tale DTD non porta miglioramenti immediati non ha senso obbligarne
> l'uso.
Ah no? Chi ha detto che non porta miglioramenti immediati?
> Per i miglioramenti futuri, sono tutti capaci di tirarli fuori: basta
> che si
> creino altri
> obblighi di legge in modo da far risultare lo Strict come vantaggioso,
> ma
> ciò non è molto onesto
> e spero non lo si faccia mai (anche se sono un po' pessimista in
> proposito)
Le motivazioni che hai portato sono debolucce eh.
> Perchè non stiamo parlando di suggerimenti ma di imposizioni
> normative.
>
> Se fosse un suggerimento per il futuro potrei anche pensare di
> spingere
> verso l'utilizzo
> del DTD Strict, ma imporre con forza di legge questo significa solo
> perdere
> del tempo
> inutilmente su delle modifiche che nulla hanno a che fare con
> l'accessibilità.
Rileggiti le differenze tra transitional e strict. Se il problema è il
CMS, rileggiti i requisiti UE per i CMS che sono molto + forti di quelli
richiesti dalla normativa italiana.
> Ti parlo adesso con una metafora:
> Non è che per ottenere 30 una legge debba richiedere 40. Se la legge
> richiede 40 tale cifra devi ottenere.
> Ora, poichè gli obiettivi erano il 30 non ha senso (per il
> raggiungimento
> del 30) richiedere 40.
> Questo a maggior ragione dato che il 40 non è meglio di 30.
Difatti, la legge chiede solo 40 su 100. Ed in questo caso quel 40 è più
che buono.


title: Checkpoint 4.3

text:
"Gimpi" <
gi...@email.it
> ha scritto nel messaggio
news:FqlLd.474618$b5.22...@news3.tin.it...
> ok, visto che te sei bravo, esponi quali sono le
> problematiche reali ... son proprio curioso. Comunque, è
> transitional, non transational.
Le ho chieste pure io ma non ha risposto.


title: Checkpoint 4.3

text:
Le ho chieste pure io ma non ha risposto.
ovvio, è un discorso che non regge. oltretutto parla di AAA,
quindi non ci sono tante possibilità.
passare da una pagina aaa valida xhtml 1.0 transictional a
una xhtml 1.0 strict non mi sembra che sia poi tutto sto
lavoro, cinque minuti è già molto, ammesso che ce ne sia
bisogno, se la pagina è davvero aaa potrebbe bastare
copia/incolla della dichiarazione del doctype ... credo
anche che ci sia un po' di confusione fra il concetto di
pagina validata xhtml qualcosa e pagina valutata aaa, ma
transit.
bò, ci dirà.


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:XJlLd.474665$b5.22...@news3.tin.it...
>
> "Stefano" <
n...@nd.com
> ha scritto nel messaggio
> news:V3fLd.8062$fq5....@news.edisontel.com...
> > Guarda che la legge è sull'accessibilità dei siti da parte di persone
> > disabili
> > o con problemi fisici.
>
> E quindi?
>
> > Il DTD strict non porta ad alcun miglioramento in tal senso.
>
> Ah no? Non obbliga persone che forniscono strumenti che non separano
> contenuto e presentazione, che utilizzano dimensioni fisse anziché in %
> per le tabelle, che applicano colori a testi, sfondo, ecc. ecc.
> direttamente nel markup?
Questi che hai elencato sono altri requisiti delle WCAG1.0 e persino dei tuo
Studio
realizzabili senza DTD Strict.
Per cui oltre ad essere ridondante per questi requisiti è anche dannoso
perchè obbliga a seguire
uno standard che non porta dei vantaggi in termini di accessibilità, dal
momento che tutti gli altri
requisiti devono essere soddisfatti.
[CUT]
> "Authors should use the Strict DTD when possible, but may use the
> Transitional DTD when support for presentation attribute and elements is
> required."
>
> La necessità del transitional è eliminata dall'applicazione della
> sentenza precedente.
Stiamo parlando di XHTML.
E non stiamo parlando di attributi ed elementi di presentazione, ma di
piccole
differenze (tipo l'eliminazione dell'attributo name nei form) che implicano
un grosso lavoro di adattamento.
> > Se tale DTD non porta miglioramenti immediati non ha senso obbligarne
> > l'uso.
>
> Ah no? Chi ha detto che non porta miglioramenti immediati?
E' un dato di fatto.
> > Per i miglioramenti futuri, sono tutti capaci di tirarli fuori: basta
> > che si
> > creino altri
> > obblighi di legge in modo da far risultare lo Strict come vantaggioso,
> > ma
> > ciò non è molto onesto
> > e spero non lo si faccia mai (anche se sono un po' pessimista in
> > proposito)
>
> Le motivazioni che hai portato sono debolucce eh.
Più che debolucce direi che sono gravi se soddisfatte.
> > Perchè non stiamo parlando di suggerimenti ma di imposizioni
> > normative.
> >
> > Se fosse un suggerimento per il futuro potrei anche pensare di
> > spingere
> > verso l'utilizzo
> > del DTD Strict, ma imporre con forza di legge questo significa solo
> > perdere
> > del tempo
> > inutilmente su delle modifiche che nulla hanno a che fare con
> > l'accessibilità.
>
> Rileggiti le differenze tra transitional e strict. Se il problema è il
> CMS, rileggiti i requisiti UE per i CMS che sono molto + forti di quelli
> richiesti dalla normativa italiana.
Indicami un solo documento normativo avente forza di legge dell'unione
europea che
richiede delle specifiche tecniche più stringenti per i CMS rispetto alle
richieste dello "studio".
(La risposta è che ovunque si parla sono di WCAG1.0)
> > Ti parlo adesso con una metafora:
> > Non è che per ottenere 30 una legge debba richiedere 40. Se la legge
> > richiede 40 tale cifra devi ottenere.
> > Ora, poichè gli obiettivi erano il 30 non ha senso (per il
> > raggiungimento
> > del 30) richiedere 40.
> > Questo a maggior ragione dato che il 40 non è meglio di 30.
>
> Difatti, la legge chiede solo 40 su 100. Ed in questo caso quel 40 è più
> che buono.
Beh, dovrebbe essere giusto che se ho utilizzato una metafora stupida, anche
la risposta che ho ottenuto
sia altrettanto stupida. No?


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:SJlLd.474664$b5.22...@news3.tin.it...

Strano, in quasi tutti i post ti ho ripetuto che si tratta di rivedere tutto
il codice del CMS per verificare che gli script server side non utilizzino
per il loro funzionamento degli attributi deprecati.
Fai orecchie da mercante?


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:atzLd.8283$fq5....@news.edisontel.com...
Tralascio le altre cose, visto che si insinua che tra le difficoltà
maggiori vi è la rimozione dell'attributo name dai form...
> Indicami un solo documento normativo avente forza di legge dell'unione
> europea che
> richiede delle specifiche tecniche più stringenti per i CMS rispetto
> alle
> richieste dello "studio".
>
> (La risposta è che ovunque si parla sono di WCAG1.0)
Informati meglio. Si parla di conformità alle ATAG 1.0, tra l'altro
senza nemmeno specificarne il livello minimo.
www.robertoscano.info/files/atag10
Comunque ecco uno dei tanti riferimenti:
http://europa.eu.int/information_society/topics/citizens/accessibility/web/wai_2002/ep_res_web_wai_2002/index_en.htm
punto 4.
"Considers that the WAI initiative, which is voluntary in nature, should
be strengthened to require, on a mandatory basis, all public websites of
the EU institutions and the Member States to be fully accessible to
disabled persons by 2003, which is the European Year of Disabled people;
furthermore, calls on the EU institutions and the Member States to
comply with the authoring tools accessibility guidelines (ATAG) 1.0 by
2003 as well, in order to ensure that disabled people can read webpages
and also to enable them to manage the content of the webpages (content
management);"
> Beh, dovrebbe essere giusto che se ho utilizzato una metafora stupida,
> anche
> la risposta che ho ottenuto
> sia altrettanto stupida. No?
Non ti cito forrest gump... se hai visto il film sai qual'è la frase
idonea a risponderti.


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:MvzLd.8284$fq5....@news.edisontel.com...
> Strano, in quasi tutti i post ti ho ripetuto che si tratta di rivedere
> tutto
> il codice del CMS per verificare che gli script server side non
> utilizzino
> per il loro funzionamento degli attributi deprecati.
>
> Fai orecchie da mercante?
No, fai tu il sordo. In ogni caso qualsiasi cosa gira su tecnologia
internet dovrà rispettare i 22 requisiti. Questo, ripeto, non l'ha
deciso Scano ma il gruppo di lavoro all'unanimità.


title: Checkpoint 4.3

author: Little-John

text:
Il Tue, 01 Feb 2005 00:48:13 +0100, Stefano ha scritto:
> Stiamo parlando di XHTML.
 che è quindi XML
> E non stiamo parlando di attributi ed elementi di presentazione, ma di
> piccole differenze (tipo l'eliminazione dell'attributo name nei form)
> che implicano un grosso lavoro di adattamento.
 sed, grep, awk
 cheers
--
If Java had true garbage collection, most programs would delete
themselves upon execution. (Robert Sewell)


title: Checkpoint 4.3

text:
 sed, grep, awk
vabbè anche trova/sostituisci andava bene dai :-), come si
diceva, 5 minuti di lavoro.
Comunque è vero che lo strict non riguarda l'accessibilità,
se si parla di accessibilità in soli termini di disabilità.
Il fatto è che l'accessibilità riguarda tutti, e che un sito
in strict sia molto più accessibile (accessibile da accesso)
a qualsiasi user agent non ci piove, è molto facilmente
dimostrabile, basta guardare il markup di un sito strict e
quello di un transitional: quale è più pulito?. Ebbasta con
gli appicciconi, e basta col markuppe di dieci anni fa che
fra un po' non funzionerà più nemmeno con linx.
Un solo piccolo motivo per usare strict? la dtd transitional
già da xhtml 1.1 (rilasciato in maggio 2001, non ieri, 4
anni fa) non esiste più, in xhtml altrettanto e mai più
ritornerà e non ritornerà per tutto il markup da qui
all'eternità. Per quale motivo? semplice, HTML è morto dal
1999, non verrà mai più sviluppato, bisogna rendersene
conto. Vogliamo andare avanti a fare siti obsoleti facendoli
passare come fosse l'ultimo ritrovato tecnico? ok, basta
esserne consapevoli e non fare pagare ai clienti le proprie
ignoranze, che poi si fanno pagare a tutti.
XHTML 1.0 Transitional is the more forgiving XHTML flavor.
Unlike Strict, which completely separates structure from
presentation, Transitional allows you to use tags to control
the look of your markup.
*Its goal is bridging the gap between HTML-based pages that
allow the markup to control the presentation and XHTML
Strict*
which does not. Its main benefit is that it overcomes
Strict's CSS dependence. Transitional pages are still
accessible to users who use older browsers or who are using
devices that don't recognize style sheets.
per chi si occupa di web, non ci dovrebbe nemmeno essere
bisogno di parlarne.La transitional serviva soltanto per
permettere ai lenti di passare a xhtml strict, ovvero alle
strette regole di xml.
Parlando di cms poi non ci dovrebbe essere nemmeno il
dubbio: un cms transitional è semplicemente ... roba
vecchia.


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:D8HLd.803080$35.31...@news4.tin.it...

Informati meglio, quello non è un atto avente forza di legge dell'unione
europea.
Non mi riferisco tanto al "should" quanto al fatto che quello che hai
riportato sono indicazioni di massima
che gli stati membri dovrebbero seguire. Per questo non trovi il livello
minimo.
Per diventare efficace, deve esserci una direttiva ed un recepimento di tale
direttiva attraverso una legge italiana
che non esiste.


title: Checkpoint 4.3

text:
"Little-John" <
ahh...@hihih.com
> ha scritto nel messaggio
news:pan.2005.02.01....@hihih.com...
> Il Tue, 01 Feb 2005 00:48:13 +0100, Stefano ha scritto:
> > Stiamo parlando di XHTML.
>
>  che è quindi XML
XHTML *NON* è XML
> > E non stiamo parlando di attributi ed elementi di presentazione, ma di
> > piccole differenze (tipo l'eliminazione dell'attributo name nei form)
> > che implicano un grosso lavoro di adattamento.
>
>  sed, grep, awk
Si, provali e vedrai che tutto funziona a meraviglia.... in teoria.


title: Checkpoint 4.3

text:
"Gimpi" <
gi...@email.it
> ha scritto nel messaggio
news:nYQLd.482650$b5.22...@news3.tin.it...
> sed, grep, awk
>
> vabbè anche trova/sostituisci andava bene dai :-), come si
> diceva, 5 minuti di lavoro.
Perchè parlate, parlate e basta senza pensare?
Se ci volessero 5 minuti di lavoro o anche una sola ora sarebbe già uscito
il primo cms open source che genera codice in XHTML1.0 Strict.
> Comunque è vero che lo strict non riguarda l'accessibilità,
> se si parla di accessibilità in soli termini di disabilità.
> Il fatto è che l'accessibilità riguarda tutti, e che un sito
> in strict sia molto più accessibile (accessibile da accesso)
> a qualsiasi user agent non ci piove, è molto facilmente
> dimostrabile, basta guardare il markup di un sito strict e
> quello di un transitional: quale è più pulito?.
Guarda se questo è il livello di discussione mi fermo a questo post.
Accessibile non significa che il codice HXTML debba essere facilmente
interpretabile da un essere umano.

E' semplicemente una tristezza che dei professinisti parlino
in questo modo. Quelli che hai usato sono solo slogan pubblicitari che non
hanno nessun senso nel contesto dell'accessibilità.
Esistono newsgroup appositi per discutere di "tendenze" e di "mode"
in cui potrai trovarti a tuo agio.
Argomentazioni tipo: "il futuro dovrebbe andare in quella o questa
direzione" senza tener conto delle effettive problematiche di
implementazione ma anche di fruizione dei contenuti non sono nemmeno da
considerare.
Saluti.


title: Checkpoint 4.3

text:
"Roberto Scano - IWA/HWG" <
rsc...@iwa-italy.org
> ha scritto nel messaggio
news:_aHLd.803094$35.31...@news4.tin.it...
>
> "Stefano" <
n...@nd.com
> ha scritto nel messaggio
> news:MvzLd.8284$fq5....@news.edisontel.com...
>
> > Strano, in quasi tutti i post ti ho ripetuto che si tratta di rivedere
> > tutto
> > il codice del CMS per verificare che gli script server side non
> > utilizzino
> > per il loro funzionamento degli attributi deprecati.
> >
> > Fai orecchie da mercante?
>
> No, fai tu il sordo. In ogni caso *qualsiasi cosa gira su tecnologia
> internet* dovrà rispettare i 22 requisiti. Questo, ripeto, non l'ha
> deciso Scano ma il gruppo di lavoro all'unanimità.
Per fortuna nell'impeto di rispondermi ti sei sbagliato, altrimenti sarebbe
stato terribile.


title: Checkpoint 4.3

text:
"Stefano" <
n...@nd.com
> ha scritto nel messaggio
news:GBULd.105$hd4...@news.edisontel.com...
> Se ci volessero 5 minuti di lavoro o anche una sola ora sarebbe già
> uscito
> il primo cms open source che genera codice in XHTML1.0 Strict.
Forse perchè non ci sono sviluppatori opensource in Italia a cui
interessa rendere disponibili cms a norma di legge italiana? Questo
dovrebbe essere uno stimolo per chi sviluppa.


title: Checkpoint 4.3

author: Spirito Libero

text:
Stefano ha scritto:
> "Little-John" <
ahh...@hihih.com
> ha scritto nel messaggio
> news:pan.2005.02.01....@hihih.com...
>
>>Il Tue, 01 Feb 2005 00:48:13 +0100, Stefano ha scritto:
>>
>>>Stiamo parlando di XHTML.
>>
>> che è quindi XML
>
>
> XHTML *NON* è XML
>
Dal sito W3C: "With a wealth of features, XHTML 1.0 is a reformulation
of HTML 4.01 in XML, and combines the strength of HTML 4 with the power
of XML."
Se leggi tutta la pagina, seguendo eventualmente i vari link, puoi
notare che il W3C incoraggia l'utilizzo del prologo <?xml> nei documenti
XHTML. L'ideale sarebbe di fornire come mime-type quello corretto per
xml ovvero text/xml oppure application/xml e di salvare i documenti
creati con l'estensione xml.
Sul discorso dell'accessibilita' e dei dtd strict e transitional. Posso
solo dire di essere il terzo, in questo 3d, ad affermare che se da un
doctype transitional togli gli attributi propri dei frame, chiudi tutti
i tag, utilizzi i tag in maniera semantica (<p> per i paragrafi, <hx>
per i titoli), di fatto stai scrivendo in strict. Perche' allora mandare
i browser in quirk mode con un codice di fatto strict e quindi standard?
E' vero che l'accessibilita' non si ferma al doctype, ma e' vero anche
che alcuni elementi presenti nei documenti transitional, siano essi html
o xhtml e, peggio ancora, nei frameset, non permettono una perfetta
fruizione della pagina web da parte di alcune categorie di utenti e non
perforza i "ciechi". Utilizzando una struttura xhtml strict, la
visibilita' si estende senza alcuno sforzo, a tutti gli User Agent che
supportano XML (palmari, UMTS, lettori ottici, ecc.) permettendo allo
stesso tempo ad una maggiore evoluzione sia alle tecnologie sul web
(linguaggi lato-server, cms) sia alle tecnologie software di fruizione
dei contenuti.
--
Spirito Libero
Siamo tutti un po' abusivi a questo mondo...
(Ocio: ho cambiato l'indirizzo)


title: Checkpoint 4.3

text:
"Spirito Libero" <
spirit...@despammed.com
> ha scritto nel messaggio
news:ue5Md.812703$35.31...@news4.tin.it...
> Stefano ha scritto:
> > "Little-John" <
ahh...@hihih.com
> ha scritto nel messaggio
> > news:pan.2005.02.01....@hihih.com...
> >
> >>Il Tue, 01 Feb 2005 00:48:13 +0100, Stefano ha scritto:
> >>
> >>>Stiamo parlando di XHTML.
> >>
> >> che è quindi XML
> >
> >
> > XHTML *NON* è XML
> >
>
> Dal sito W3C: "With a wealth of features, XHTML 1.0 is a reformulation
> of HTML 4.01 in XML, and combines the strength of HTML 4 with the power
> of XML."
>
> Se leggi tutta la pagina, seguendo eventualmente i vari link, puoi
> notare che il W3C incoraggia l'utilizzo del prologo <?xml> nei documenti
Hai ribatito quanto ho scritto e cioè XHTML non è XML.
> XHTML. L'ideale sarebbe di fornire come mime-type quello corretto per
> xml ovvero text/xml oppure application/xml e di salvare i documenti
> creati con l'estensione xml.
L'ideale per chi??
> Sul discorso dell'accessibilita' e dei dtd strict e transitional. Posso
> solo dire di essere il terzo, in questo 3d, ad affermare che se da un
> doctype transitional togli gli attributi propri dei frame, chiudi tutti
> i tag, utilizzi i tag in maniera semantica (<p> per i paragrafi, <hx>
> per i titoli), di fatto stai scrivendo in strict. Perche' allora mandare
> i browser in quirk mode con un codice di fatto strict e quindi standard?
Perchè i codici di molti CMS utilizzano degli attributi non coinvolti nel
problema dell'accessibilità, deprecati nello strict ma validi nel
transational. Quindi ci sarebbe del lavoro inutile e lungo da fare senza
benefici immediati.
> E' vero che l'accessibilita' non si ferma al doctype, ma e' vero anche
> che alcuni elementi presenti nei documenti transitional, siano essi html
> o xhtml e, peggio ancora, nei frameset, non permettono una perfetta
> fruizione della pagina web da parte di alcune categorie di utenti e non
> perforza i "ciechi".
Nessuno ha mai parlato di frame e nemmeno di attributi che possono creare
problemi di accessibilità.
> Utilizzando una struttura xhtml strict, la
> visibilita' si estende senza alcuno sforzo, a tutti gli User Agent che
> supportano XML (palmari, UMTS, lettori ottici, ecc.) permettendo allo
> stesso tempo ad una maggiore evoluzione sia alle tecnologie sul web
> (linguaggi lato-server, cms) sia alle tecnologie software di fruizione
> dei contenuti.
Beh, senza alcuno sforzo è una parola molto grossa...
Il supporto pieno non è poi così diffuso.