Commenti alla bozza dell'AIPA sull'accessibilità dei siti Web.

Commento di "Access To Web" (http://www.ecn.org/xs2web/) alla Bozza dell'Autorità per l'Informatica nella Pubblica Amministrazione sull'accessibilità.

PREMESSA

Prima di effettuare il nostro commento alla Bozza "Strumenti per migliorare l'accessibilità", vorremmo fare una breve analisi delle motivazioni che hanno reso oggi necessaria la suddetta. Tale premessa non ha scopi storici, bensì, operativi. Riteniamo che allo stato attuale, il problema dell'accessibilità a internet, in generale, e ai servizi offerti dalle Pubbliche Amministrazioni (PPAA), nel caso specifico, pur essendo già di una certa entità, è solo agli inizi. Nei prossimi anni la conversione e l'accesso, ai tanti database delle PPAA, attraverso le reti telematiche porteranno ad un' inevitabile "esplosione" del problema. Ci sembra quindi utile analizzare la situazione attuale, e ricercare le cause che hanno reso tale situazione già problematica, al fine di consentire l'attuazione di una migliore strategia di soluzione del problema.

Oggi ci sembra di poter rintracciare le origini della attuale situazione in tre grosse aree:

a) la disconoscenza del problema e delle tecniche per la soluzione

b) la superficiale, o mancata, applicazione degli attuali standard

c) il ricorso a strumenti di sviluppo non appropriati

Nell'immediato ci sembra possibile agire direttamente solo sul punto B, attraverso una Normativa che "vincoli" la corretta applicazione di quanto previsto dalla presente bozza, e, più in generale, da quanto accettato dalla comunità internazionale in fatto di accessibilità, contenuto nelle indicazioni del Web Accessibility Initiatives (WAI) del World Wide Web Consortium (W3C). Rimane, però, molto lavoro da fare per i punti A e C. Lavoro che non potrà dare i propri frutti se non nel medio e lungo periodo. Ci sentiamo però, fin d'ora, di segnalare la necessità di considerare, organicamente ed operativamente, l'aspetto della "formazione professionale" quale obiettivo da perseguire primariamente per una organica soluzione dei problemi PPAA e accessibilità delle risorse di rete.

COMMENTO

Il problema dell'accessibilità è un problema molto complesso che coinvolge, non solo i non vedenti e gli ipovedenti, i quali necessitano di hardware e software di ausilio, peraltro di vario tipo e con caratteristiche di accesso ai documenti in Rete molto diverse fra loro, ma la popolazione tutta, anche se con gradi diversi di importanza, almeno allo stato attuale. Rendere un documento accessibile in senso universale in Rete, sul World Wide Web (WEB), è un'impresa ardua e una scelta politica forte, ma appropriata per una PA che, per sua natura deve soddisfare i bisogni di informazione e comunicazione di TUTTA la sua cittadinanza. Questo significa anche per quella parte, seppur minoritaria, che:

Sono categorie di clienti, o di utenti, del nostro sito, oltre che strumenti di amplificazione delle informazioni, come nel caso dei motori di ricerca, (i quali necessitano del rispetto degli standard per essere efficaci), categorie che seppur minoritarie hanno gli stessi diritti di un'ipotetica maggioranza che ha tempo, connettività, soldi, risorse fisiologiche "perfette", hardware, ecc. da spendere in quantità, anche se, tale categoria di utenti, ci pare più ipotetica che reale. Peraltro, se come sembra stanno per passare leggi e regolamenti che rivendicano il diritto del cittadino ad accedere alla documentazione della Pubblica Amministrazione online, stiamo solo affrontando un lato del problema, dimenticandoci che dovrebbero essere messe in moto anche delle politiche orientate a garantire, attraverso punti di accesso telematici pubblici, capillarmente distribuiti nel territorio, l'accesso alla Rete a chi, purtroppo esistono anche di questi soggetti, non ha facile accesso alle risorse poc'anzi elencate.

