Thu, Aug 18 2005 7:42 PM
Erwyn van der Meer
XHTML 1.0 Strict compliant and accessible output from ASP.NET 1.1
Since last week we have an accessibility expert blogging on BloggingAbout.NET: Nathan J Pledger. His first post inspired me to blog about my current project.
As I mentioned in a comment on Nathan's first post, I currently work in a team on the new web site for one of the major financial institutions in the Netherlands. This web site will go live sometime later this year. Most web pages on that site come from a content managent system. All web pages are designed to conform to the XHTML 1.0 Strict standard. I.e., they should be valid when being validated against the XHTML 1.0 Strict DTD. This in itself helps in creating an accessible site by separating layout and content and working well across different browsers.
Extraordinary care is taken to ensure that markup is semantically correct. Tables are only used for tabular data and not for layout. Lists are marked up using the XHTML elements for lists: ul, ol and li. Etc. etc.
ASP.NET is used for dynamic pages that depend on user input, like pages that give advice on what type of savings account is best suited for someone. I will call these types of web applications within the site .NET modules.
Having custom controls that render XHTML 1.0 Strict is not enough when you want to use the standard postback model. There are two well known problems with the standard ASP.NET output. The form element rendered for postbacks by ASP.NET contains an illegal name attribute according to the XHTML 1.0 Strict DTD. And the <input name="__VIEWSTATE" .. /> element should be wrapped in a container element like a div.
To fix these issues we post process the ASP.NET output by using a response filter. This filter is installed by an IHttpModule in the ASP.NET pipeline for each request for an ASPX page. This response filter parses the ASP.NET output as XML. If the ASP.NET output is well formed XML, this is already a good step on the way to XHTML compliance. A developer will know instantly that there is a problem if the output cannot be parsed as XML, because the filter will throw an InvalidAspNetOutputException.
Most approaches to fixing ASP.NET output mentioned on the web use regular expressions or other forms of string parsing to fix the output. We use XML parsing because we have to do additional manipulations on the output on top of fixing the XHTML issues. We have to integrate the ASP.NET output with static pages published by the content management system. Parsing the ASP.NET output as XML imposes a significant overhead with noticably longer processing times on the server, but in our case the resulting performance is acceptable.
In another post I will go into some additional design goals that we had, like not showing the .aspx extension in URLs and I will tell more about how we integrated with the content management system.
BTW: Don't look at the HTML code for postings on this Community Server. It contains horrendous old style markup with font tags all over the place ;)
Filed under: .NET, Work