minerva homepage


 
  About Minerva  
  Structure  
   
  NPP  
  Good practices  
  Competence centres  
  Digitisation guidelines  
  European and national rules on the Web Applications  
  Enlargement  
  Events  
  References  
  Publications  

home  |  search  |  map  |  contact us  
Path: Home | Events | bibliocom


 

International workshop
Rome, October, 17th 2002, Palazzo dei Congressi, Bibliocom 2002

Quality in cultural Web sites

edited by the Ministero per i Beni e le Attività Culturali In conjunction with European Commission and Associazione Italiana Biblioteche, within the MINERVA Project




Maurizio Lunghi
European Commission, General Directorate for Information Society


L'accessibilità alle pagine Web per persone disabili: un esempio pratico



Introduzione

L'accessibilità delle pagine Web per "utenti con speciali necessità" è un importante requisito da rispettare, per il quale dobbiamo tra l'altro rimuovere le barriere che non permettono l'accesso a utenti disabili, anziani e con limitate esperienze informatiche, barriere che sono invisibili agli occhi e al mouse degli utenti normodotati.

Molte iniziative sono state avviate per migliorare il livello di coscienza e conoscenza sull'argomento da parte di tutti i produttori di contenuti per il Web, ma con particolare attenzione da parte degli attori pubblici e istituzionali che devono offrire un servizio a tutti i cittadini.

Con il termine "utenti con speciali necessità", riferito all'uso delle nuove tecnologie, in realtà intendiamo un pubblico molto più ampio delle persone considerate disabili nella nostra società. Possiamo dividere i problemi di accessibilità in quattro categorie:

  • disabilità fisiche/sensoriali: non vedenti, ipovedenti (persone che possiedono un residuo visivo, oscillante tra 1/10 e 3/10), daltonici, non udenti, utenti con difficoltà motoria nell'uso di mouse e tastiera;
  • disabilità cognitive: scarso apprendimento, problemi di lettura e comprensione dei testi;
  • barriere tecnologiche: connessione lenta, plug-in assenti (java flash ecc.);
  • anziani e persone senza particolare capacita nell'uso dei nuovi media.

Parliamo di: problemi pratici per gli utenti non vedenti che avranno difficoltà con la comprensione delle immagini del sito; gli ipovedenti con caratteri troppo piccoli, i daltonici con alcune combinazioni di colori; gli utenti dotati di vecchi computer/software; problemi con alcune tecnologie non standard (Java, Flash ecc.). Spesso volendo concentrare tutto in una pagina o volendo inserire effetti speciali per "distinguersi" da altri siti, si finisce per complicare molto la navigazione e quindi la fruizione di un servizio da parte di persone senza particolare capacità nell'uso dei nuovi media e Internet come la maggioranza della popolazione anziana, fra l'altro in grande aumento.

Le soluzioni hardware e software, che permettono di superare alcuni di questi problemi, vengono definite "tecnologie assistive". Un esempio è lo Screen Reader, software che leggendo il contenuto della pagina Web ne permette la navigazione anche agli utenti non vedenti. Altro esempio è lo Screen Magnifier, software che ingrandisce alcune parti dello schermo per facilitare la lettura agli ipovedenti. Per gli altri problemi devono intervenire il buon senso e la voglia di semplificare la fruizione del servizio anziché di stupire con "effetti speciali".

Perché costruire siti Web accessibili?

Un sito Web accessibile è un "sito Web di qualità" che dimostra attenzione da parte del team di sviluppo per le esigenze degli utenti, compresi gli utenti disabili. Bisogna chiarire che per essere accessibili non bisogna rinunciare al design del sito. I componenti multimediali il più delle volte vanno solamente integrati per permetterne l'utilizzo anche agli utenti disabili. Gli ALT nelle immagini sono un chiaro esempio. Ad esempio, impostare il "testo ALTernativo" non modifica il design di un sito, ma permette a un non vedente di comprendere il significato della grafica.