Per una migliore fruibilità dettagliamo puntualmente i commenti specifici alla Bozza. La bozza "Strumenti per migliorare l'accessibilità" ci pare:

a) troppo orientata verso le problematiche legate ai non vedenti, che, lo riconosciamo, sono molto interessati dal problema, ma sempre e solo, uno dei soggetti legati all'argomento accessibilità.

b) troppo orientata verso le problematiche legate alla multimedialità, che, seppure rappresenta l'aspetto più appariscente del web, non rappresenta certo per delle PA la materia prima di pubblicazione.

c) non chiarisce che gli attuali standard di accessibilità del W3C [nota 1 a fondopagina] e del progetto Trace [nota 2 a fondopagina], consentirebbero di rendere accessibile a tutti una qualsiasi risorsa, indipendentemente da aspetti psico-fisici e tecnologici, sia per il presente, che per diversi anni a venire.

d) non dettaglia e sviluppa l'argomento degli equivalenti testuali, e dell'uso delle immagini testuali. Due argomenti di fondamentale importanza per le problematiche legate all'accessibilità [nota 3 a fondopagina]

e) non dettaglia e sviluppa l'argomento uso delle tabelle per la creazione del layout di pagina, che è oggi, de facto, lo standard in uso [nota 4 a fondopagina]

f) non afferma che nel caso di uso delle tabelle per la tabulazione dei dati è da prevedersi una versione alternativa linearizzata.

g) non dettaglia e sviluppa i differenti usi che si possono fare delle immagini, non distinguendo le immagini decorative, a contenuto, testuali, a mappa sensibile, ecc.

h) non dettaglia e chiarisce gli standard a cui tale Bozza si riferisce, che, date le premesse di approccio diverso, basato sul "punto di vista" degli utenti, è fondamentale per dare unità e corpo alla proposta.

i) non dettaglia e sviluppa l'argomento risorse lato server, che pure, allo stato attuale, rappresenta la soluzione immediata, totale e a basso costo, del problema accessibilità.

l) non dettaglia e sviluppa l'argomento risorse scaricabili, pur riconoscendo la valenza di queste e propone inspiegabilmente l'uso di prodotti proprietari, e basati su compatibilità solo "dall'alto in basso" e non viceversa.

m) non dettaglia e sviluppa l'argomento tools di validazione della accessibilità e correzione codifica html, css e script [nota 5 a fondopagina]

n) non dettaglia e sviluppa l'argomento usabilità dei siti web, neanche nella sua componente più importante, ossia, i tempi di attesa per gli utenti e la navigabilità di un sito [nota 6 a fondopagina]

o) non contempla in modo appropriato le possibilità offerte dai diversi sistemi operativi, fra cui Linux e Macintosh; essendo tale Bozza generale, riteniamo questa una lacuna inevitabilmente da colmare [nota 7 a fondopagina]

p) sull'uso dei CSS, non chiarisce che è indispensabile verificare che la pagina prodotta sia correttamente interpretabile anche da browser in cui non sia abilitato il supporto per i CSS

q) sulle componenti multi-mediali, non viene chiarito che nei filmati audio video le "componeneti alternative di segnalazione" devono essere sincronizzate rispetto allo scorrere delle immagini e dei dialoghi.

r) sull'uso dei frame, non viene dettagliata e chiarita la funzione del comando noframe, uno dei più grossi problemi di accessibilità ai siti che utilizzano tale struttura [nota 8 a fondopagina]

s) sull'uso dei linguaggi, non viene segnalata l'utilità, soprattutto per i documenti (non mi viene il termine: multilinguistici), di utilizzare i marcatori sui linguaggi naturali (attributo lang) e specificare lo scioglimento di ogni abbreviazione (acronym e title)

t) sull'uso delle form, non dettaglia e specifica che, al fine di renderne più facile l'uso, i campi editabili dovrebbero essere pre-compilati da testo di esempio, e che, in caso di una form complessa per ottenere informazioni dettagliate dall'utente è da prevedersi anche una versione txt da scaricare, compilare e inviare via email

