Erwyn kindly pointed me to the article below:
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/aspnetusstan.asp
This article covers the use of ASP.NET 2.0 to generate accessible web sites. The article explains how the ASP.NET engine now emits XHTML code, has improved accessibility features and has been very much re-thought in terms of flexibility of development to a number of Web standards - both lax and strict.
The Problem with ASP.NET 1.1
The core issue of ASP.NET 1.1 was always that you were limited to what Microsoft targetted the language to. This was an extremely lax version of HTML 4, which seemed to have a determined preference to the even more lax Internet Explorer browser. Before .NET was released, we were promised controls that looked the same no matter the target browser, with little or no further effort on the part of the developer. This was delivered using the <BrowserCaps> tag, which is now kept unmaintained by the company concerned and whose "default" Microsoft output resulted in horrendous tables and other such inaccessible output.
Futher, the platform was made up of a series of powerful server controls, that wrapped up the rendering of complex content, such as Data Grids, pick lists, etc. While this was a big step forward in reducing the difference between a desktop application and a web application, this resulted in code being output that was very "closed" and inaccessible. To make these controls accessible, requires extensive re-engineering of the controls.
Finally, while XHTML output was not supported or intended, a number of solutions have popped up that help to convert the output of the ASP.NET service to XHTML. These are, however, largely a series of patches to Global.asax and DLL's.
ASP.NET 2.0 : My first thoughts
Firstly, let me say that I have not actually used a copy in anger, as Microsoft don't seem to want to send me a Beta in the Isle of Man! However, I have been keeping my ear to the ground with regards accessibility and web standards in ASP.NET 2.0.
I liked the CNN idea of having the single pixel image, with an ALT tag of "Skip navigation". As the article says, a screen reader has to read through a load of links on a lot of web-pages, before the actual content is reached. This is often unnecassary. This can be solved in two ways. The first, mentioned in the article, is to have a link at the top of the page that allows the navigation to be skipped. By selecting this, which links to a named anchor at the top of the "body", the user can jump straight to the content they're interested in. The use of a single-pixel transparant GIF ensures users wouldn't see this unless they were using an accesisble browser. I prefer not to use images, however. My preference would be to render it in text, and use CSS to hide it from any browser that understands CSS by putting a class such as:
*.skipNavigation { display: none; }
In a top level CSS file (as some browsers can't read @import statements, it is possible to create multiple levels of accessibility by using a hierarchy of CSS pages). This would hide the text, form normal browsers, and would avoid the screen reader announcing "image" before the image link. And remember - some browsers ignore images, or users turn them off. Consider a mobile phone - why pay for pointless images, turn them off and speed the experience up! The Menu control seems to remove this flexibility.
The second way I like to do this is to have the content first. On a tradiitonal page design, the links are either placed at the top or the left. This means the first thing that will be read will be the links, not the content - which is after all wha the page is there for. It is often useful to place the content first in the HTML markup, followed by the navigation. If these individual sections are placed in appropriately managed DIV's, it is possible to use CSS to place the navigation "before" the content so it adopts a traditional page design in a standard browser, while an accessible browser will dive straight in to the content. (You may like to provide a "Skip To Navigation" link before it, though). Again, the Menu control removes this flexibility.
Wrapping up functionality inside server controls is welcome, as it removes much of the drudgery involved in writing web-pages. A server control that performs the equivelant of a Button, or even a DataGrid, is welcome. However, it becomes something else when these controls are "over-overloaded". Instead of relying - and possibly requiring - the developer to create a navigational list that is accessible, or just of a decent standard of markup, these are wrapped up in the Menu control. This removes the fine level of control that is often required to ensure compliance to XHTML and Accessibility standards, and also reduces the opportunity for the developer to adopt interesting ideas in terms of rendering content. The nature of Accessibility is such that it is very subjective. Microsoft's "catch-all" policy, whereby a Menu control renders as a defined set of markup, immediately limits the idea of an accessible control to a defined set of people. If you're not in this set, tough luck.
Also, the wrapping up and over-overloading of functionality removes the possibility of innovative ideas. For example, while it is perfectly possible to use a DataGrid in ASP.NET 1.1 and overload it so that it becomes accessible, I prefer not to take on the sledgehammer markup that can result, instead using a simpler control that I can finely tune - with ease, such as a Repeater. While not exactly innovative, it is an example of using a simple control to perform added functionality that maybe would not be thought of if an all-purpose control was developed. While I am absolutely sure developers won't necassarily become "lazy", I do think it will stifle creativity and imaginative thinking on more basic controls - which can only improve accessibility and standards adoption.
I think I can "wrap up" by saying that different people want different things out of an accessible experience. Microsoft seems to be closing this experience to their defined set of controls.
What we do need from ASP.NET
I applaud Microsoft for making the step towards web standards, and providing the flexibility to adopt one of a number of different standards. ASP.NET 2.0 will hopefully mark the next step in encouraging web developers to move away from the idea that tables provide equivelant functionality to a DTP package on the web, and that functionality taken for granted for the "normal" browser may be made more accessible to those who struggle. My belief is that the very openness of the web and the ease by which people can learn and develop their own content is possibly too easy. We have become lax, and browsers are developed to accept poor coding. (The resilience of Internet Explorer is truly impressive!)
While I would prefer to stamp out the possibility of bending the rules, I accept that this is not going to be possible. Since the introduction of CSS, it has been an all too slow process to remove formatting from an HTML document. If Microsoft can introduce these standards to its own browser (as it says it intends to do, to an extent, in IE 7), and encourage users to develop better quality pages in the various web-publishing tools made available (Word, FrontPage) to the masses, we should start seeing a slow swing towards adoption of standards, and therefore get closer to an accessible web. Web standards are beginning to turn heads and the introduction of a modern standards based environment from Microsoft is definitely welcome.
Pre-populatiing your fields gives a further hint to the user
Following on from my post Accessible Forms: Using the label control, I'll just add another useful guideline in improving form design.
The Contact Us page on the ARMS site has a good example of how to develop an accessible form.
This form uses the labels discussed in the previous article, but adds a number of additional elements.
Pre-population of fields
The fields are pre-populated with comments such as "(Your name)" to provide additional guidance on what should be inserted into the field. This also provides an ideal way of differentiating nothing from nothing! ie. the difference between a field that should be deliberately left blank, and a field that has been missed. As every hint is wrapped in brackets, it makes summary validation a breeze.
It is perfectly acceptable, and a good idea, to add a bit of JavaScript if the need takes you that empties the field when a user gives it focus, in preparation for input. As this is complemtary to the function of the HTML, it is perfectly accessible and useful.
Fieldset
When developing a form, it should be enclosed in a fieldset tag. This wraps up a form and its contents, which in a platform like .NET is particularly important, as we can only use a single and rather large form which provides no feedback on its purpose or the hierarchy of the various controls on the page. By wrapping it in a fieldset, coupled with a legend tag, we can separate individual forms (eg. Search form, Contact form, etc.) from each other, and style each individually without resorting to weighing the browser rendering down further by using expensive DIV's.
Consider that the form consists of a simple fieldset, similar to that below:
<fieldset id="contactForm_formFieldset">
<legend>Contact Us</legend>
<p>Please complete all fields marked with an asterisk (*),
and any other fields you feel may be useful to your enquiry.</p>
<p>
<span id="contactForm_lblName"><label for="contactForm_txtName">Name: *</label></span><br />
<input name="contactForm:txtName" type="text" value="(Your name)" maxlength="64" id="contactForm_txtName" />
</p>
<p>
<span id="contactForm_lblEmailAddress"><label for="contactForm_txtEmailAddress">Email Address: *</label></span><br />
<input name="contactForm:txtEmailAddress" type="text" value="(Email address)" maxlength="64" id="contactForm_txtEmailAddress" />
</p>
....
<p>If you have any other feedback, please feel free to add it to your existing comment or enquiry.
We will be happy to respond and take your feedbacl into account.</p>
<p><span class="floatRight"><input type="submit" name="contactForm:btnSubmit" value="Submit form" id="contactForm_btnSubmit" /></span>
Click the <strong>Submit</strong> button to send your feedback to us.</p>
</fieldset>
Validation
A personal preference for validation is to highlight errors two-fold. Firstly, I create a UL tag, with items that are erroneous on the form. This provides a quick summary of errors and how they can be corrected. This is placed at the top of the form, in a visible location - for when the page is returned from postback.
Secondly, I have a Validation Class, which is a simple class with an Assert method that adds an assertion to a collection. This can then be used to render the aforementioned UL tag, and highlight each individual control in error by modifying, for example, their background colour to a soft salmon colour. This is not necassarily accessible, its just usable. Putting stars next to the labels does not, in my opinion, make an erroneous field stand out from its neighbours, nor does it form a strong relationship with the actual field element from an accessibility point of view.
If anyone would like this class, as a starting point for their own, please let me know and I shall make it available.