Right, before I get started I want to make two points clear:

The Javascript thing isn’t Microsoft’s fault, they are working within the limitations of what you can do with HTML and needed Javascript to add in additional behaviour. In this case, the blame is to be laid at the foot of the door of the people who think that .NET is the solution to every problem. .NET is a bloody good tool, don’t get me wrong — it’s my favourite development platform. It’s just, like pretty much every tool, it has limitations.

Secondly, the CSS thing is Microsoft’s fault. But I’ll get to that in due course.

.NET, Javascript and Accessibility

Firstly, the javascript thing.

Microsoft .NET uses a lot of things called postbacks which are mostly javascript driven events and tell the page to post back to the server when you’ve done various things which would normally not post back to the server — e.g. you’ve got a DataGrid with hundreds of records in your recordset and you want to only show 15 records at a time via paging.

In this circumstance, the postback would tell the server to “show the next 15 records”, “the previous 15 records” and so on. Obviously, unless this is driven by a whole series of different submit buttons, there’s no way that under normal HTML the information would be posted back to the server and the page updated.

This doesn’t just apply to DataGrid controls, there are a number of other controls which have postback functionality — for example if you have a pair of dropdown lists e.g. continents and countries, you could postback to the server after the first dropdown list is amended and automatically update the values in the second dropdown list accordingly. You could even set the focus of the control to the particular point you wanted so that when the page reloaded a screenreader would (hopefully) pick up from the point you left off rather than reading the page again from the beginning.

Unfortunately this is again driven by the javascript:__doPostBack event generated by .NET. This means that of course if javascript is switched off or not supported, that these functions will not operate.

The ASP.NET server controls that depend on being able to run client script include:

• The LinkButton and HtmlButton server controls require script. (This is not true for the Button Web server control or the HtmlInputButton or HtmlInputImage controls.)
• By default, the Calendar control implements month navigation and day selection using LinkButton controls. If you set control properties to allow users to select a day, week, or month, or if you allow users to navigate to other months, then the Calendar control will generate client script. If you use the Calendar control simply to display a single month with no selection or navigation, the control does not require client script.
• Any Web server control whose AutoPostBack property is set to true; the client script is required so that the control will post the page.
• The Web validation controls, which require client script to support client-side validation. If the client does not support script, validation will run on the server only.

…users sometimes disable script in a browser as a security measure. If they have, the functionality provided by client script is lost. This disables some controls, such as the LinkButton control, entirely, and disables the functionality of the AutoPostBack property.

MSDN

Now let’s get this clear: this isn’t Microsoft’s fault. They are working within the limitations of HTML and they’ve created a really useful application that has lots of advanced features that can be used if javascript is supported. Unfortunately, you cannot rely on these if you need to comply with WCAG 1.0 at any conformance level, because if you’re relying on any of these features then you will fail checkpoint 6.3:

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.WCAG 1.0

…and of course if you’re going to have to provide the function/information in a different way on a different page, then what’s the point of doing it again using the .NET controls?

The problem here is that .NET is a well known application and development platform across the industry and from my experience the assumption seems to be that the built in controls will satisfy accessibility requirements. Whereas in fact a number of them will only work if javascript is supported and leave users with no javascript support unable to use your site. This is not a case of Microsoft not telling you — as you can see above they are explicit about it — it’s more a case of people not checking or not thinking of what a postback actually entails.

How to fix it? Well, there’s no easy answer, but basically you need to rewrite all of these features so that they post back to the original page using submit buttons and URL query strings to update the information. It’s far from being an ideal solution because it means that much of the neater functionality of .NET is closed off to you without access to javascript, but like I keep saying, that’s not Microsoft’s fault.

So just be aware that if you’re using .NET to develop internet applications that you can’t rely on the all of the standard controls to be fully accessible — many of them require javascript.

But if anyone can come up with a way to resolve this without breaching WCAG 1.0 checkpoint 6.3, please do let me know! Meanwhile, I won’t be holding my breath…

Layout Tables in .NET

The other problem with .NET is it’s particularly heavy reliance on the use of layout tables. I’ll forgive them a table if you create a DataGrid — it’s a data grid, so it’s a data table after all — but MenuViews, TreeViews, DetailsViews and FormViews will all generate layout tables by default.

This is in breach of the checkpoint 5.3 (priority 2/AA conformance level) which states:

5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2]

Note. Once user agents support style sheet positioning, tables should not be used for layout

WCAG 1.0

Note that unfortunately the note, while part of the actual normative checkpoint (i.e. this is necessary to comply with the checkpoint) did unfortunately not make it through to the Checklist of Checkpoints which is frequently used for reference, and so many people will miss this.

I’ll just step back to clarify: the user agents clause states that:

Checkpoints that contain the phrase “until user agents …” require content developers to provide additional support for accessibility until most user agents readily available to their audience include the necessary accessibility features.WCAG 1.0 Glossary

As we’re clearly at a situation now where most user agents readily available to the audience do support style sheet positioning, this plainly means that tables should not be used for layout.

So if you need a .NET page which is accessible to conformance level Double-A (as is mandated for a lot of public sector organisations in the UK), not only do you need to make sure that your .NET application works without javascript enabled, you also need to make sure it doesn’t use tables for layout.

Unfortunately, a lot of the controls I’ve mentioned for you before put in layout table markup in your applications whether you want them to or not.

Fortunately, there is a solution — someone has developed CSS Friendly ASP. NET 2.0 Control Adapters which are currently in their second Beta version. These can be plugged into your .NET site to tell your .NET framework to render these controls in a different way to the default — e.g. by using proper semantic code such as lists and controlling the styling by using css.

Unfortunately, while it’s not horrendously complicated, it’s not straight-forward either, and this is where I do hold Microsoft culpable — the technologies already existed to render these controls in a standards-compliant and accessible manner, so why didn’t they?

What I would ask Microsoft to do here would be to provide an update for the .NET framework that meant that the controls were rendered using CSS-compliant methods by default for a particular server (or at least by some sort of toggle setting on the webserver), that way developers who want to produce standards compliant code can do so without having to undo unwanted table markup being shoe-horned in in the first place by the .NET framework.

Summary

Microsoft .NET and Microsoft Visual Studio are fantastic products and tools for developing applications, but they aren’t without their faults and limitations. The faults being that they don’t produce standards-compliant css-styled code, and the limitations being that to add behaviour outside standard HTML behaviour, they need to use javascript, both of which can potentially cause problems for someone trying to develop an accessible website, particularly if they aren’t aware of them.

For users that are aware of them, you can use the control adapters for now and avoid anything that uses the javascript postbacks if you require your site to be accessible. Or if you don’t think you require your site to be accessible, you can just do it any old how and hope it doesn’t come back to haunt you.