Note a fondopagina per l'approfondimento

[nota 1] Web Accessibility Initiatives http://www.w3.org/WAI/

[nota 2] Il progetto Trace http://www.trace.wisc.edu/index.html

[nota 3] Use of ALT texts in IMGs http://ppewww.ph.gla.ac.uk/~flavell/alt/alt-text.html

[nota 4] Ricerca di xs2web sui comandi html maggiormente usati http://www.ecn.org/xs2web/ricerche.htm

[nota 5] Delorie Software http://www.delorie.com/web/
Center for Applied Special Technology http://www.cast.org/bobby/
HTML Validation Service http://validator.w3.org/

[nota 6] Le news del CLARR, progetto valutazione usabilità http://users.iol.it/buste/clarr/rel_usab.htm

[nota 7] Apple, People with Special Needs http://www.apple.com/education/k12/disability/
Linux, Il progetto Ocularis http://ocularis.sourceforge.net/
Linux Access HOWTO http://www.pluto.linux.it/ildp/HOWTO/Access-HOWTO.html

[nota 8] Le news del CLARR, ricerca sull'uso dei frame http://users.iol.it/buste/clarr/rel_fram.htm
Le news del CLARR, ricerca sui tools di sviluppo http://users.iol.it/buste/clarr/rel_tool.htm

Siti generali di approfondimento

Best viewed http://www.anybrowser.org/campaign/anybrowser_it.html

All Things Web http://www.pantos.org/atw/

GVU's Eighth WWW User Survey Use Bulleted List http://www.gvu.gatech.edu/user_surveys/survey-1997-10/bulleted/use_bullets.htm

Jakob Nielsen's Website http://www.useit.com/

Problematiche reali e soluzioni tecniche a cura di Laura Burzagli e Paolo Graziani http://etabeta.iroe.fi.cnr.it/accesso/accesso.htm

Cordiali Saluti, xs2webcrew
www.ecn.org/xs2web/

| torna su |

COMMENTO DEL CLARR

Premessa

Questo commento alla "Bozza per una normativa sull'accessibilità dei sistemi informatici" (nel seguito del documento Bozza), è suddiviso in 3 parti:

1) Prospettiva di osservazione, in cui è riportato il nostro punto di vista, al fine di fornire da subito una chiave di lettura dei commenti e delle proposte di modifica effettuate.

2) Commento alla Bozza, in cui è riportato il commento a quelle che sono le premesse, la forma ed il livello di approfondimento dei contenuti, evidenziando quelli che riteniamo essere i limiti dell'attuale modello normativo.

3) Suggerimenti per la modifica, in cui sono riportati i cambiamenti a livello generale che apporteremmo alla presente Bozza.

1) Prospettiva di osservazione

Riteniamo che il ritardo accumulato dalle Pubbliche Amministrazioni, e non solo, in fatto di accessibilità delle risorse web, sia oggi così ampio da rischiare di rendere tale bozza "sorpassata" prima ancora che sia ufficializzata. Molti punti qui affrontati avrebbero dovuto essere discussi diversi anni addietro, quando ancora non si intravedevano i possibili sviluppi, futuri sì, ma ormai prossimi, della rete. In particolare riteniamo che i progetti di informatizzazione diffusa degli ambienti abitativi, educativi, formativi e lavorativi, così come lo sviluppo della telefonia mobile, rendano necessario un forte richiamo alla 'forward compatibility' rivedendo molti dei presunti standard attuali. Il termine di 'forward compatibility' è usato qui per significare compatibilità con il futuro e non con il passato, come qualcuno intende il termine ufficiale di "backward compatibility". D'altronde, gli esperti di usabilità applicata al web hanno da tempo delineato quelli che sono gli aspetti salienti delle risorse web, e parlare oggi di accessibilità senza inserirla nel più ampio concetto di usabilità sarebbe un errore.

2) Commento alla Bozza

