skip navigation barsW3C logoWeb Accessibility Initiative (WAI) logo
W3C Index - W3C Search - W3C Translations
WAI Resources - WAI Site Map - About WAI

Implementation Planning Suite:
Developing Policies
you are hereSelecting 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

Introduzione

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:

  1. supportare le pratiche di progettazione e sviluppo accessibile;
  2. generare codice standard;
  3. supportare la creazione di contenuto accessibile;
  4. fornire modalità di verifica e correzione del contenuto non accessibile;
  5. integrare il supporto all'accessibilità nell'immagine completa del prodotto;
  6. promuovere l'accessibilità con aiuti in linea e documentazione; e
  7. assicurare che lo strumento sia accessibile agli autori con disabilità.

Lista di controllo per la selezione di strumenti di progettazione e sviluppo

Valutare il software attualmente in uso nell'organizzazione:

Selezionare software nuovo o di sostituzione:

Analizzare le procedure di acquisizione del software:

Interrogare i produttori di software circa il supporto dei prodotti:

Minimizzare le limitazioni degli attuali strumenti di progettazione e sviluppo

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:

Esempi di strategie per minimizzare le limitazioni degli attuali strumenti di progettazione e sviluppo:

  1. 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.
  2. 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.
  3. 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.
  4. 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].
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.

Analisi dei prodotti

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.

Level Double-A conformance icon,  W3C-WAI Web Content Accessibility Guidelines 1.0

Copyright 2000 - 2002 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.