Analisi - WCAG 2.0 W3C Working Draft 11 November 2004

Nelle tecniche per il primo criterio, la 9.4 delle tecniche per HTML propone:

Many kinds of links have both a text and iconic link adjacent to each other. Often the text and the icon link are rendered in separate links, in part to create a slight visual separation from each other. Visually they appear to be the same link, but they are experienced by many people as two identical links and can be confusing. To avoid this, some authors omit alternative text from the image, but then there is a link with an unclear destination. The preferred method to address this is to put the text and image together in one link, and provide null alternative text on the image to eliminate duplication of text.

Il primo esempio propone di inserire due collegamenti adiacenti, uno per l'immagine e l'altro per il testo che portano alla stessa identica pagina.
Questo potrebbe non essere completamente corretto verso le possibilità relazionali dell'HTML, che correttamente marcate con meccanismi come rel e rev, permettono di identificare le relazioni tra i documenti.

Inoltre il secondo esempio dove sia l'immagine, sia il testo sono nello stesso collegamento, mi sembra molto più corretta è funzionale.

Nelle tecniche per il primo criterio, la 5.1 delle tecniche per HTML propone di non usare gli elementi di formattazione HTML per dare una formattazione alla pagina, si specifica inoltre che però questo è solo consigliato.

La nota che volevo mettere su questo punto è di non crocifiggere alcuni elementi come B o I poichè permettono naturalmente di creare un enfatizzazione visiva separata dall'enfatizzazione semantica. Per esempio permettono naturalmente la seguente separazione:

Telefonami allo <b>041000000</b>, <em>solo</em>, in casi d'emergenza.

La prima enfatizzazione dovrebbe risultare visiva per migliorare la leggibilità della frase, la seconda invece ha un significato semantico dettato dalla stessa pronuncia della frase.

Si potrebbe inserire una nota esplicita che chieda di risolvere il linguaggio in qualunque nome proprio o aziendale.
Questo permetterebbe una corretta pronuncia di tal nome.

Esempio (predefinito in italiano):

Di fatto solo il secondo esempio è corretto e il tutto vale ancora di più per i nomi propri di persona.
Bisogna inoltre pensare che nomi propri come "Andrea" in culture linguistiche diverse verrebbero interpretate come di sesso diverso.

Esempio:

Si consiglia di inserire anche una nota che chiarisca come gestire eventuali acronimi annidiati.

Esempio:

Con l'introduzione di XML quale tecnologia padrona nella definizione e strutturazione di dati e linguaggi di marcatura, questo punto delle WCAG 2.0 tente ad essere abbastanza problematico.

Infatti in un ottica XML non esiste un solo linguaggio che non sia formalmente valido se rispetta alcune regole base come la definizione di namespace o di definizioni di documento (DTD e/o XSD).

Quindi il seguente esempio è logicamente valido:

Nonostante la validità logica del documento il validatore ci ritorna errore.

Nota: bisogna stare attenti a questo tipo di potenzialità di XML, infatti permetterebbero la proliferazione libera di una miriade di formati proprietari atti all'esecuzione di programmi (es: alternative a SVG). Sarebbe meglio contemplare l'uso di queste potenzialità di XML in un ottica di marcare solo dati informativi e comunque prediligendo sempre i formati raccomandati dal W3C.

Per quanto riguarda l'accessibilità di XML valgono chiaramente le XAG.

Nota: il seguente approfondimento è molto orientato a domande e/o teorie molto aperte, che possono fungere da suggerimenti.

• Nelle tecniche per l'uso dell'elemento Address si propone di regola un collegamento ad un URI riguardante l'autore direttamente sul suo nome, ma in fondo questo non è nient'altro che citare l'autore, quindi non sarebbe più corretto usare l'elemento Cite, per poter così in XHTML 2.0 sfruttare direttamente la sua proprietà href ?
• Nelle tecniche per gli Heading bisogna ricordare che se è vero che non bisogna saltare l'ordine degli heading, è anche vero che l'ordine può ripartire ogni qual volta l'heading è contenuto in una sezione con un id univoco. Quindi una pagina può partire da H1, arrivare fino a H4 e poi in una divisione univoca ripartire da H1 secondo le necessità logiche e semantiche del documento.
• Nelle quotazioni di testi, consigliare sempre l'inserimento di un URI che ne indichi la fonte tramite l'attributo cite. Questo potrebbe permettere in futuro un maggiore accesso alle informazioni.

Nota: il seguente approfondimento è molto orientato a domande e/o teorie molto aperte, che possono fungere da suggerimenti.

• Nelle poche note riguardanti i CSS aurali bisogna tenere conto che un controllo totale sulla lettura sonora della pagina HTML può in determinate circostanze creare grossi problemi. Infatti un suono, a determinati parametri di frequenza, ampiezza, ecc... può provocare reazioni inaspettate nell'uditore, a volte anche dannose e simili agli effetti che possono provocare immagini lampeggianti.

Nota: il seguente approfondimento è molto orientato a domande e/o teorie molto aperte, che possono fungere da suggerimenti.

• Per le tecniche per la gestione degli URI nei form (1.1), l'esempio di validazione sarebbe ancora più corretto e interoperabile verso il futuro gestendolo nel seguente modo:
  nell'head:
  <script>
  onload = function() {
  if(document.getElementById)
  document.getElementById('form').onsubmit = return checkFormFields();
  }
  </script> nel body:
  <form action="submit.php" id="form">...</form> La stessa metodologia può essere correttamente applicata per le tecniche della gestione degli URI in javascript (2.1).
• Le tecniche per il cambiamento del focus non sono ancora state definite, comunque la possibilità di cambiare costantemente il focus nelle applicazioni web è una funzione sostanziale. Infatti permette di gestire le applicazioni web molto complesse e dinamiche con estrema facilità, interpretando la pagina in maniera sequenziale. Per approfondire si veda il capitolo sui linguaggi di scripting del libro Accessibilità: dalla teoria alla realtà di Roberto Scano.
• In generale sfruttare al meglio le potenzialità del DOM e dei suoi gestori di eventi cercando di aggangiare le strutture di programmazione alle strutture dati.
  Esempio:
  nell'head:
  <script>
  onload = function() {
  if(document.getElementById)
  var st = document.getElementById('stats').
  st.onclick = st.onkeypress = return checkStats();
  }
  </script> nel body:
  <a action="statistiche.html" id="stats">statistiche 2004</form>