2.1) Commento generale alla bozza

A nostro avviso questa bozza non ha i requisiti necessari per un documento operativo sugli "Strumenti per migliorare l'accessibilità" in quanto non viene chiarito a chi esso sia rivolto e con quale scopo. Nel documento viene più volte fatto riferimento a 'chi gestiscè un sito per la PA, e al grado di conoscenza delle tecniche del W3C, a cui si rimanda chi è in grado di utilizzarle. Se ne deduce che il target di questo documento siano i webmaster, non abbastanza esperti da utilizzare le Guide line del W3C. Date queste premesse il documento dovrebbe essere prescrittivo, oltre che informativo. Di fatto ciò non è vero. Dei singoli punti di controllo per l'accessibilità viene data soltanto una sommaria descrizione teorica, che spesso risulta anche superficiale. Si nota poi una non chiara presa di posizione rispetto al concetto di accessibilità per tutti, che viene spesso riferita ai "disabili della vista". Pensiamo che una Bozza sull'accessibilità dovrebbe essere generale e specificare di volta in volta le esigenze di gruppi particolari di utenti, comprendendo anche chi non può usufruire di strumenti standard, come palmari, computer poco potenti, computer molto potenti ma usati da più persone, ecc. Una nota a parte circa la forma data alla presente bozza. Riteniamo che la attuale forma non sia molto usabile, infatti gli "allegati" di approfondimento non sono linkati alla pagina, e non consentono la scelta della lettura in modalità sequenziale, o ipertestuale. Nessuna nota specifica che tali allegati si trovano alla fine della pagina. Vista la lunghezza del documento, avvertiamo anche la mancanza di un "riassunto" in apertura di Bozza. Va altresì detto che tale Bozza è stata inserita in un sito non conforme agli stessi standard qui esposti.

2.2) Commento alle regole di accessibilità dei siti Web pubblici

Ciò che lascia un po' perplessi è che in tutto il documento non viene fatto che un brevissimo cenno a quello che ci pare il punto cruciale del problema accessibilità-usabilità: la progettazione di un sito web. Infatti nella sezione "regole di accessibilità" non viene fatto nessun cenno alla questione. Di fatto il documento pone la "pagina" al centro della progettazione accessibile. Eppure nel documento viene ben chiarito, anche economicamente, che la fase migliore per occuparsi di accessibilità-usabilità è proprio la fase di progettazione.

2.3) Commento al concetto di accessibilità strumentale

La definizione riportata dovrebbe essere uno strumento cognitivo di valutazione dell'accessibilità di un sito, ma poi elenca semplicemente degli strumenti, senza spiegare come utilizzarli. Il semplice utilizzo di un browser di per sé non modifica l'accessibilità di un sito, e se non meglio precisati i 'parametri di osservazione' potrebbe anche non avere nessuna utilità pratica.

2.4) Commento al riferimento ai programmi e sistemi operativi

Non abbiamo trovato alcun cenno ai programmi per il sistema operativo Macintosh, né per i pacchetti applicativi per Linux. Tale mancanza non è commentata. Va poi notato che viene riconosciuta la possibilità di fornire una versione scaricabile di un sito, ma nulla viene detto sulla costruzione dei nomi di directory e files. Dal momento che nella Bozza si parla di "disabili", siano essi motori che sensitivi, non si può trascurare chi utilizza software non previsti dalla bozza.

3) Suggerimenti per la modifica

Secondo noi la Bozza andrebbe modificata secondo le seguenti linee programmatiche:

a) inserire correttamente "la questione" handicap nel più ampio contesto accessibilità alle risorse web, per tutti, disabili o meno.

b) dettagliare il target di questo documento e strutturarlo in modo da essere adeguato ai compiti formativi, prescrittivi e operativi, che esso dovrà svolgere.

c) specificare operativamente il concetto di "accessibilità strumentale" al fine di fornire strumenti tecnico-cognitivi atti alla valutazione dell'accessibilità.

