I’m somewhat of an accessibility evangelist; I am passionately in favour of ensuring that websites are available to all, irrespective of disability. I include in this people using different platforms and different browsers, because I tend to think it’s unprofessional to design a site which only works properly half the time.

Yet my development platform of choice is Microsoft’s .NET environment. Many people wrongly assume that using .NET means that you can’t produce standards-compliant accessible code.

They’d be wrong. It’s not necessarily as easy, and you have to make judgement calls from time to time. Here are some of the things I’ve done to try and make my .NET 2.0 applications more standards-compliant and accessible.

But .NET isn’t built for standards-compliance

Well, I don’t know how it’s built, but I do know that it is certainly possible to develop ASP.NET 2.0 sites using web standards. In fact there’s a whole great ruddy resource on precisely that topic on MSDN: Building ASP.NET 2.0 Sites Using Web Standards.

Give it a whirl. You might learn something. Bear in mind though, that the people behind it might not be right every time — for example they suggest that it makes things more accessible if every form field has an accesskey. It doesn’t. Nor does running your site through an automated checker (also suggested here) allow you to state with confidence whether or not your site is accessible.

So I wouldn’t recommend this as a key source of information for accessibility. I would however consider it to be a key source of information for .NET features that relate to accessible design. Just take their accessibility pronouncements with a pinch of salt…

But doesn’t .NET use tables for everything?

A number of .NET controls use tables by default, such as form views, grid views, tree views and the like. You’ve got a number of options here:

1. Don’t use those controls
2. Use those controls and accept that they are going to output tables
3. Use the CSS Friendly Control Adapters

The CSS Friendly control adapters take the code output by .NET and transform it, depending on browser, to more CSS-related output. I have to admit I haven’t looked into these a great deal: partly because I don’t want to server different output depending on how a browser is identified, partly because I don’t trust people’s browser identifications to be accurate, partly because I’ve never got round to it, and partly because my brief glance at the adapters seemed to indicate that they use javascript, and I try to minimise javascript use for reasons of accessibility support.

However, they might be suitable for you, or your environments, and are probably worth a look.

I personally don’t use them, however. I either create controls myself if I need to — for example creating my own paging control using buttons (so as not to be reliant on javascript), or I avoid them — preferring to build my own navigation menus than using TreeView — or I’m perfectly happy that they output tables, such as when I’m using the GridView control to output tabular data.

The ideal way forward would be for .NET to render controls using CSS by default…

[Edit: and it looks as though they might be doing precisely this in .NET 3.0, from what I've read although I've not been able to test this as yet]

…(or at least by some sort of application level switch) so that people wanting to produce standards compliant, css-friendly code can do so without having to jump through additional hoops.

For now though, you’ve got to jump through ‘em.

.NET form labels don’t work

If you’re using Master Pages (a nice template-type feature found in .NET), you’ll find that many of your controls get given prefixes like ctl00_CPH_Body_ which means that if you’ve started out with something like this:

<label for="Name">Name: </label>
<asp:TextBox ID="Name" runat="server"></asp:Textbox>

What will actually be rendered is something unexpected:

<label for="Name">Name: </label>
<input name="ctl00$CPH_Body$txtFirstName" type="text" id="ctl00_CPH_Body_txtFirstName" />

Which isn’t an accessible form control at all: the label is not actually associated with the correct control (indeed, it’s not actually associated with any control now).

But the solution is simple: instead of using a plain HTML label element, use an ASP label instead:

<asp:Label ID="lblName" runat="server" AssociatedControlId="Name"></asp:Label>

Would render as:

<label for="ctl00_CPH_Body_Name" id="ctl00_CPH_Body_lblName" class="label">First Name:</label>

Simple, eh?

And it’s even easier for ASP controls CheckBox, RadioButton, CheckboxList and RadioButton list, because (and thanks to BrettD for spotting this):

The ASP.NET CheckBox, RadioButton, CheckBoxList, and RadioButtonList controls automatically render tags. Be careful, when using these controls, to use the Text attribute to label the text of the controlBuilding ASP.NET 2.0 Sites Using Web Standards (2)

.NET isn’t XHTML-strict compliant

