Esistono due sistemi per consentire concretamente all'utente di cambiare lo stile di presentazione di una pagina, in modo da adattarla alla sue preferenze. Il primo sistema, molto utilizzato, è quello di accoppiare gli stili CSS alternativi predisposti dall'autore ad appositi JavaScript, che – senza dover ricaricare via Internet il contenuto della pagina – sono in grado di applicare "al volo" i vari stili, in base alle scelte dell'utente.
Un esempio suggestivo di applicazione di questo sistema è fornito dal sito di Eric Meyer, vero guru di livello mondiale per quanto riguarda la conoscenza e l'uso dei CSS.
Nella pagina di personalizzazione del suo sito sono presenti opzioni che consentono all'utente sia di impostare la grandezza dei caratteri sia di cambiare radicalmente lo stile grafico della pagina (tipo di caratteri utilizzato, colori di sfondo, immagini decorative, posizione dei menu). Il tutto è gestito per mezzo di fogli di stile alternativi e di un JavaScript. Quest'ultimo fornisce il meccanismo per passare da un foglio di stile all'altro. Riportiamo di seguito un brano di codice, tratto dalla suddetta pagina di Meyer, che mostra come richiamare i file CSS ed il JavaScript:
[...]
<link rel="alternate stylesheet" href="/ui/aware.css" type="text/css" title="Aware" media="screen, projection">
<link rel="alternate stylesheet" href="/ui/classic.css" type="text/css" title="Classic" media="screen, projection"> [...] <link rel="alternate stylesheet" href="/ui/natural.css" type="text/css" title="Natural" media="screen, projection">
<link rel="stylesheet" href="/ui/basic-print.css" type="text/css" media="print" title="Print styles">
<script type="text/javascript" src="/ui/styleswitch.js"></script>
[...]
Da notare il valore "alternate stylesheet" dell'attributo "rel". Le regole su come impostare fogli di stile alternativi usando l'attributo "rel" sono consultabili nel 14° capitolo delle Specifiche HTML 4.01. Da notare, ancora, il criterio utilizzato per nominare i file CSS alternativi: hanno tutti lo stesso nome espresso nel valore del corrispondente attributo "title" (un modo per non confondere gli stili l'uno con l'altro). Da notare, infine, nell'ultima riga, il collegamento al file JavaScript esterno, che contiene lo script in grado di far funzionare il meccanismo.
Il grande vantaggio del sistema utilizzato da Meyer sta nella velocità di applicazione delle modifiche: il cambio di presentazione è infatti pressoché immediato, poggiando interamente sulle capacità riproduttive del browser. Il grosso limite sta, invece, nella non universalità del metodo: affinché funzioni occorre infatti a) che il browser utilizzato dall'utente supporti JavaScript; b) che lo script sia tarato per quello specifico browser. Il secondo requisito è tutt'altro che semplice da rispettare, considerati il gran numero di versioni esistenti dei principali browser e la gran quantità di combinazioni possibili delle tre variabili in gioco: 1) sistema operativo, 2) tipo di browser, 3) versione adoperata. È un metodo, inoltre, per nulla economico: ad ogni rilascio di nuovi browser o nuove versioni di vecchi browser - cosa che accade piuttosto di frequente - lo script deve essere rivisto ed eventualmente adattato per supportare correttamente anche i nuovi programmi.
Per approfondire l'argomento ed ottenere consigli e soluzioni consigliamo la lettura dell'articolo "Cambiare al volo i fogli di stile" di William Verdolini presente nella sezione PRO.HTML.it
Il secondo sistema - meno diffuso tra i siti che offrono personalizzazioni a fini di accessibilità - si differenzia dal primo per il fatto che utilizza degli script lato server, invece che lato client, per consentire all'utente di modificare lo stile di presentazione dei documenti. La prima pagina di Diodati.org offre un esempio di applicazione di questo metodo. Nella versione grafica predefinita, l'utente visualizza un'impaginazione a due colonne. Tuttavia, per un lettore ipovedente questo tipo di soluzione può risultare scarsamente leggibile. Viene dunque offerta la possibilità di modificare la presentazione passando ad un'impaginazione basata su una sola colonna. Attivando il collegamento sulla scritta "impaginazione a colonna unica", posta proprio alla sommità della pagina, l'utente non richiama un JavaScript eseguibile dal proprio browser, ma ricarica la pagina direttamente dal server remoto, aggiungendo al nome della risorsa ("index.asp") un parametro di query ("coldx=0"), che innesca una serie di eventi previsti dal codice di programmazione lato server. Il risultato è che il server remoto fornisce al browser dell'utente una nuova versione della pagina, in cui tutti i contenuti sono ora disposti su una sola colonna.
Il grande vantaggio di questo sistema sta nella sua maggiore universalità, rispetto alla programmazione che agisce sul lato client. Non è richiesto infatti che il browser dell'utente supporti JavaScript né tantomeno è richiesto allo sviluppatore di fare prove su prove, per elaborare uno script compatibile con le innumerevoli combinazioni di sistema operativo, browser e versione di browser esistenti, che rendono così difficile ottenere JavaScript di larga applicabilità. Lo svantaggio è dato, invece, dalla possibile lentezza di esecuzione del cambio di presentazione della pagina. Lo script, infatti, viene eseguito sul server e ciò produce due inevitabili fonti potenziali di ritardo: 1) la necessità di ricaricare via Internet il documento, con le conseguenti attese dovute al normale traffico di rete; 2) il possibile sovraccarico di lavoro del server, nel caso che ospiti – come spesso avviene – anche altri siti e che giungano contemporaneamente numerose richieste di servire pagine ed eseguire script.
Quale dei due metodi è da preferire? Non è possibile dare una risposta assoluta: dipende dai casi. Dal punto di vista dell'accessibilità, le soluzioni universali sono sicuramente preferibili: permettere all'utente di modificare la presentazione della pagina indipendentemente da se il suo browser supporti JavaScript oppure no, sembrerebbe in linea teorica la soluzione migliore. Tuttavia la sua adozione deve essere valutata attentamente: se, infatti, il traffico di rete e il sovraccarico del server rallentano troppo l'attuazione della modifica richiesta dall'utente, si incorre in un problema di accessibilità forse peggiore di quello che si intende risolvere (cioè rendere il più universale possibile l'applicabilità della modifica).
Possiamo quindi concludere che, per siti che non generano un eccessivo volume di traffico o che sono ospitati su server molto performanti, la soluzione migliore è servire agli utenti le modifiche di presentazione per mezzo di script lato server. Invece, per siti in cui il volume di traffico generato e i tempi di risposta del server possono costituire un problema, la soluzione migliore è ricorrere a script lato client, opportunamente combinati con fogli di stile alternativi.
