From experience of past projects Web Accessibility is often considered to late in the development process.  In most cases the client or owner usually signs off the project on the visual design.  They are excited to see their idea becoming a reality and never consider the unpinning technologies used.

Its not uncommon for projects to land on our desk after the build is delivered.  We will conduct the accessibility audit and work directly with the developers to ensure all issues we identify are addressed.  However, this is the time when changes cost more.

Accessibility should be considered as early as the design stage.  Discussions should take place regarding layout and navigation and flow of an application before the build stages. Its a lot easier to over come issues while the project is still on paper.

From a developers stand point, they should be instructed on how to build, and what technologies to use instead of delivering an application that relies heavily on javascript.

The more effort made to put emphasis on accessibility equals the better chances of getting it right first time.  Even if that means you are the only person in the room who asks the question.

Build accessibility into your project, don’t try ad bolt it on.

In a recent post about a Peters Pink Boat I came across a Web site which has to be the most inaccessible Web site I have ever seen.

“Bloom in the Park is the largest and most spectacular gardening event in Ireland, hosted by Bord Bia. Its a competition of sorts where gardeners can get creative as they like.”

The Bloom in the Park Web site should get a Golden Razzie. The site is one big image thats probably been run through a Dreamweaver chopping shop. Everything is an image right down to the text.

The competition is all about “getting creative” and obviously the organisers like things that look nice. (Note to organisers not everyone who uses the Web can see.)

I’ve seen a lot of bad sites and most could be put down to lack of knowledge and experience. In such cases the developers usually demonstrate that they did their home work and with a little research they did their best to make their Web site as accessible as they new best.

Chances are the developer marked up headings incorrectly, hard coded a few spacer gifs and forgot to provide alt text for images, but they gave it their best shot. With a little encouragement these developers can only get better and they do.

Part of the problem with accessibility is understanding, some people just cant think outside the box while others are not paid to think outside of the box. I’d love to know what their excuse is. It was the same last year.

This Web site clearly demonstrates the wool being pulled over the clients eyes, but is that good enough excuse, surely in this day and age they could manage to pull of a Single A compliant Web site?

Do you have a Web site which is compliant with the W3C’s Web Content Accessiblity Guidelines? If so, you may be interested to see if your site is going to require any additional work in order to make it mobile friendly or, as the W3C calls it Mobile OK.

The W3C has just published a first public working draft of a Relationship between Mobile Web Best Practices 1.0 and Web Content Accessibility Guidelines document. This document aims to bridge the gap between WCAG and the Mobile Web Best Practices by providing direct mappings between the guidelines. If you know what WCAG checkpoints your site conforms to, then this document will tell you what additional steps you need to take to also make it Mobile OK.

It’s a very useful document as it demonstrates just how little effort is actually required to make your website Mobile OK.

Yesterday afternoon the World Wide Web Consortium (W3C) released the first public working draft of the HTML 5.0 specification. The official press release can be found here. Its taken 11 months since work began on HTML 5.0 for this first public working draft to get released. A pretty impressive effort in my opinion, having first hand experience at just how slow some W3C groups are run.

The main goal of HTML 5.0 is to make it easier for developers to create dynamic content and it introduces a load of new elements to enable this.

A final release of HTML 5.0 is still a long way off but this working draft provides an insight into where HTML is heading and the future is looking bright.