Lo scorso aprile ho avuto l'onore di essere uno degli speaker presso il 3° workshop organizzato da DotNetMarche relativamente all'Accessibilità dei siti Web. In quella occasione, tra le varie interessanti riflessioni, sono stati approfonditi molti aspetti teorici e tecnici riguardanti le sfide che uno sviluppatore Web dovrebbe fronteggiare per realizzare applicazioni conformi a standard di accessibilità riconosciuti a livello sia nazionale che internazionale.
Purtroppo, navigando in diversi siti marchiati dalla PA e non solo, ancora oggi si può notare come la maggioranza degli sviluppatori Web non diano sufficiente peso all'importanza di renderizzare contenuti XHTML (almeno) strutturalmente corretti in base ai DOCTYPE dichiarati.
Probabilmente, per un certo verso si fa sentire ancora quella che molti definiscono come una "mancanza" dei principali vendor dei browser visuali, che tramite il DOCTYPE sniffing permettono mirabilmente di correggere al volo degli errori concettuali e strutturali nel rendering dei documenti Web, rifugiandosi in modalità più o meno standard/retrocompatibili (*), per la precisione:
- IE/Netscape modes: Standards - Quirks
- Firefox/Opera modes: Full Standards - Almost Standards - Quirks
(Notare come Firefox e Opera siano più bacchettoni specificando due sottotipi (Full e Almost) dello Standards mode:
http://developer.mozilla.org/en/docs/Mozilla%27s_DOCTYPE_sniffing)
Il tutto, chiaramente, a danno dell'accessibilità. Utilizzare XHTML significa anzitutto adottare la filosofia "separazione tra contenuto (XML) e presentazione (CSS)" e tutti sappiamo come ciò sia oggi consigliabile da un punto di vista tecnico ed obbligatorio per i siti Web destinati alla PA nonché ad un utenza diversamente abile. In questo senso, le specifiche W3C hanno sempre insistito molto nei confronti dei vendor di Authoring Tools, non solo finalizzati allo sviluppo Web (vedi le specifiche ATAG), con lo scopo di spingere verso l'utilizzo di application/xhtml+xml come MIME type predefinito (non supportato tra l'altro da IE) nella fornitura di contenuti XHTML. In effetti, il well-forming strutturale di un documento XHTML è il primissimo passo verso la cosiddetta "standard conformance" ed il raggiungimento di contenuti accessibili.
Interessante in questo contesto è il percorso di ASP.NET: dalla completa assenza del supporto ad XHTML della versione 1.x si è passati al supporto nativo nelle versioni successive, scegliendo XHTML 1.0 Transitional come DOCTYPE predefinito (per far contenti tutti) ed integrando un utile strumento di validazione a partire da VS2005 (da prendere però con le molle in quanto non permette di controllare XHTML renderizzato lato client). Il MIME type di default invece è rimasto lo stesso: text/html. In altre parole il comportamento di default è: "erogare contenuti xhtml mantenendo la 'genericità' dei documenti html".
Nella speranza che tutti un giorno sviluppino seguendo specifiche rigorose come XHTML 1.0 Strict / 1.1 (meglio), riporto un esempio di HttpModule che implementa uno dei workaround più consigliati per erogare contenuti application/xhtml+xml, chiaramente qualora lo user agent richiedente dichiari di supportarlo:
public class ContentTypeModule : IHttpModule
{
public void Init(System.Web.HttpApplication application)
{
application.PreSendRequestHeaders += new EventHandler(this.Application_PreSendRequestHeaders);
}
private void Application_PreSendRequestHeaders(object sender, System.EventArgs e)
{
HttpApplication app = ((HttpApplication)(sender));
HttpContext context = app.Context;
if (Array.IndexOf(context.Request.AcceptTypes,"application/xhtml+xml") > -1)
{
context.Response.ContentType = "application/xhtml+xml";
}
}
public void Dispose() { }
}
Due curiosità:
-
Application_PreSendRequestHeaders è un evento disponibile anche nel Global.asax
-
Tramite l'array di stringhe Request.AcceptTypes possiamo osservare tutti i MIME Types accettati da un particolare browser: IE ad esempio è il più furbo poiché dichiara semplicemente " */* " (ovvero: accetto tutto!!!) mentre ad esempio Firefox dichiara, in ordine di preferenza, text/xml, application/xml, application/xhtml+xml ... e */* alla fine.
(*) Per capire in maniera approfondita la differenza tra Standard e Quirks mode consiglio vivamente la lettura di questo completissimo articolo:
http://www.quirksmode.org/css/quirksmode.html (la tabella in fondo chiarisce ogni dubbio sulla sostanziale differenza esistente tra il rendering standard e quello retrocompatibile)
Technorati tags:
XHTML,
W3C