E quali sono i motivi che dovrebbero spingere a progettare e costruire siti Web accessibili?

  • Motivi civili: i disabili hanno gli stessi diritti e non è giusto escluderli dai servizi presenti in rete! Soprattutto quando lo sforzo per rendere un sito accessibile è fattibile. Inoltre, nella nostra accezione estesa se conteggiamo anche gli anziani e le persone senza particolari esperienze informatiche probabilmente arriviamo a metà della popolazione totale.
  • Motivi economici: gli utenti disabili si dimostrano clienti affezionati con chi cura le loro esigenze, portando vantaggi anche a livello economico.
  • Motivi legali: per le amministrazioni pubbliche è obbligatorio il rispetto di alcune norme. Negli Stati Uniti i siti federali devono rispettare le regole imposte dalla Section 508 e in Italia c'è una circolare AIPA del settembre 2001 contente criteri e strumenti per migliorare l'accessibilità dei siti Web e delle applicazioni informatiche a persone disabili.

Web Accessibility Initiative (WAI)

Nel 1999, promossa dal World Wide Web Consortium (W3C), nasce WAI . La missione del WAI: rendere accessibile universalmente la potenza di Internet. Si pensa a un nuovo modo di concepire lo sviluppo delle pagine Web ispirato ai Principi di progettazione universale, per permettere anche agli utenti disabili di accedere ai contenuti dei siti Web.
La Web Content Accessibility Guidelines 1.0 è ancora oggi il documento più importante per chi intende abbattere le barriere nei siti Web. Le guidelines dividono i checkpoint secondo la loro priorità creando tre livelli per l'accessibilità (A-AA-AAA):

  • Priorità 1. Norme che devono essere rispettate da tutti, pena l'impossibilità per alcuni gruppi di utenti di accedere alle informazioni (livello A di adesione).

  • Priorità 2. Norme che dovrebbero essere soddisfatte, pena una difficoltà di accesso ad alcune informazioni da parte di uno o più gruppi di utenti (livello AA).

  • Priorità 3. Norme che potrebbero essere soddisfatte, con l'obiettivo di rendere ancora migliore l'accesso a uno o più gruppi di utenti (livello AAA).

Consigli pratici