d) specificare in modo chiaro (visto che nella Bozza non è mai espresso) a quali standard la presente si riferisce, in particolare rimuovere le ambigue definizioni di "livello minimo" accostate ai concetti del W3C senza però fare mai espressamente riferimento al "Level A" delle Wai.

e) rivedere il concetto di "versione recente" e aggiornarlo a 1/2 anni prima anche in rispetto a quanto consigliato da Jakob Nielsen in fatto di cauto uso delle nuove tecnologie per un paio di anni dal rilascio.

---

CLARR
http://users.iol.it/buste/clarr
| torna su |

COMMENTO Di ASSOLI

Premessa
Perché la premessa è sempre d'obbligo!
Questi sono i commenti dell'Associazione Software Libero alla bozza di regolamentazione dell'accessibilità dei siti web, della documentazione e dei programmi della Pubblica Amministrazione presentata dall'AIPA e resa disponibile all'indirizzo http://www.aipa.it/attivita[2/gruppi[18/accessibilita[3/bozza[1/strumenti.asp
Innanzitutto va fatto sicuramente un plauso all'iniziativa di rendere pubblica la bozza prima di produrre un testo definitivo: davvero un'ottima idea.
Quello che rimane abbastanza oscuro è a chi si voglia rivolgere l'AIPA con questo scritto: a prima vista pare essere diretto ai responsabili "politici" della Pubblica Amministrazione, coloro che decideranno a chi affidare la realizzazione dei siti e dei programmi e soprattutto come farli realizzare, e quindi il linguaggio è scarsamente tecnico e le raccomandazioni risultano abbastanza vaghe.

Presentazione dello scritto
L'accessibilità viene individuata per due grandi filoni:
- i siti web e più in generale tutta la documentazione presentata in formato html, anche quando non viene distribuita via rete ma su supporti fisici;
- i programmi applicativi preparati per conto della Pubblica Amministrazione.
Con questa bozza si cerca di recepire le normative prodotte prima dall'ONU (in tempi abbastanza remoti per altro) e dall'Unione Europea poi.

Analisi del documento
La nostra analisi si è incentrata esclusivamente su quello che può riguardare il Software Libero per due ragioni:
- innanzitutto siamo qui per questo;
- inoltre altre critiche sono state mosse anche da altri, fondamentalmente dall'interno della lista CyberRights (vedi http://www.ecn.org/lists/cyber-rights/200102/msg00449.html, http://www.ecn.org/lists/cyber-rights/200103/msg00104.html), critiche che ci sentiamo di fare nostre.

1 - Formati proprietari
La prima cosa che salta con evidenza agli occhi alla prima lettura è l'assoluta mancanza di raccomandazioni che riguardino l'uso di formati proprietari nella distribuzione delle informazioni.
Noi crediamo che l'uso, purtroppo assai diffuso in tutta la distribuzione di documentazione da parte della Pubblica Amministrazione, di formati proprietari (testi resi disponibili esclusivamente in uno dei tanti formati doc per il programma di video-scrittura Word, formati spesso incompatibili fra loro anche a livello di versione differente, siti realizzati in flash sono i due esempi più comuni e diffusi) sia un elemento di grave limitazione all'accessibilità di questa documentazione sia per la richiesta implicita di uso del software, sia per la potenza di calcolo e di rete richiesta per l'elaborazione di queste informazioni.
In tutto il documento le indicazioni su quali formati preferire nell'"impacchettamento" delle informazioni risultano estremamente generiche come nel caso del punto d) del paragrafo "Criteri di applicazione delle regole di accessibilità", dove si dice:
d) I documenti disponibili per lo scaricamento dovrebbero avere formati accessibili: HTML, RTF, testo...... Noi crediamo che il testo di questo punto dovrebbe diventare:
d) I documenti disponibili per lo scaricamento devono essere resi disponibili anche in formati accessibili quali: HTML, PDF, testo...
Con l'aggiunta del formato PDF, Portable Data Format, per il quale pur essendo proprietario (della ditta Adobe, per l'esattezza), sono state rilasciate pubblicamente le specifiche permettendo così lo sviluppo di lettori e creatori per tutte le piattaforme anche da parte di sviluppatori indipendenti.
Lo stesso problema esiste anche per l'accessibilità dei siti web, problema affrontato in modo più chiaro all'interno della bozza, indicando come linee guida quelle stabilite dal consorzio del W3.
Il proposito in effetti è valido e importante, vista l'attuale fiorire invece di tanti, troppi siti realizzati e progettati per l'uso esclusivo con il browser Internet Explorer di Microsoft e conseguentemente inutilizzabili da parte di chi vuole o è costretto all'uso di altri browser.
In effetti però dobbiamo segnalare che lo stesso sito dell'AIPA è stato realizzato usando una codifica del testo di tipo WINDOWS-12, invece della ben più standard ISO 8859-1, cosa che impedisce la visualizzazione di caratteri particolari a chi non usa Windows.

