Working in a Government IT development group you soon realise that compliance and accessibility sit far above design and aesthetics in the eyes of the Information Technology panels and committees that make the decisions on what government web sites all across the country will look like. I find one of the most challenging and enjoyable parts of my job as a lead developer is to deliver a happy medium where the interface does not suffer due to the tight regulations of compliance and accessibility, this often results in a simpler cleaner interface.

I have long ago learnt that not all websites will be compliant and accessible, I used to assume that it was because of lazy developers or bad management but after a long time in the IT industry you realise that there are many other factors involved in the life cycle of a web interface. Sometimes a client flat out refuses to pay the extra and is happy that only people using IE6 will be able to access their site or the big one.. time. I have been involved in projects that were designed, created and released in a 48 hour period, in these situations you are lucky if you have time to submit your code to the W3C Validator, let alone spend a few days optimising the code.

I will not bore you with specifics of the regulations and legal mandates that we have to follow but I will explain that they are not over the top and as a developer these are standards that I would try to follow in every day design. In reality, the government IT developers path creates developers that know how to follow guidelines and create nice friendly compliant interfaces (well that is the theory..)

The Compliance and Accessibility Testing  Life Cycle is a no brainer. It can also be a nightmare for the lazy developer and time consuming in fixing. This part of the project often shows the skill of the developer and his experience in the industry. A badly designed page/template might get up to 50 validation errors (or more) and still look fine in a browser, this could take days to clean and adjust all the code. A well designed page/template might take one day/afternoon to achieve full compliance and complete all testing, this is a sign of good developer.

HTML & CSS Validation

Firstly head over to the W3C CSS Validation test, if you know what you are doing with CSS then this is as simple as editing a few div tags cleaning up any errors that have reared their head. Secondly run your page through the HTML Validator, this will identify any real problems with your code and you can clean up any errors that will interfere with the rendering of your pages in different browsers/devices. It is important that you choose what level of validation you want achieve with your code and declare it at the top of your page. The standard doctype is HTML 4.01, HTML 4.01 specifies three document types: Strict, Transitional, and Frameset. A doctype is a declaration that works as a top level tag like reference known as a Public Identifier.

There is no correct declaration to use you just have to make sure you choose the right one for the project.

A big issue for the batch of current developers is the huge usage of Content Management Systems. If your Content Management System produces clean complaint code before the content pages are populated then you stand a much better chance of keeping it all compliant, I have seen a few CMS’s that do not comply to web standards so your pages will never reach a high level of validation, be aware.

Basic Compliance & Accessibility

There are many online tools available to get your page up to standard; they are mostly using the same base standards. After running your page through the validator you will see a report. It is not necessary to fix all the warnings but adjust your code to remove all the errors. The fact that you have tested each of these levels of compliance and accessibility will give you an excellent report on where your interface rates and if your client is happy with that standard reached. Not every client will care if the site can be viewed at 640×480 or that you didn’t reach XHTML strict 4.01, every client is different but they love to have the choice and good developers will always present multiple options.
I have my favourites for testing my pages, number one on my list is "Truwex Online 2.0 beta, Section 508 and WCAG Accessibility, Privacy, Quality validation Tool", it has a long name but provides an excellent report and is free. Truwex even displays an image of your page and can show you where your aerrors are taking place, this is very handy. WebXACT & Cynthia  are  also a great tools and  free.

User Testing with Real Users

I find user testing to be an eye opening part of the Life cycle, I will never cease to be amazed at the level of some users and their inability to find their way around a screen which only has three links. But, these are the kinds of people that your design needs to work for and changes to the User Interface are often nothing more than highlighting important links and making some fonts larger. These tests often identify things that developers and programmers don’t care about. You do not need do extensive testing in this area but often using 6 different people all with different levels of IT ability and skill will show any real problems real people will have using your pages. I find the best (most frustrating) test is to try to get one of your parents to use the interface, at least you can shout at them when they don’t see the 200% larger link in the middle of the page.

Why should I test my pages for compliance and accessibility? Well, for the first reason, you don’t want to get sued. It is becoming more common place in Western countries that there are legal requirements in place that state your pages must be viewable to

After a few projects done at a high level of compliance and validation you will begin to do the right things automatically and all your development will naturally be of a very high standard, which should leave you more free time near the end of the project to do important tasks like drink beer and play Halo.