Descrizione del documento
Questo documento vuole analizzare e fornire una serie di commenti alle linee guida del Working Draft pubblico del 22 Novembre 2004 delle ATAG 2.0 del W3C e alle rispettive implementazioni tecniche del 22 Novembre 2004.
La versione originale di questo documento è disponibile al seguente indirizzo:
http://www.ioshi.org/pubblicazioni/analisi.WD-ATAG20-20040224.html
Analisi linee guida 1
ATAG Checkpoint 1.3 Allow the display preferences of the authoring interface to be changed without affecting the document markup. [Priority 1]
Nelle tecniche per il secondo criterio si esprime il seguente principio:
Technique 1.3.4: For authoring tools that offers a “rendered view” of a document, such as a browser preview mode, provide an editing view that has a presentation that can be controlled independently of the rendered view.
Su questo punto si potrebbe raccomandare che la “visualizzazione renderizzata” sia compatibile con le specifiche w3c e non con eventuali visualizzazione di un browser.
ATAG Checkpoint 1.4 : Ensure that the authoring interface enables the author to navigate the structure and perform structure-based edits. [Priority 2]
Nelle tecniche per il primo criterio si esprime il seguente principio:
Technique 1.4.4: For an image expressed in a structured language (i.e., SVG), allow the author to navigate regions of the image or the document tree.
Questo presuppone che le regioni componenti l’immagine siano ordinate secondo una logica strutturata e facilmente consultabile.
ATAG Checkpoint 1.5 : Ensure that the authoring interface allows the author to search within the editing views . [Priority 2]
In generale potrebbe essere raccomandata l’implementazione di strumenti che facilitino le ricerche complesse (es tramite espressioni regolari).
In caso di documenti strutturati in modo gerarchico (es xhtml o svg) si potrebbe raccomandare la fornitura di strumenti per limitare la ricerca tra i nodi, tramite una selezioni degli stessi in maniera gerarchica (tree).
Analisi linee guida 2
ATAG Checkpoint 2.1 : Support formats that enable the creation of Web content that conforms to WCAG . [Priority?1]
Nelle tecniche per il primo criterio si fa riferimento al seguente principio:
Technique 2.1.1: When creating documents or markup languages, make full use of W3C Recommendations . For example, use MathML [MathML] for mathematical Web content and XHTML [XHTML] , MathML [MathML] , and DOM [DOM] scripting to implement dynamic-interactive spreadsheets.
Bisogna però ricordare che il DOM è semplicemente un linguaggio “interfaccia” che permette l’accesso a strutture di marcatura complesse tramite dei metodi universali e indipendenti per tutti i linguaggi di programmazione e/o di scripting.
Per questo affermare l’uso del DOM per implementare il dinamicismo non garantisce un funzionamento dello script su tutte le piattaforme che accederanno al contenuto web. Per questo sarebbe raccomandabile l’inserimento di un riferimento all’unico linguaggio di scripting funzionante su tutti i browser, l’ECMAScript (ECMA-262 e altri) dell’ECMA International.
ATAG Checkpoint 2.2 : Ensure that the tool preserves all unrecognized markup and accessibility information during transformations and conversions. [Priority 2]
Si potrebbe consigliare in generale l’uso di un linguaggio standard come l’XSL per effettuare le conversioni tra tipi di dati, garantendo così una maggiore interoperabilità tra le applicazioni.
Analisi linee guida 3
ATAG Checkpoint 3.1 : Prompt and assist the author to create content that conforms to WCAG . [Web Content Checkpoints Relative to WCAG]
Al punto 3.1.1(8) si propone di limitare i colori del testo o sfondo, quando uno dei due è già stato selezionato, secondo i principi del contrasto minimo. Ma come si può gestire il contrasto quando uno dei due è trasparente e l’area in questione eredita il colore dagli elementi presenti visualmente sotto di lui.
Una proposta di soluzione potrebbe essere quella di verificare anche i colori di sfondo dell’elemento padre (statisticamente il più compromettente) e sconsigliarne di conseguenza quelli con troppo poco contrasto.
Al punto 3.1.1(13a), un consiglio non toccante direttamente la tecnica, potrebbe essere quello di non proporre i nomi “tecnici” delle classi CSS, ma assegnare ad ogni classe CSS un nome indipendente e separato, più facilmente comprensibile.
In generale si potrebbe consigliare l’uso di sistemi di analisi linguistica (oltre ai vocabolari, alle collezioni di acronimi e ai termini in maiuscolo) che cerchino di identificare eventuali acronimi o abbreviazioni per poi segnalarle all’editore.
Analisi linee guida 4
ATAG Checkpoint 4.2 : Ensure that accessibility prompting, checking, repair functions, and documentation are always clearly available to the author [Priority 2]
La possibilità di attivare o disattivare preferenze di controllo sull’accessibilità nelle applicazioni di edizioni basate sul web potrebbe risultare il punto d’implementazione più problematico delle stesse.
Raccomandazioni generali
- Le linee guida analizzate risultano essere già molto complete.
- Nelle tecniche molti punti sono stati chiariti solamente per un edizione visuale, andrebbero chiariti con degli esempi pratici (usecases) anche per una navigazione alternativa basata per esempio sulla tastiera.
- Andrebbe chiarito meglio l’uso dei metadata RDF, specialmente in vista del Web Semantico. Infatti questi stessi metadati richiedono l’edizione oltre che di dati informativi anche di relazioni tra gli stessi. Questi meccanismi non sono richiesti espressamente nel documento ma faranno comunque parte del web del futuro e richiederanno dunque procedure di edizione ad hoc.
- Andrebbe chiarito meglio il principio generale che l’editore di pagine web si possa creare preferenze personali sulle singole operazioni (per esempio bookmark tra le cartelle dei file del sito).