2 - Scarsa conoscenza dei sistemi operativi di tipo Unix.
Nel paragrafo "Elenco delle configurazioni di tecnologia assistiva", al punto "3. Applicativo Unix" si dice:
"Si intende che l'accesso avvenga tramite emulatore di terminale VT100 sotto Dos, per cui si ricade nel caso 2."
lasciando sottindere che questa famiglia di sistemi operativi presenti la sola interfaccia a caratteri, il che è decisamente falso.
Chiunque conosca un minimo questi sistemi operativi sa che sono quasi tutti dotati anche di un'interfaccia grafica, detta X Window, da lungo tempo sviluppata e tuttora sotto un pesante sviluppo e anche molto utilizzata e diffusa, visto che oltre tutto è comune a molti di questi sistemi.
Per questo tipo di interfaccia, ma anche per l'interfaccia "classica" a caratteri di Unix è in corso un notevole sviluppo di software assistivo, vedi ad esempio http://ocularis.sourceforge.net.

3 - Questioni di licenze
Un'altra mancanza effettivamente curiosa è quella che riguarda le norme consigliabili per la distribuzione della produzione informatica della Pubblica Amministrazione.
Noi, in qualità di Associazione Software Libero, crediamo che lo scopo della produzione informatica della Pubblica Amministrazione sia di favorire la diffusione della propria documentazione e per questo pensiamo che l'unica possibilità sia quella di distribuire il tutto con una licenza che permetta la sua copia e diffusione senza alcun limite, se non quelli di cambiarne la proprietà intellettuale ed anche la sua modifica da parte di altri.
D'altronde in questo senso vanno recenti proposte fatte al Parlamento Italiano (vedi http://www.interlex.it/pa/emendam.htm) e recenti leggi accettate dal Parlamento francese.
Crediamo altresì che l'uso di licenze di questo tipo non possa altro che aiutare anche la ricerca di una sempre maggiore accessibilità, in quanto lasciare la possibilità di modifica, in special modo nel caso dei programmi, permette anche ad altri, che siano privati oppure ditte interessate in qualunque modo alla questione, di modificarli per adattarli a nuove piattaforme, di portarli su sistemi operativi non previsti all'inizio, di migliorarne l'usabilità prendendo il meglio da altri programmi distribuiti con le stesse modalità, e, viceversa, di prendere ciò che di buono di questi programmi può essere usato per migliorarne altri.
Per ottenere questa possibilità diventa perciò obbligatorio distribuire o rendere in qualche modo disponibili i sorgenti (cio´ il codice prodotto direttamente dal programmatore) dei programmi e lasciare che i sorgenti stessi siano liberamente distribuibili anche nelle nuove forme modificate; solo in questo modo si può realizzare effettivamente la possibilità di modifica e riutilizzo da parte di altri.

leandro@firenze.linux.it
GPG Key fingerprint = 761A 69EA 813A CF14 FACD 1E79 AFF9 1B97 D88E 024C

| torna al menù principale |