La WAI fornisce agli sviluppatori di contenuti Web un insieme di dieci "consigli pratici", che condensano alcuni dei principi basilari dell'accessibilità dei siti Web in una scheda delle dimensioni di un biglietto da visita, disponibile in diverse lingue. Pur essendo un utile promemoria, queste istruzioni non offrono la soluzione completa e assoluta del problema dell'accessibilità di Internet.

  1. Immagini e animazioni. Utilizzare l'attributo "alt" per descrivere la funzione di ogni elemento grafico.

  2. Per ciascuna immagine o animazione su una pagina Web, aggiungere una breve descrizione testuale della funzione immagine all _ interno del codice pagina. In questo modo, le interfacce di assistenza usate dagli ipovedenti possono estrarre queste informazioni alternative per produrre lo stesso messaggio generale dalla pagina. Queste tecniche sono utili anche per chi usa strumenti alternativi come tecniche di assistenza personale digitale, telefoni cellulari di terza generazione o browser solo testo (spesso usati da coloro che hanno una connessione a Internet lenta).
  3. Immagini cliccabili. Utilizzare l'elemento "MAP" e descrivere le zone attive.

  4. Le immagini cliccabili, o image maps, sono immagini che sono state divise in regioni associate rispettivamente ad azioni. Le mappe interamente contenute nel documento (client-side) codificano quest'attività disponibile alle tecnologie di assistenza, contrariamente alle image maps server-side, la cui interattività non è accessibile alle tecnologie di assistenza.
  5. Multimedia. Fornire sottotitoli e trascrizioni per l'audio, e descrizione di filmati.

  6. Per ogni tipo di multimedia inserito in una pagina Web aggiungere sulla stessa pagina o in una sottopagina didascalie e trascrizioni dell'audio, nonché descrizioni dei filmati. In questo modo coloro che non possono vedere o udire il contenuto multimediale possono comunque avere accesso allo stesso messaggio.
  7. Link ipertestuali. Utilizzare enunciati che conservino il loro senso al di fuori del contesto. Per esempio, evitare "cliccare qui".

  8. Per ciascun link ipertestuale di una pagina, scegliere un testo cliccabile significativo e possibilmente un "title", che mantengano il proprio senso logico anche se il resto della frase o la configurazione di pagina vengono rimossi. Le interfacce di assistenza di solito utilizzano un canale intrinsecamente più lento di comunicazione umana, come la sintesi vocale o il Braille, che rende molto lenta la "lettura" di tutti i contenuti di una pagina.
  9. Organizzazione delle pagine. Utilizzare titoli, liste e una struttura coerente. Utilizzare CSS 1 per l'impaginazione. Fogli di stile.

  10. Scegliere una struttura chiara e coerente per le informazioni sulle pagine Web, che sia facile da comprendere e riconoscere da una pagina all'altra. Inoltre, usare i codici dedicati disponibili per creare questa struttura nella pagina (elemento marcatore strutturale) e separare i codici di contenuto e stile, in modo che le tecnologie di assistenza possano navigare efficientemente attraverso contenuto e struttura.
  11. Figure e diagrammi. Descriverli all'interno della pagina o utilizzare l'attributo "longdesc".

  12. Per ciascuna figura o diagramma di una pagina, aggiungere un riassunto testuale o inserire una descrizione testuale alternativa all'interno del codice pagina in modo che queste possano essere sfruttate da un'interfaccia di assistenza anziché rappresentazioni grafico-visive.
  13. Script, applet e plug-in. Fornire una pagina alternativa quando tali funzionalità sono inaccessibili o non supportate.

  14. Poiché queste azioni non necessariamente possono essere riprodotte dalle interfaccia di assistenza e persino da alcuni browser, aggiungere sempre un modo alternativo per veicolare o indicare il contenuto all'interno del codice pagina.
  15. Cornici (frames) . Utilizzare "NOFRAMES" e titoli significativi.

  16. Una configurazione di pagina può essere suddivisa in cornici, il contenuto delle quali può essere aggiornato separatamente mediante l'interazione dell'utente. Nella codificazione di layout della pagina, aggiungere un nome significativo per ciascuna cornice. In tal modo le tecnologie di assistenza possono fornire informazioni che permettono all'utente di capire il rapporto fra le cornici e il loro contenuto.
  17. Tabelle. Facilitare la lettura linea per linea. Riassumere.

  18. L'organizzazione bidimensionale delle informazioni è altamente visiva e le attuali interfacce di assistenza la trascrivono con lettura riga per riga. Migliorare l'efficienza di questo metodo aggiungendo un riassunto del contenuto della tabella codificando i titoli significativi per ciascuna colonna e riga. Inoltre, se possibile, evitare l'uso di tabelle per rimpiazzare l'attuale mancanza di strumenti di pagina Web per creare una configurazione di pagina a più colonne.
  19. Verificare il lavoro. Validare. Utilizzare gli strumenti, la lista di controllo e le linee guida di: www.w3.org/TR/WCAG.

  20. Verificare la qualità del lavoro ispezionando il codice pagina prodotto, utilizzando strumenti di valutazione disponibili e cercando di visualizzare la pagina prodotta su un browser solo testo.È bene però precisare che l'accessibilità non può essere semplicemente verificata automaticamente. Infatti, uno dei due principi cui fa riferimento, precisamente rendere il contenuto navigabile e fruibile, non può certo essere stabilito da un programma. Alla luce di queste considerazioni, è possibile anche definire il rapporto che intercorre fra usabilità e accessibilità, almeno per come viene definita dal WAI. Si tratta di un rapporto di inclusione: l'accessibilità, per essere tale, deve includere anche l'usabilità, e implementare alcune norme di buona codifica HTML.

