Si parla diffusamente ormai di validazione del codice, di scrittura di codice conforme alle WCAG.

Anche nelle rare occasioni in cui si instaura un proficuo scambio di opinioni con addetti ai lavori, semplici appassionati, committenti e tecnici della comunicazione pubblica, resta sullo sfondo come un’ipotesi oscura e quasi angosciosa quell’attività artigianale di elaborazione del codice che costituisce la materia ostica ma essenziale per realizzare contenuti accessibili.

Non si trovano guide semplici in grado di avvicinare in modo efficace alla scrittura di codice conforme alle WCAG, anatroccoli, analogia con lo script semplicee la correzione di pagine statiche – che pure è cosa tutto sommato fattibile e alla portata di tutti gli interessati – rimane uno scoglio increscioso, oltre il tempo degli impegni e degli svaghi. Quando poi si insinua nella mente il dubbio sulle modalità per una analoga pulizia del codice per pagine dinamiche, spesso le idee si confondono lasciando spazio a incubi e chimere…
Con queste pagine vorrei far vedere che la trasformazione di pagine dinamiche, con la finalità di superare la validazione, è un’attività divertente e appassionante, due esemplari di Anatidi in una elaborazione grafica, analogia con gli script complessi e un’occasione per studiare il codice e comprendere cosa succede nel gioco client-server quando di mezzo si introduce un linguaggio di programmazione lato server. Esamineremo riga dopo riga uno script semplicissimo in PHP, e lo trasformeremo fino ad ottenere una pagina che supera il test del validatore del W3C e di Bobby (AAA).
Gli script complessi si comprendono a partire dai semplici 🙂

 

Cosa succede quando il browser richiede una pagina dinamica al Server?

Il Web Server richiama il PHP engine, se si tratta di una pagina PHP, o IIS per le ASP. Il motore elabora lo script presente nella pagina e restituisce al browser, creandolo al volo, l’output HTML, che viene visualizzato.

schema del processo di generazione di pagine dinamiche

Quindi la pagina costruita e caricata sul Server non presenta lo stesso codice che legge il navigatore dopo “clic tasto destro+visualizza HTML”.
Qui è il nocciolo della questione.

Per ottenere una pagina dinamica validata, dovremo prevedere l’aspetto del codice dopo l’elaborazione del parser.

Con le pagine statiche tutto è più semplice, si può lavorare comodamente in locale, il codice è scritto una volta per tutte, e le correzioni da effettuare dopo il testing col validatore si basano sul confronto di due elementi (il codice e il report del validator).
Un errore in un codice generato dal motore lato server va invece fatto risalire al codice sorgente, e la modifica non sarà un semplice adeguamento fra un testo corretto e lo stesso testo sgrammaticato. Si tratta di …identificarsi con il parser e prefigurarsi, intervenendo nel codice sorgente, la pagina interpretata dal browser.
Si può immaginare la straordinaria complessità della validazione di uno script esteso, composto di più file, o di un CMS in grado di generare pagine validate e accessibili (come il CMS che fa vivere questo sito). I concetti essenziali che stanno alla base della validazione di pagine dinamiche sono presenti anche negli script più elementari, e qui è più agevole impadronirsene.

Ho scelto uno script di Leon Atkinson: Simple BBS system using MySQL [link esterno, apre una nuova finestra], che si compone di un centinaio di righe.
Consente di postare commenti e di rispondervi su più livelli ad albero.

Per seguire la trasformazione del codice e verificare i risultati in modo attivo, si deve creare un database. E’ possibile naturalmente effettuare l’esperimento in locale, se si dispone di uno dei molti tool free-of-charge disponibili nella rete, in grado di installare Apache, MySql e PHP nel proprio PC. 
Potrai testare gli esiti delle modifiche al codice utilizzando le pagine che ho preparato, collegate ad un database MySql.
Sottoponiamo innanzitutto il codice originario al test di Bobby.
Il test si effettua all’indirizzo http://bobby.watchfire.com/, digitando l’indirizzo della pagina da testare nell’apposita form.
Otteniamo una serie di errori.
Not Bobby AAA Approved
Per ciascun errore si rimanda ad una pagina dove si pongono a confronto il codice di output, il codice sorgente e il codice corretto.
Nelle pagine troverai anche link allo script nelle varie fasi di ottimizzazione, funzionante. Puoi anche postare commenti, ma fai attenzione a non usare un oggetto già esistente 😉 creeresti due link con la stessa etichetta e il validator segnalerebbe l’errore (priorità 2) “Do not use the same link phrase more than once when the links point to different URLs”.
Le pagine di esempio dispongono del link a Bobby: per testare le varie fasi di trasformazione ti basterà un clic 🙂

[Va precisato che il nostro percorso si limita alla validazione “automatica”. L’accessibilità va poi curata per tutti quegli aspetti che non sono testabili via software. Per un approfondimento consulta le pagine dedicate a Bobby in questo sito.
Oltre ad autorizzarmi all’uso esemplificativo del suo script, molto gentilmente Leon Atkinson mi ha inviato la versione aggiornata. Ho usato la versione base per ovvi motivi di semplificazione del discorso, ma se ti vorrai cimentare nella validazione della nuova versione puoi trovarla nel sito di Atkinson [link esterno, apre una nuova finestra], insieme a molti altri script inclusi nel suo libro Core PHP Programming (lo script è nel file 17-7.php).]

I collegamenti alle pagine di test su server aprono una nuova finestra del browser.

Errori nel codice originario ( visualizza la pagina funzionante ed esegui il test ):

Priority 2 Accessibility errors found:

  • Use relative sizing and positioning (% values) rather than absolute (pixels). (7 instances) >>> prima trasformazione
    Lines 17, 18, 19, 20, 21
  • Explicitly associate form controls and their labels with the LABEL element. (3 instances) >>> seconda trasformazione
    Lines 18, 19, 20

Priority 3 accessibility errors found:

  • Provide a summary for tables. (1 instance) >>> terza trasformazione
    Line 17
  • Include default, place-holding characters in edit boxes and text areas. (3 instances) >>> quarta trasformazione
    Lines 18, 19, 20