Tips for improved accessibility in ASP.NET 1.1
If you are an experienced ASP.NET developer but new to accessibility you may have searched the web for ASP.NET accessibility information. It is likely that most of your results have been about how ASP.NET 2.0 promises improved standards support and better accessibility. But 2.0 isn’t here yet. In this article we have a look at what you can do right now to increase accessibility in ASP.NET 1.1 web applications.
Searching for information on how you can increase accessibility in ASP.NET will give you a lot of information on ASP.NET 2.0 (Whidbey) features. It is like Microsoft is trying to hide the fact that the first generation of ASP.NET has issues with accessibility and standards compliance.
Anyway, all is not lost. Here are some tips on what you can do right now to increase accessibility in your existing ASP.NET 1.1 applications. If you are an experienced ASP.NET developer, but new to the field of accessibility make sure you check out some of the other articles here.
1. Try to create standards-compliant pages
If you are using the W3C validator to validate your ASP.NET pages you will notice that no matter what you do in Visual Studio .NET 2003 they will not validate. This is because ASP.NET will ouput hidden HTML to manage view state. However, it is possible to rewrite the output before it reaches the browser. This of course has some impact on performance but if you are using your output cache correctly the performance hit will be of minor importance. There are several ways to rewrite output to make it standards compliant:
- A C# class to make your ASP.NET pages XHTML valid. A short tutorial with code samples.
- Valid XHTML within .NET.
- Ensuring XHTML compliancy in ASP.NET
- Producing XHTML-Compliant Pages With Response Filters
- XhtmlWebControls.NET. This is a commercial product. It is a rewrite of all the web controls to make sure they are Xhtml 1.1 compliant.
If you decide to not use any of the above you can still make sure that your web pages use proper semantic markup. You can still use the W3C validator to check for other validation errors. If your application can’t be reached from the internet you can use the Web developer toolbar Firefox extension to validate single pages. If you are working on a large scale project you can set up a validation server and automate testing (instructions in my previous post “Validating an entire site“.
2. Update to .NET Framework 1.1 Service Pack 1
Service pack 1 includes an important update of the datagrid control enabling output of real table header elements and table captions. After the upgrade you can set the UseAccessibleHeader property to true and your datagrid will use the <th> element for the grid headers.
This service pach also contains a fix for the asp:label control. More on that below.
3. Use real labels for your form fields
When designing web pages in Visual Studio .NET 2003 it is easy to quickly set up a web page with form fields. However, using the asp:label control to create field labels is bad as it will be translated to a simple <span> element. You are better off writing the HTML for the label yourself as the visual designer will give you no help. Switch to the HTML source view and use the following code to create a label for your form element:
<label for="<%=TextBox1.ClientID%>">My label text:</label>
You may wonder what the “TextBox1.ClientID” is doing there. As you may know, ASP.NET creates a unique id for all elements that have the attribute “runat=server”. So, to make sure your label is properly connected to your form field you can use “TextBox1.ClientID” which will be translated to the rendered client id of your TextBox1 field.
If you have applied Service Pack 1 you can use the AssociatedControlId property of the asp:label element and get the same result.
4. Do not rely on client-side validation
ASP.NET enables you to easily add client side validation to forms. This method relies on javascript and will be hard to use for vision impaired users (see previous discussion on AJAX and accessibility). It is likely that they will not get any information at all about validation errors. You can still use the server side validation functionality of ASP.NET. Make sure you present your validation errors in an accessible way.
If you have any more tips you feel would be valuable for ASP.NET developers, please post them below.
Thanks. Quite useful.
Personally I find using XML/XSLT is much more powerful and gives finer control of the output that you need to create. Using ASP.NET on the server side is still useful for the OO power that .NET gives, but we just typically override the Render() method in a base Page class, which transforms xml data (this of course assumes you can get your data in XML format easily) with a specified XSL.
The child classes, the actual pages, simply set the data, which XSLT to use, and any XSLT Parameters that might be needed.
For optimization, as well as page output caching, the XSLT can be compiled and cached into the Cache object, with a dependency on itself, so that when it changes, the cache is appropriately invalidated.
This has worked quite nicely for us on a very, very high profile site (not sure I can mention it just yet).
Anyway, I had another question:
What do you think about the limitation, typically, of one form for the entire page? Sometimes, semantically, and for accessibility, it would make sense to break parts of a page into multiple forms (e.g. a form at the top of the page may be for searching, a form near the end of the article may be for comment posting, and another form somewhere else could be for email subscription or something.)
While technically this can be made to work in one form, semantically these are all different forms, and for assistive technology, they could present different forms for the user to fill in.
Hence, I believe that the one-form-suits-all approach of Visual Studio .NET is not always appropriate (another reason why XML/XSL approach works for us).
Apologies for the long comment!
Anup
Anup, thank you for your comment. Great input about using XML/XSLT for the UI. Another way of doing it is to turn off view state and do plain html pages. This is similar to your approach and require you to write your own form/event handling (just like “old school” ASP).
Regarding the limitation of one form for the entire page I don’t think it affects accessibility that much. If you want to use multiple forms, check out the open source component WilsonWebForm which allows you to use multiple forms in the same page.
There is a lot of useful stuff at ASP.NET Resources, including a filter that rewrites the output HTML.
I think it’s very important to shed some light on this, so web developers know about .NET’s flaws and how to handle them.
However, I still like to see myself as the first Swede out with such a blog post: How to generate valid XHTML with .NET :-)
Thanks for this article! This is very useful information for those of us that will not be able to jump on the .NET 2.0 bandwagon for a while.