Iniziative politiche

Tra le numerose iniziative intraprese nel mondo, oltre alla WAI, anche gli attori europei hanno decisamente sostenuto tale iniziativa, ponendola come prioritaria per il raggiungimento del rispetto dei diritti di tutti i cittadini in una società del futuro assolutamente senza differenze come livello di inclusione e servizi offerti. La Commissione europea e tutti i paesi membri, nell'ambito dell'iniziativa coordinata eEurope Action Plan 2002 hanno fissato obiettivi comuni a tale scopo nella "Information Society for all". Tra le tante attività previste in ambito eEurope, spicca certamente la e-accessibility e "Design for all" specificatamente per people with special needs, incentrata sull' adozione da parte della Commissione Europea e dei paesi membri, delle guidelines della WAI per i propri siti Web. Il livello di progresso nell' implementazione degli obiettivi concordati viene verificato tramite l'uso di indicatori relativi a un modello di benchmarking. La Commissione Europea ha anche prodotto una propria Comunicazione dove il Commissario Liikanen promuove un piano di azione per l'adozione delle guidelines WAI da parte di tutti i siti Web della EC fissando delle scadenze molto ravvicinate (Comunicazione della Commissione al Consiglio, al Parlamento europeo, al Comitato economico e sociale e al Comitato delle regioni, eEurope 2002: accessibilità e contenuto dei siti Internet delle amministrazioni pubbliche, Bruxelles, 25.09.2001, COM(2001) 529. Infine, il 3 dicembre 2001, l' Unione Europea ha adottato il 2003 come "European Year of People with Disabilities". Questa decisione crea nuove opportunità per le persone disabili in Europa, circa 37 milioni, di ribadire i propri diritti e mettere in cima all'agenda politica questa problematiche cruciale per una società veramente credibile e fruibile da tutti i cittadini europei. In Italia il governo, per voce del Ministero della funzione pubblica, ha emanato una direttiva per la costruzione dei siti Web delle amministrazioni pubbliche. Le norme italiane dettate dall'AIPA sono un riassunto delle Content Accessibility Guidelines 1.0 e hanno soppresso integralmente la suddivisione dei checkpoint nei tre livelli di priority. Il documento invita tutte le pubbliche amministrazioni a considerare il ruolo di Internet come strumento comunicativo sia interno sia con l'esterno, e ne sottolinea il valore strumentale di "tecnologia distribuita". Alla luce di queste considerazioni, esorta chi realizza i siti delle pubbliche amministrazioni a rispettare le norme di usabilità, intesa come buona organizzazione dei contenuti e della navigazione; accessibilità, ovvero la possibilità di rendere accessibile i contenuti dei siti ad utenti disabili o con dotazioni tecnologiche ristrette. Da notare che negli Stati Uniti l'accessibilità è considerata un vero e proprio diritto civile (come di fatto è) dalle associazioni dei disabili, che dopo varie battaglie hanno ottenuto che, con la normativa denominata sezione 508, tutti i siti e le intranet governativi siano conformi alle norme sull'accessibilità. Questo ovviamente è anche un vantaggio per il governo, che ha tutto l'interesse che un dipendente disabile riesca a utilizzare proficuamente il sistema informativo interno ed esterno durante il lavoro.

Esempio pratico

Al fine di testare un sito Web, sono stati prodotti alcuni software che automaticamente fanno una prima analisi della pagina in esame, generando un report con una lista dei punti sospetti rilevati. A questo punto un esperto deve completare l'esame valutando, sulla base della sua preparazione professionale, quali punti della lista sono trascurabili e quali soluzioni implementare per garantire la conformità alle raccomandazioni. Due fra i più noti sono Bobby, il classico riferimento anche del W3C, e il nuovo Torquemada, sviluppato recentemente dalla Fondazione Bordoni.

Per il test delle nostre pagine sono partito dalla pagine radice per poi estendere alle altre pagine gli stessi precetti.

Inizialmente ho usato entrambi i software, Bobby e Torquemada, poi ho analizzato ogni singolo punto della lista dei warnings del report. La maggior parte di queste segnalazioni erano "false", vale a dire che non erano rilevanti nel contesto della pagina. Ho redatto altresì un elenco di correzioni da apportare alle nostre pagine per renderle conformi alle guidelines WAI, almeno al livello più semplice "level A". Vorrei sottolineare che la valutazione rimane sempre un lavoro di interpretazione personale e che il risultato finale è pur sempre una forma di "auto-certificazione"; ovviamente la persona che "certifica" e quindi si assume la responsabilità della conformità deve possedere notevoli conoscenze tecniche. A conclusione del lavoro svolto, con Christine Michaut all'interno della nostra unita D2, abbiamo prodotto una pagina esplicativa delle modalità e un Decalogo (in appendice), per il momento solo in inglese, con una serie di consigli utili per rendere più semplice la costruzione di pagine Web per tutti i tipi di utenti possibili. Ringraziamenti sentiti per il supporto offerto vanno a Oreste Signore dell'ufficio W3C a Pisa e ad Andrea Bernardini della Fondazione Ugo Bordoni.

Lista di indirizzi Web


Appendice

Content producers' Decalogo

This Decalogo is a draft internal document to help 'content producers', people inside Commission charged with producing and updating content pages, on accessibility issues. It regards only the features related to the content page, including selection and organisation of material, definition of sections and specific pages, language and communication tools, tables and forms for request or searching, finally, content page itself with text-hyperlinks-multimedia.
All the other issues like for example template, menu, graphic, are left to the service for web site following the W3C-WAI guidelines. Anyhow some technical issues are included in this list to advise 'content producers' to be aware about that and to check together with technicians that rules are respected.

Policy for management, source information and credibility

  • Title of the page must be self-explaining content and functionality of the page.
  • In some cases the attribute LONGDESC can provide a longer description of the page itself.
  • Use the attribute LANG to declare the natural language of the page, normally use the same language for the all page.
  • Use Metadata to introduce the page mission, author and other data, keywords should be few and very focused.
  • Indicate clearly the author/authority, responsible contact and e-mail, date of the last 'revised and updated on ..' both inside the page and in the header; it's suggested to change this information as often as possible, obsolete pages damage credibility of the all web site. It would be better to revise most important pages at frequent intervals following a specific policy for example once every six months.
  • Avoid personal uses or publishing message offensive for somebody.

Text organisation

  • The starting point must always be the final user, his expectations, skills and ability using telematics tools, what kind of info are more commonly requested. Final user should be able to find out information with 3 clicks of mouse whatever his expertise. Implement a strategy to monitor users interest, needs, behaviour and to receive comments or suggestions by them.
  • Organise the text in a simply way being clear, synthetic, focused trying to make easy and logic the 'topic navigation' by all users, the main content must get across to all users. All the key information must be contained in the first screen; all the keywords must be evident in the headers or titles.
  • Use a language and terminology well known and accessible by all users.
  • Avoid using acronyms without giving explanation.
  • Avoid using images on the background that can disturb reading by some users.
  • Avoid too small text or specific types of character.
  • Avoid using absolute dimensions instead relative size for your text page in order to be readable and printable on every user platform.
  • If you include in the text page an hyperlink to an important URI, make it also evident in the written form in order to be readable if user prints the page, of course it's not the case if the link is internal.
  • Avoid long textual pages or in case create at the top of the page an internal index listing different parts of the document with hyperlinks to jump to one section with a button 'back to the top'.
  • Homogenous structure is always suggested for a web site.
  • Avoid using proprietary format for text or make your document available in different formats, our suggestions are:
  • HTML and TXT are clearly the best accessible formats;
  • RTF doesn't have the problems for version number like DOC;
  • PDF format the reader is available for all platform for free.

Colour

  • Make sure the colour contrast is suitable also for people with colour deficits. It's suggested to test pages with a black-white monitor or with different light-conditions.
  • Minimise colour palette size for each image or icon. That will reduce the size of images and will improve the actual colour rendering on every monitor.
  • Ensure that all information conveyed with colour is also conveyed in the absence of colour. For example, asking users to click the red button is not useful if they can't distinguish the red button from other buttons on the screen. The Web page needs to provide another way of making the information available.

Multimedia and alternative text

  • The use of multimedia content must be reduced as much as possible, and in any case the page size in bytes must be limited not to overload slow capacity connections: each page should take no longer than 30 seconds to be loaded on the slowest connection.
  • Use attribute ALT or LONGDESC or CAPTION to give a textual explanation for multimedia content like images, sounds, graphs, video, animations, scripts and so on.
  • Provide an alternative page if it's impossible to give the same information using simply the attribute for a text description.
  • Use ALT = "" for images that do not convey important information.
  • It's strongly discouraged use of images for text buttons.
  • Avoid blinking, moving or flickering content, and in case use very low frequencies.

Hyperlinks

  • Provide meaningful and descriptive text for hyperlinks, for example avoid "click here" but use "follow this link to our news page".
  • If an image is used to create a hyperlink use ALT attribute to introduce the linked content.
  • Use attribute TITLE for more important hyperlinks <A HREF> included in your page giving a short explanation on the linked content and the page size in bytes. It will be very useful to improve navigability also for people without disabilities.
  • If an external window will be launched or content of page will b e changed, inform users in advance.
  • Hyperlinks to downloadable files should include a text description with all the needed information about content, file size and format.

Tables and forms

  • Use attribute CAPTION or SUMMARY to describe content and structure of tables or forms. A legend is normally appreciated in particular for acronyms.
  • Use relative sizing and positioning rather than absolute. Test on monitor with lower resolution.
  • Make sure it's properly printable on different machines.
  • Forms for info-request or search engine are often too complex, long and not evident by all users. Simplify as much as possible and make usable by all users without specific skills.

Image maps

  • Use client-side image maps and alternative text for image map hot spots. If a server-side map is needed, provide equivalent text links.

Proprietary technologies and plug-in

  • Avoid use of proprietary technologies or formats not free or accessible on different platforms, operative systems or older computers; avoid using plug-in and non-HTML features or provide an alternative page.

Navigation tools and frames

  • Navigation bar or menu must be self-explaining, easy to understand, synthetic and focused using well known terminology and symbols. An alternative text-only navigation tool should be provided.
  • Navigation bar can be included in the page or can be put in a frame: in the first case make sure that the page is still printable with the correct margins; in the second case make sure that the frame titles are self-explaining the content and provide a 'noframe' version of the page.
  • Provide methods for skipping over navigation links to get to the main content of page.
  • Use relative sizing and positioning rather than absolute for menu too, if it's possible. Make sure all the scroll-bars are visible and accessible on low resolution monitors.
    A text-only index or a map of the whole web site should be always available as well as the search engine function, possibly from every page.
  • Pop-up window menus would be better to avoid, if they are really needed, provide equivalent text links or methods to skip over to the page content anyway. A 'no scripts' version of the page should be provided.
  • In general every dynamic functions like pop-up windows, scripts or any change in the page must be device-independent, for example it would be better to have keyboard than mouse accessible pages.

Test your pages

  • Test your pages on different operative systems, monitors with different resolution, install a screen reader and various types of browser.
   




TOP


Copyright Minerva Project 2003-04, last revision 2003-04-10, edited by Minerva Editorial Board.
URL: www.minervaeurope.org/events/documents/lunghibibliocom.htm
Valid HTML 4.0!