Implementation Planning Suite:
Developing Policies
Selecting Authoring
Tools
Evaluating Sites +
Training Suite +
Questa è una traduzione in italiano dell'unica versione ufficiale del documento che è la versione originale in inglese:http://www.w3.org/WAI/impl/software.html. I possibili errori dovuti alla traduzione, sono di esclusiva responsabilità del traduttore Pasquale Popolizio e non sono in alcun modo imputabili al W3C. Questa traduzione è stata realizzata nel luglio del 2004. Per qualsiasi commento riguardo tale traduzione rivolgersi a Pasquale Popolizio.
Selezione ed uso di strumenti di progettazione e sviluppo per l'accessibilità web
introduzione - lista di controllo per la selezione di strumenti - minimizzare le limitazioni - analisi di prodotto
A tutt'oggi, per l'ultima revisione di questo documento, non abbiamo notizia di alcun strumento di progettazione e sviluppo che supporta pienamente la produzione di siti web accessibili. Alcuni sviluppatori stanno incrementando il supporto all'accessibilità nei loro strumenti di progettazione e sviluppo, e alcune utility possono aiutare a colmare le lacune negli strumenti di progettazione e sviluppo esistenti.
Questo documento fornisce informazioni che possono aiutare a trovare strumenti di progettazione e sviluppo migliorati e/o colmare le lacune negli attuali strumenti di progettazione e sviluppo. Esso include questioni da richiedere ai produttori di software in relazione al supporto all'accessibilità nelle loro attuali e future versioni dei prodotti secondo le loro conformità con le Authoring Tool Accessibility Guidelines 1.0 (ATAG 1.0).
Le Linee Guida ATAG 1.0 si rivolgono a tutti i tipi di strumenti di progettazione e sviluppo, inclusi gli strumenti WYSIWYG (ciò che vedi è ciò che ottieni), strumenti di conversione che salvano in HTML come eleboratori testi, strumenti per la generazione di base dati, strumenti per la gestione di siti, etc. Le Linee Guida ATAG 1.0 hanno un insieme di tecniche di supporto che aiutano gli sviluppatori del software a implementare le Linee Guida ATAG 1.0 nei loro prodotti. Le Linee Guida ATAG 1.0 spiegano agli sviluppatori degli strumenti di progettazione e sviluppo a realizzare il loro prodotti, in modo che essi possano:
- supportare le pratiche di progettazione e sviluppo accessibile;
- generare codice standard;
- supportare la creazione di contenuto accessibile;
- fornire modalità di verifica e correzione del contenuto non accessibile;
- integrare il supporto all'accessibilità nell'immagine completa del prodotto;
- promuovere l'accessibilità con aiuti in linea e documentazione; e
- assicurare che lo strumento sia accessibile agli autori con disabilità.
Valutare il software attualmente in uso nell'organizzazione:
- Gli strumenti di progettazione e sviluppo attualmente in uso supportano o impediscono la produzione di siti web accessibili? Accertarsi di considerare ampiamente i software di produzione HTML WYSIWYG; strumenti di conversione come elaboratori di testi o software per presentazioni che salvano i documenti in formato HTML; applicazioni che generano pagine web partendo da base dati; software di elaborazione immagini, software di elaborazione di contenuti multimediali; strumenti di gestione dei siti, etc.
- Gli strumenti di progettazione e sviluppo attualmente in uso cambiano o rimuovono le informazioni accessibili (per esempio, il testo alternativo per le immagini) che sono state aggiunte da altri strumenti o con codice realizzato a mano?
- Per gli strumenti di progettazione e sviluppo che non supportano la creazione di contenuto accessibile, ci sono plug-in o altre utility che possono essere usate con questi prodotti per meglio supportare la produzione di siti web accessibili?
Selezionare software nuovo o di sostituzione:
- Quali applicazioni sono più conformi alle Linee Guida ATAG 1.0?
- Per quali applicazioni sono disponibili plug-in che colmano la lacuna nel supporto all'accessibilità per il prodotto principale?
- Per quali applicazioni esiste un impegno dello sviluppatore di continuare a migliorare la conformità rispetto alle Linee Guida ATAG nelle versioni future?
Analizzare le procedure di acquisizione del software:
- Le politiche di acquisto all'interno dell'organizzazione incoraggiano o richiedono l'acquisto di applicazioni con più avanzato supporto all'accessibilità?
- Per le organizzazioni con procedure di acquisto centralizzate, c'è un modo attraverso il quale comunicare l'interesse dell'organizzazione per software conforme alla Linee Guida ATAG ai produttori, così che essi siano al corrente delle richieste di tali caratteristiche?
Interrogare i produttori di software circa il supporto dei prodotti:
- Il prodotto è conforme alle Authoring Tool Accessibility Guidelines 1.0 del W3C?
- Se no, quando il produttore pensa di realizzare una versione conforme?
- Il produttore può dimostrare l'attuale supporto in accessibilità nei suoi prodotti?
- Ci sono plug-in che possono essere utilizzati con il loro prodotti per meglio supportare nella creazione di siti web accessibili?
- Può una serie di strumenti fornire accessibilità laddove lo specifico strumento di progettazione e sviluppo è manchevole?
- (In Paesi dove sono in vigore requisiti di legge per l'accessibilità web) Quali caratteristiche il produttore ha aggiunto ai suoi prodotti per supportare i requisiti di accessibilità web?
- Chi è il contatto nella società di software a cui richiedere più informazioni riguardo l'accessibilità dei prodotti?
Finché non saranno disponibili strumenti di progettazione e sviluppo pienamente conformi alle Linee Guida ATAG 1.0, è utile sviluppare strategie per minimizzare le limitazioni degli attuali strumenti. I passi per sviluppare tali strategie sono:
- familiarizzare con i concetti generali (a livello di Linee Guida, non necessariamente i singoli punti di controllo) espressi dalle Linee Guida per l'Accessibilità del Contenuto Web 1.0 (WCAG 1.0) e le Linee Guida ATAG 1.0;
- identificare le limitazioni degli strumenti di progettazione e sviluppo attualmente in uso all'interno dell'organizzazione (prendendo nota dei problemi ricorrenti in output non accessibile di questi strumenti di progettazione e sviluppo; informandosi sulle analisi di accessibilità dei prodotti; prendendo nota delle caratteristiche di supporto ai punti di controllo delle Linee Guida ATAG 1.0; etc.);
- individuare plug-in o utility che possono esser utilizzate in combinazione con un determinato strumento di progettazione e sviluppo per correggere output non accessibile;
- sviluppare un processo interno o una lista di punti per correggere i problemi di accessibilità generati da questi strumenti.
Esempi di strategie per minimizzare le limitazioni degli attuali strumenti di progettazione e sviluppo:
- Se i modelli forniti con uno strumento di progettazione e sviluppo non sono conformi alle Linee Guida WCAG 1.0 [ATAG
1.0 Checkpoint 1.4], sviluppare modelli conformi alle Linee Guida WCAG appropriati per i bisogni della tua organizzazione, e distribuirli per tutta l'organizzazione.
- Se uno strumento di progettazione e sviluppo non crea codice valido [ATAG 1.0
Checkpoint 2.2] in accordo alla Definizione del tipo di Documento (DTD), usare in abbinata uno strumento di ripulitura come HTML Tidy.
- Se uno strumento di progettazione e sviluppo di elementi multimediali non supporta la creazione di didascalie per audio [ATAG 1.0
Checkpoint 1.1], usare in abbinata un software per didascalie come Magpie.
- Per sistemi di progettazione e sviluppo disegnati principalmente per produrre stampati (per esempio Acrobat, PageMaker, Quark Xpress), elementi complessi (Director, Flash, ToolBook), elaboratori di testi (Word, Word Perfect), presentazioni (PowerPoint, Freelance, Visio), ritornare al materiale originario laddove è possibile e generare un documento accessibile in versione HTML o XHTML dall'originario; o utilizzare convertitori se disponibili (per esempio, un PDF to HTML
Converter) e poi verificare l'accuratezza della conversione; oppure ricreare i materiali in un formato accessibile; poi porre il formato accessibile sul sito [ATAG 1.0 Checkpoint
2.1].
- Se uno strumento di progettazione e sviluppo utilizzato per riparare un sito esistente non ha un automatismo per testi alternativi mancanti [ATAG 1.0
Checkpoint 3.1], utilizzare uno strumento di riparazione di accessibilità come A-Prompt che automatizza la richiesta di immisione di informazione richiesta.
- Se uno strumento di progettazione e sviluppo non inserisce una Denizione del Tipo di Documento (DTD) (necessaria per la validazione del codice, e per la conformità all'HTML, XHTML, etc.) [ATAG
1.0 Checkpoint 2.2], ricercare un'estensione che inserisce l'appropriata DTD, o inserire la DTD a mano.
- Se uno strumento di progettazione e sviluppo non supporta i fogli di stile in cascata [ATAG 1.0
Checkpoint 3.2 & ATAG 1.0
Checkpoint 4.5], usarlo in abbinamento con un software di sviluppo per fogli di stile compatibile.
- Se uno strumento di progettazione e sviluppo non visualizza una versione lineare delle tabelle [ATAG 1.0
Checkpoint 3.2] e tecniche per [WCAG 1.0 Checkpoints 5.1 - 5.4],
usarlo in abbinamento con the WAVE,
o con Lynx o Lynx-me, o altri browser testuali o emulatori di browser testuali.
- Se uno strumento di progettazione e sviluppo non preserva tutta l'informazione accessibile durante la progettazione e sviluppo, trasformazioni, e conversioni [ATAG 1.0
Checkpoint 1.2], editare a mano e salvare in formato grezzo, oppure utilizzare un nuovo strumento di progettazione e sviluppo.
- Se uno strumento di progettazione e sviluppo genera alternative equivalenti [ATAG 1.0
Checkpoint 1.3], per esempio inserendo il nome del documento come testo alternativo, disattivare questa funzione, oppure verificare manualmente e correggere tutti i testi alternativi.
L'Authoring Tool Accessibility Guidelines Working
Group (AUWG) periodicamente analizza strumenti di progettazione e sviluppo per verificare la loro conformità con le Linee Guida ATAG 1.0. A tutt'oggi, con quest'ultima versione di questo documento, le analisi disponibili dalla home page del gruppo AUWG possono non essere aggiornate ed in ogni caso non rappresentano gli ultimi progressi nelle conformità ATAG. Il gruppo AUWG aggiorna tali analisi dei prodotti su base collaborativa insieme agli sviluppatori; assistenza e feedback sulle analisi è di aiuto.
In alcuni casi gli sviluppatori illustrano sui loro siti informazioni sul grado di supporto all'accessibilità presente nei loro prodotti. Il WAI fornisce collegamenti alle pagine di accessibilità di molti sviluppatori. La pagine di accessibilità degli sviluppatori possono contenere rimandi a plug-in che migliorano la capacità di uno strumento di progettazione e sviluppo a supportare la produzione di contenuto web accessibile.
Ultima revisione: $Date: 2002/10/25 03:30:00 $
Redattori Judy Brewer, e i participanti al Gruppo Education and Outreach Working Group. Comments welcome at
wai-eo-editors@w3.org.
