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.
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.
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.
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).
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.
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.
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.
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.