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.

One of the design goals is that pages will work well with JavaScript turned off and with CSS styling turned off. JavaScript should only enhance the browsing experience when available but it should not break the page when it is not available. This means that drop down menus are marked up as regular XHTML lists of links. These are accessible to people using screen readers or with JavaScript turned off. When JavaScript and CSS are available those lists will be converted through the DOM to drop down menus with fancy shading etc. We have had CSS and accesibilty experts working on creating the stylesheets, JavaScripts and templates for accessible pages.

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.

For the content management system this was not so difficult to implement.  But for ASP.NET 1.1 it was. As you may know the default output of ASP.NET is not XHTML compliant. Furthermore it has a lot of controls that output JavaScript that does not work well outside of Internet Explorer. There is poor support for using CSS. The HTML editor is a disaster. I could go on, but to cut the list short, I will jump to the conclusion: we had to roll our own custom controls and page rendering.

We use the standard ASP.NET Page model, its lifecycle and its postback model. We don't use most of the standard controls and we have build our own custom controls. These custom controls render XHTML 1.0 Strict output and can work with or without JavaScript in a cross-browser compatible way. Without JavaScript the standard ASP.NET auto postback functionality will not work. For instance when you select another radio button the page cannot not be posted back automatically. With standard ASP.NET you are out of luck if want to modify the page in response to the user selecting another option. When JavaScript is not available we render  submit buttons next to such controls to allow the user to update the page. This simulates the auto postback behaviour. So how do we know if  the user has turned JavaScript  off  when we render the page on the server? We don't. The trick is to always render these extra submit buttons, and then remove them from the page using clientside DOM manipulations when JavaScript is available.

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.

After fixing the XHTML issues, parts of the ASP.NET output are mapped into container elements in a XHTML 1.0 Strict content template. This content template comes from the content management system. It contains the skeletons for the layout of the page and the references to external stylesheets and JavaScripts. The .NET module inserts its own title in the title tag of the template and adds additional meta elements to the document. These mappings can be configured in a flexible way using an XML configuration file that is read using the Enterprise Library at run-time. Think of our mapping functionality as "XSLT light". After the mappings have been performed, the resulting XHTML document is rendered to the standard ASP.NET output stream. If all goes well the browser receives an XHTML 1.0 Strict compliant and accesible page rendered by ASP.NET 1.1!

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 😉

One thought on “XHTML 1.0 Strict compliant and accessible output from ASP.NET 1.1

  1. Nathan J Pledger

    Thanks Erwyn for the accolade!

    Firstly, it would be interesting to find out what content management system you are using. A project, in the Netherlands? I wonder if we are using the same package? If its one based out of Denmark, that is.

    I really like the ideas you've used. JavaScript to hide accessible content is a good idea. My outlook is the same: scripting should complement the site, not form its function. Unfortunately, accessibility often becomes a bit of a black art - with hacks having to be made to CSS and scripting required to modify the DOM.

    I've played with a few means of outputting XHTML Strict. I am playing around with the idea of sending my own content out from the server programmatically at the moment, and just seeing how much control I have over the rendering process. I'm sure I'll post my results!

    BTW: Too late! I have used the editor, which Jan kindly gave me tips on using. 🙂


Leave a Reply

Your email address will not be published. Required fields are marked *