Building accessible sites - two sides to every coin
04/05/2016 - Web Development
Relevant, no longer rigorous
Web accessibility still centres around the WCAG2 guidelines (see Web Content Accessibility Guidelines (WCAG) 2.0 and WCAG 2.0 Quick Reference Guide). However, whilst the key points are still very relevant, they no longer stand up to rigorous and detailed analysis.
Two basic examples:
- Access keys - there are various arguments as to why these are not the best solution / approach. (More about access keys)
- Colours - The concept of 'web-safe' colours is now superseded by the all-important 'Contrast Ratio' between colours. We check against WCAG standards using various tools, such as this online contrast-ratio checker.
This is not surprising since the WCAG2 guidelines were released in 2008 and the fact is that the web has moved on since then. Since 2008, the RNIB standards have in effect superceded and built on to the WCAG2 guidelines, outlining the relevant key points whilst dismissing others. See 'Main differences with WCAG 2.0' on the RNIB website.
So what's a web dev supposed to do?
What we do
Looking at some key headers and how we respond to them on ALL our projects:
Semantic web, markup and class names
All of our page and HTML markup is fully semantic. This benefits both users and elsewhere (e.g. SEO). Throughout the course of a project we produce and test our code to be compliant - whether in the production of prototypes or when finally worked (or themed) into Drupal.
Images
All images (still) need alt tags. The majority of these will be added when images are uploaded via the CMS which makes it the responsibility of content managers/editors. We make sure all image uploads can add alt tag data and we can make that a requirement so you don't miss it. For top marks on accessibility it's worth spending time thinking about what you add here - it's better to write "Image of a dog" than "Image' for example.
JavaScript
No longer as relevant as it's rarely used inline, functions will have a fallback and is not fundamental to the user. We ensure this is now managed through the <noscript> tag.
Forms
We ensure that form submission doesn't require JavaScript in order to work.
Flash
According to WCAG and RNIB standards there must be HTML equivalents whenever Flash is used. The simple solution to this is simply not to use Flash elements and to ensure when using any 3rd party content providers that they use newer iFrame HTML5 technology etc (e.g. from YouTube, Vimeo, SoundCloud). Since Flash does not work on the vast majority of tablets and smartphones, HTML is a much preferred solution.
Subtitles or written transcripts on audio and video
This content tends to come from 3rd party platforms (e.g. YouTube) and is again editor driven.
Finally we make sure to give a content guide to every client (covering images sizes, typography and the like) and make sure they add an 'accessibility' page to their site - eg: ICA's accessibility page.
As part of his Arts Analytics blog, Chris Unitt assessed the accessibility of 100 websites in the arts sector a little while ago to see how everyone's doing - check whether he reviewed yours! Chris also gives some tips on how to check how you're doing.
Accessibility is a joint effort and everyone involved in a project holds some level of responsibility for making sure everything's done well. Designers, developers and content editors need to understand their part in the jigsaw in order to make a truly accessible site.
