Halting the drift into inaccessibility
Last month we had yet another accessibility audit of high profile sites that made depressing reading and I doubt very much whether the situation will change greatly this year. This would also include many of the UK public sector sites even though they’re supposed to conform to the WCAG Double-A standard. From experience I would say that even if this were the case at launch there seems to be a slow, inevitable slide into inaccessibility. So it set me wondering over the Christmas break how we might be able to stop the rot.
Starting as you mean to go on
A good starting point is the recent BSI guide – PAS 78: A guide to good practice in commissioning accessible websites – freely available from the Disability Rights Commission.
Usually the emphasis is those involved in production – the developers and the graphic designers. If you’re using external resources then you’ll be looking to see accessibility as part of the quality control process & some previous experience of working to these standards. With an internal team you’d also want to be proactive with training and exchanging useful resources so that issues are identified long before you’re into testing.
However there are some areas that are worth considering at the start to ensure that you don’t lead everyone astray:
- ensure that there’s time for accessibility checks on the final design choices – this is usually an area where everyone has a strong opinion and there’s pressure to start producing something, but you need to make sure that there aren’t problems with colour combinations or contrasts (and time to come up with a compromise if there are)
- if you’re planning to use JavaScript or Flash then make sure that thought is given at the start to an alternative for those who won’t be using these technologies (sometimes people think this means you can’t do whizzy things in JavaScript, that’s not the case you just need to make sure that there is another route to achieve the same goal)
- again with JavaScript make sure that it works with a keyboard or a mouse – all too often programmers focus on the latter, even though it doesn’t take much more effort to include both options
- including content in other formats (e.g. PDF files, video, audio, etc.) requires them to be accessible or alternatives provided – see the Rich Media Accessibility articles on WebAIM for more information on accessible PDFs and captioning videos, etc.
- remember to inform anybody providing third party add-ons that those also need to be accessible – it’s easy to forget them as you’re thinking about the service they’re offering rather than what you need to add to your site (we’ve had experience of this with web traffic analysis tools)
Checking it out
Unfortunately relying on automated testing isn’t going to tell you with your site is accessible or not. Many of the issues require an understanding of the content being displayed and therefore will be beyond the capabilities of the most sophisticated program (e.g. identifying headings and lists within text). So you’re going to have to rely on people making subjective decisions and spending time sifting through HTML code. If you’re not clear if something is a problem (& can’t find examples of best practice) at least be consistent in your decision.
Minor tweaks under pressure
Frequently the life of a website involves a whole raft of minor amendments with very tight deadlines attached to them. One day everything will be planned and orderly so that it can go through stringent quality control before being made live – honest guv! Until then how are we to keep on the straight and narrow?
I would suggest that the changes are logged and then made part of a regular website review that would include assessing the impact on accessibility. It will also allow you to run through other quality control processes and give an opportunity to clean up those quick & dirty fixes that are always made under pressure.
Creating content
It’s not just the techies that have to think about accessibility but everyone contributing content to your website. However their focus is going to be on writing text or creating images and not necessarily the mechanics of what happens when that’s displayed in a browser. So some ways of helping them could include:
- providing resources on making their content accessible that relates to the tools they’re using – on this blog we’ve some advice for people using rich text editors
- reducing the decisions that they need to make by looking at the different content types that you have and draw up guidelines on how they are to be created – this would mean that they can be checked by someone focused on accessibility issues but also help you to maintain site design conventions
- making sure that your web authoring tools make it easy for your content providers to style their text – e.g. if someone wants to highlight a paragraph with a bullet then they could mistakenly make it a list as that’s the only option they can see in their rich text editor and it produces the result they want
- making authors aware that they have to take responsibility if they try something not within your guidelines
commissioning websites, nptech, wcag, web-accessibility, website management