The New Zealand Government Web Guidelines were created in August 2001 as a way to ensure that government websites provided equal access to all NZ citizens. One in five New Zealanders have some kind of disability and the government has a responsibility to ensure that they are not discriminated against. The 69-page Guidelines document is a good piece of leadership from the NZ government, building on similar efforts overseas.

We have audited over 130 government websites against the Guidelines in the last 18 months, so now seems like a good time to share some of our observations about the guidelines. In our opinion the following changes to the guidelines would be very helpful for agencies trying to comply:

1. Checkpoints should be uniquely numbered and provided in a checklist form. The Guidelines themselves are not very usable. There is no easy-to-use checklist included as part of the document. In fact, if you were to go through the document and try and create a checklist (as we’ve done) you’ll see that some checkpoints are repeated three times! The checkpoints aren’t uniquely numbered either, so it can be a tongue twister to describe exactly which checkpoint you’re referring to: “It’s checkpoint 5.4.1, the second bullet point in the second paragraph after the heading on page 25”.

2. Checkpoints should have a similar scope. There are checkpoints that a site will pass by including a single email address on just one page. Other checkpoints literally roll up 30 criteria into one, such as “you should satisfy WAI priority 2 checkpoints”.

3. Checkpoints should be less ambiguous. The Guidelines say no frames, so does that exclude IFRAME tags as well? Sites must be DOM compliant – sure, but to what level? Level-0 compliance means something a lot different to the current Level-1 standard.

4. Difficult to achieve checkpoints that offer little value should be culled. For example, writing HTML tags in the same order on every page requires a huge amount of discipline. Only the very smallest sites will pass this checkpoint, so why include it?

5. All checkpoints should be testable. It is well known in software engineering that requirements of software systems must be testable. If you are expected to comply with something, then you must be able to tell when you’ve succeeded and when you haven’t. How can you tell if your site is ECMAScript compliant for example? Some of the checkpoints also introduce an element of subjectivity. Different auditors might interpret “it is clear who to contact about a part of the site” in different ways.

6. Guidance should be given to help determine what is meant by a pass and a fail. It is difficult to interpret the meanings of “should” and “must”. What actually constitutes a pass and fail? If you pass 100% of the musts? Or is it like school, and 50% is a pass? If one page on a site fails, does the entire site fail?

Probably the biggest criticism of the entire Guidelines compliance exercise is that it is still possible to create a very unusable site and comply 100% with the guidelines. Compliance needs to be in someway about abiding with the spirit of the Guidelines. As UK-based consulting firm Nomensa put it: “Making a web site technically accessible is just the first step. For your online solution to be successful it must also be both useful and usable.” Local expert Zef Fugaz also warns that “too many Government websites (there are exceptions) seem to be taking the blandness pill – playing it safe, not offending anyone, keeping it neutral.”

In most cases, it’s not technically difficult to create an accessible website. Unfortunately though, in the same way that it’s hard to create a curb cut-out after the curb has been built, it’s very difficult to achieve compliance once a site already exists. That’s the challenge ahead for the 500+ government websites that need to be compliant by the 1st of January 2006.