Yes it is. Or rather, it can be. The problem it has is that it doesn’t know that you want to use XHTML strict (defaulting to XHTML 1.0 Transitional). All you have to do is tell it, by including something in the web.config file:

<xhtmlConformance mode ="Strict"/>

Not too difficult, was it?

Errors Are Found In The Output Source Even When There Isn’t An Error

What, you mean like this?

<span id="ctl00_CPH_Body_valSurname" style="color:Red;visibility:hidden;">You must supply a surname for searching</span>

…or more commonly showing an asterisk, with the full error message being shown in a validation summary further down the page.

Yes, some of my earlier .NET 2.0 developments contain this sort of thing. Unless you view the source code (and unless you’re some sort of standards-obsessed anal retentive, you’re not likely to), you wouldn’t notice that in most circumstances.

You might however notice it if your browser doesn’t use CSS (or doesn’t take account of it properly), in which case you’ll find that all of your form controls with associated validation are reporting errors even when there aren’t any errors.

This is quite simple however, and is to do with client side validation. .NET allows the use of client side (javascript) validation, backed up by server side validation if the page cannot be validated with javascript (i.e. javascript doesn’t work, is turned off etc).

In order to do this, it places these error elements in the source code, but tells the browser to use CSS not to display them, and then in the event of an error actually being found, it manipulates the DOM again in order to display the errors.

That’s fine and dandy, assuming you’re using CSS, and you’ve not over-ridden it with your own preferences. However, if this isn’t the case, you report an error every time: including before anyone’s typed anything in, which obviously isn’t ideal.

Fortunately, there’s a simple way around it: simply insist that all validation is carried out server-side rather than client-side. This might mean a slightly increased load on your server, and it might mean it takes ever-so-slightly longer to validate the page, but that’s the compromise you have to make.

And it’s very simple to carry out the change. All you need to do is add EnableClientScript="False" into your .NET validation control, like so:

<asp:RequiredFieldValidator ID="valSurname" runat="server" ControlToValidate="surname" ErrorMessage="You must supply a surname for searching" EnableClientScript="False" cssClass="error">*</asp:RequiredFieldValidator>

And hey presto, nothing in the output HTML source unless there actually is an error.

.NET And The JavaScript Bugbear

A lot of .NET controls use javascript. This isn’t because Microsoft are an evil corporate machine dedicated to the destruction of accessibility and standards-compliance (although you’d never know that, listening to some people), it’s because Microsoft have added additional functions that aren’t supported by HTML and therefore need to use javascript to add these additional features because they simply aren’t there in HTML.

I’ve already described this in more detail, and indeed produced a testcase for javascript postback compatibility to test for precisely this thing.

Basically, as far as .NET and accessibility goes, you cannot comply with WCAG 1.0 if you require javascript postbacks. It’s as simple as that: WCAG 1.0 requires that the site functions without scripting being enabled.

However, if the particular scripting — in this case the javascript postback — is compatible with accessible technologies then it will be possible to comply with WCAG 2.0.

If you’re required to comply with WCAG 1.0, you can’t use javascript postbacks. End of story. Everything on your site will need to be driven by buttons or hyperlinks, and it’s certainly possible to do things that way, you just have to go to a little more trouble (for example, when I created my own button-based paging controls).

If you’re not required to comply with WCAG 1.0, you therefore have a decision to make. If you use only javascript which has been tested to work with accessible technologies (and that’s the reason why I produced the testcase ), then you can use that piece of javascript and you won’t be preventing users with disabilities from accessing your site.

That’s why I tested the javascript postback, and I’m confident that this can be used without discriminating against disabled users; it appears to be widely supported by assistive technology. I wouldn’t however just take my word for it: if you feel you need to, test it yourself, or set up your own test case!

However, your site (or at least those parts of it which required javascript) would be unusable for anyone who couldn’t support javascript, or have it switched off.

That’s your call.

Personally, I’d minimise the use of javascript, and only rely on it if necessary, because I’d rather have a site that will run even with scripting switched off. But if I have to use it, I will.

That’s my call: but then again no-one is insisting ThePickards comply with WCAG 1.0…!