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.
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.