Making websites accessible is very inaccessible

One of the issues a software engineer who develops HTTP interfaces (i.e. websites) as part of their code has to consider is ‘accessibility’. This catch-all term covers many things but essentially means that a website must be implemented in such a way that no-one is excluded from using it. It’s often thought of as purely a website graphical design consideration but it is absolutely something that a coder has to consider.

This is an aim that is entirely laudable, and with the UK government’s recent legislation (and the legal interpretation of websites as part of that legislation) on the issue, is something that web-based software development project planning must take into account at an early stage.

There are globally recognised standards for this, but the problem comes when an organisation realises that it has to take this seriously, as more often than not it has not been addressed at all in any previous IT-related resource management and planning. What then often seems to happen is that a software engineer is handed down an edict from on high to the effect that they must re-design current websites or incorporate these standards into new website development. Essentially, it is left to to the software engineer to interpret these standards into real life code. And this is where things get murky.

Some rules are not a really a problem, and all software engineers should endeavour to follow them, such as ensuring that all HTML image tags have textual alternatives, and ensuring that the use of layout facilities (e.g. CSS, HTML forms and tables) is such that a user can change font sizes, colours and the format of the webpage in their browser to suit their needs.

Other things are less clear. One of the biggest problems, in my experience, is the use of JavaScript. Although the use of JavaScript is not explicitly ‘banned’ in the W3C guidelines (they merely mention that an entirely equivalent textual alternative must always be available), it is routinely used (along with Flash) as the archetypal example of ‘bad practice’ in this context.

JavaScript is such an essential component of building the dynamic and interactive nature of the websites required by the projects I work on, that there really is no alternative. Many of the website interfaces I build are entirely graphical in nature as well, with no way of representing them textually – see my previous posting ‘Why I love Google Maps‘. So whats the answer? I don’t know, and neither does anybody else, it seems.

Another thing that is manifestly not done, in my experience, is getting feedback from the user communities that are affected by this issue and may be potential stakeholders in a web-based project, and finding out what their real experiences and requirements are. Reacting to scare stories in the news and watercooler chat is no way to drive the goals of an organisation; talking to the people who have to use the applications and products that are being developed is.

What tends to happens in practice is that the best way an interested organisation approaches this problem is to come up with a list of guidelines that are tailored to its particular circumstances, and which (it hopes!) will address the issue and stop them getting sued – see the BBC guidelines and the RNIB for examples. All of this is routinely flouted of course, even by large companies and the UK government itself.

It’s worth noting also that the concept of ‘accessibility’ is larger than this – although the legal aspects and guidelines that are most discussed talk about disability specifically, it also covers things like ensuring a website is usable in different types of browsers or operating systems and not requiring the end user to suffer financial penalties such as having to buy commercial software (such as Microsoft Word) or having to have a top-end PC and a fast broadband network connection in order to view the content of the website. There are also security-related considerations such as catering for users who do not wish their browser to support the use of cookies.