My Response to ASP.NET 2.0 Accessibility
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.