For many years now I have been involved in User Interface development and have always followed W3C guidelines to the last millimeter.

Reasons for this have been:

• To achieve cross-browser compatibility
• Make code easier to maintain
• Make sure my sites work well over long period of time
• Ensure that everyone can access my page without any problems

My aim in this article is to try and argue against engineering massive accessibility into your web solution and give reasons why this might be a very good idea.

Current beliefs about accessibility

Within web standards circles accessibility has become a subject matter which nobody seems to want to contend with.

It seems to be the overarching feeling and belief that ‘more accessibility we build into our solutions the better our solution will be’.

The above statement, however, is becoming less and less true as time passes and in some circumstances is almost totally irrelevant.

When accessibility matters

There are clear circumstances within which accessibility is incredibly relevant and should be implemented by all means possible.

Some of these circumstances may be:

• Government sites where legislation states that AA or AAA accessibility compliance must be achieved to give every citizen equal chance of accessing Government data  and/or service
• Company wants to achieve high search engine ranking and wants to make it really easy for search engine bots to find, index and crawl their web sites
• A company cares about their users, wanting to ensure a wide as possible accessibility in order to avoid customer complaints, negative feedback and generally increase their changes of higher profits by ensuring everyone can buy goods from their web site without problems

If you are working within an environment where the above circumstances are in place, ‘the accessible route’ should be followed without questioning.

If there is a good enough business case for accessibility, it should be implemented.

Accessibility is irrelevant

Today we are smarter about the approach through which we develop web presences.

User Experience Design (UXD) approach (if utilised) means that we identify the target market for which the given web site is relevant and cater our solution for that target market.

This is all in order not to waste company’s money and resources on implementing a solution which does not meet users’ requirements.

For example, if a high level of accessibility without JavaScript is not required (based on UXD research), it should not be implemented as target users are most likely to have fully featured browsers with good support for JavaScript.

There are many circumstances within which accessibility might not matter much at all and can therefore:

• Act as a potential development burden
• Increase time spent on coding a solution
• Create unnecessary overload on testers
• Complicate matters and
• Generally delay the time-to-market date without achieving any benefits whatsoever

Circumstances where accessibility may be highly or totally irrelevant when:

• Developing applications for an Intranet where target browser(s) support is very well known and the solution ‘resides’ within a controlled environment
• Developing for specific audience(s) with advanced browser support
• Search engine ranking does not matter as much (e.g. FaceBook or Google)

Accessibility matters after all

An important additional aspect of accessibility today (compared to some 10 years ago) is the incredible proliferation of various mobile devices, which might be the future way in which we access the web.

We may well find ourselves in a circumstance today where a given application needs to be accessible for ‘typical’ desktop user (e.g. using FireFox or Internet Explorer 8), but also needs to be accessed via BlackBerry Bold 9000 mobile device.

In this scenario we are better off implementing a solid W3C compliant solution for desktop users and another, parallel solution specifically targeted at BlackBerry Bold 9000.

This way both our target user groups will have very nice experience through their devices, while overall accessibility (according to WCAG1.0) might be very low in both implementations.

This approach hopefully helps clarify the overarching thinking behind WCAG2.0 guidelines which do see JavaScript as a ‘legitimate’ web technology which is part and parcel of many users’ browsers.