Estimated reading time: 10 minutes Only have a few minutes? Skip to the section on Extending accessibility…
I've spent over a decade creating websites for a living, and only recently have I worked on a project which included some research with disabled and deaf people, observing their online habits and chatting about their needs. This has changed everything. I'm no expert (yet), but I found it fascinating, and hopefully some of the insight I gained will be useful and interesting to you, too.
A few years ago, whilst at Clearleft, I designed the website for an assistive technology provider, but any actual observational research was out of scope for the project so even then my understanding of accessibility was only hearsay. I would suggest that this is fairly typical of most website designers' understanding of the subject, despite the fact that nearly a third of the population (in the UK) have some kind of accessibility requirements. Many of those people struggle on without knowing that things could be better, so imagine their delight if a website offered to make a transaction easier than they thought possible.
I knew, as no doubt you do, that people who had problems with their eyesight might use a screen reader so their computer reads a page aloud, or might want a high contrast version of the site (back then I hadn't considered other colour variations for people with dyslexia or colour blindness), or may want to enlarge the text on a site to make it more legible.
I was opposed to replicating the browser's text resize controls within the page, but I realised that people might expect those controls, so I included them as a link to instructions on how to use the browser's own functionality instead (teaching a man to fish rather than giving him a fish, so to speak). I stand by this as A Good Idea, although I've never seen it done that way on other sites.
Of course, I also understood the importance of alt-text on images, skip-to-content links before navigation, and using semantically meaningful HTML. This is all well documented good practice, but watching disabled people use the web has made me realise that whilst these things are very useful, "accessibility compliance" really covers only the bare minimum we should be doing to meet disabled people's needs. We are merely ticking the boxes rather than considering context. Rather than being user-centred.
So, earlier this year I created a prototype venue and event listing site specifically for use by people with access requirements. Listing sites are a dime a dozen, but pretty much all of them fall down when it comes to accessibility, especially in its broader sense. I worked with Lizzie Ostrom from A+E, the client was Alison Smith from Pesky People, and the site will be called Go Genie. The purpose of the prototype was to show where people's needs aren't currently catered for, to demonstrate our ideas to fill these gaps, and to secure funding for the site's development.
We spent a few days with people who have a variety of visual impairments, hearing problems, learning disabilities, and motor disabilities. As we'd only enlisted a couple of dozen people for this research these are personal anecdotes rather than hard-and-fast rules – everyone has different needs, which makes addressing them all a near impossible challenge. Nevertheless, there are some enlightening observations about how disabled folk use the web and – as importantly as web accessibility – the kind of information they're looking for online which would help them become more participatory in society. Here's a summary of some what we learnt.
Non-disabled people You may have noticed that I referred to "disabled and deaf people" back there. This is because people who are deaf or hard of hearing do not always consider themselves to be disabled, even though they might find accessible features helpful. Indeed, as we get older we naturally begin to have mild access needs without being "disabled" – I often use Readability to make article text larger, clearer, and uncluttered, but I don't consider myself to be visually impaired.
Browser text resize Just like non-power-users without access needs, disabled people don't necessarily know what their browser can already do to help them. Don't assume that they will know about the browser's text resize feature just because they are the ideal target audience for it. Why isn't there a campaign to educate people about this feature? This seems like an easier win than getting every website to implement its own text-resize controls.
OS built-in accessibility A number of people is our observation sessions chose to use the operating system's built-in accessibility features to customise the machine's behaviour to their own requirements. This is worth noting, because unlike in-page contrast options or browser text resizing there's no way that a website can know if someone is using these features, making it harder (impossible?) to gain accurate metrics of accessibility setup from your site logs. (I'm not a techie, so please correct me if I'm wrong here!)
Extreme zoom Registered blind people often have some degree of sight. We observed that some people will zoom in so far that only a few words at a time fit on the screen, then move their face to within an inch of the monitor to read the text one word at a time, moving the screen along each line with the mouse as they go. The process is long and arduous, and highlights the need for keeping text concise and line-lengths short.
Columns and physically grouped content This kind of extreme zooming can make it hard to find your way around even a single web page. To make this less of a burden, physically grouping similar elements on screen and arranging content in columns rather than in a staggered layout helps. I used to be of the opinion that an accessible website needn't compromise the design of the page (because you can make it accessible with code, right?), but now I realise that accessibility is just as much about visual design patterns and layout as it is about coding style, and also content. That doesn't mean an accessible page has to be ugly – chances are the more outlandish design would have also been unnecessarily complex in design, and therefore harder to use anyway.
Video content for people with learning disabilities In our research, people with some learning disabilities would arrive at a website from Google and just look at the screen, and if they couldn't see the information they were looking for then they'd assume it wasn't there. They wouldn't consider scrolling, or clicking on a link. Depending on the content, it would appear that providing a video version of the page would be a good solution to this because it would put all the information in one physical place on the screen (just revealed over time as the video plays). However, this brings about questions of cost, maintainability, and scalability.
If somebody tells you accessibility is free, quick and easy to implement then they're talking about the ticking-the-boxes kind, but video is one of the things that can be expensive and time consuming to source to a professional standard. The content of most importance to people with these access requirements should be given priority for video versions, bearing in mind that if the content changes then the video would need to change too. Don't do this kind of accessibility early in the development process if your content isn't yet finished, and ask the producers to keep the source files for future amendments. Also worth noting that videos need captions (or sign language) for people who are hard of hearing – often this can be switched on and off in the player, so it's not intrusive for people who don't need it.
Access symbols These icons are universally recognised and should be used whenever providing information for people with access needs. Note the last symbol – this isn't just about disabled users!
Extending accessibility to include online advice about offline situations One of the major things that struck me from this research is that disabled and deaf people often lack any confidence that real-world situations will be accessible to them, so they tend to stay home and not participate in society as much as they could. Given the power and opportunity that the web affords us, it's sad that this remains a problem – though possibly not surprising as I wouldn't have thought about it were it not for this research.
To give you an example, somebody in a wheelchair may never go to the cinema because they don't know how easy it is to get to, or what the access is like when they get there.
- Is there a train station nearby?
- Is the cinema near any rowdy bars which may have intimidating drunks outside after the show?
- Is there disabled parking? How far is it from the entrance?
- What's the terrain like from the parking to the entrance – Uphill? Downhill? Across roads?
- Are there dropped-kerbs? Are they good quality or do they dip below the road surface causing an unexpected bump?
- Can I sit with my friends in the cinema or is there a separate area for people in wheelchairs?
- Is that area raised, and if so will I block the view of anyone sitting behind, and be considered an inconvenience?
- Are there closed captions?
- Is there an induction loop for people with hearing aids? Is it always turned on? Do the staff know how to use it?
- Are the staff well trained in helping people with disabilities?
- Are there concessionary prices for disabled people? What makes someone eligible for those prices? (more than one person reported being humiliated when staff doubted the authenticity of their disability, because it wasn't visibly obvious)
The list of potential questions can get very long and it's a difficult balance between providing enough detail and providing an overwhelming amount. This information can be different for each type of venue, and at least it only has to be provided once, but unless you have infinite time and resources then a pragmatic approach to prioritising what's important for your site is clearly the way to go. From a disabled user's perspective, maybe a good solution is for them to tell a site what their access needs are so that the site can provide only the info relevant to them.
Putting this amount of thought into accessibility could really make the difference between someone having a great experience or never bothering at all. It's not about just giving them the ability to read a website, these are the kinds of extra steps that could could literally change someone's life for the better.
A footnote about Alpha.gov.uk The Go Genie prototype consisted of an imagemap-based walkthrough of a few mocked-up pages of the site (here's a video, starting with a clickable Go Genie widget on the Birmingham Hippodrome website), and some storyboards explaining some typical scenarios. The prototype itself was not available to the public, and wasn't accessible of course, because it's purpose was in part to secure the required funding to develop it with accessibility (and congrats to Alison, as Go Genie is now funded!).
In this regard there are interesting parallels to the recent Alpha.gov.uk prototype I worked on for the Cabinet Office. The purpose of the prototype was similar in many ways, but we took the extra step of making it available to most of the public. Despite the fact that we used semantically meaningful markup, skip-to-content links, alt-text on images, correctly labelled form elements, and added the caveat that we knew accessibility was one of the many things on the site that was unfinished in the incredibly short amount of time we'd had, we still received some very hostile criticism from some accessibility advocates for daring to release something (even a demo) that wasn't totally accessible.
That's a real shame – the team want to seek external advice on the matter, but it's also a natural human reaction to want to avoid aggression and seek constructive and helpful criticism instead. I'm sure that as ever it's only a vocal minority that are being unfriendly in their approach to the project, but it still leaves a bitter taste after all the efforts we had made. The points might be valid, but hostility doesn't win any friends.
Maybe I'll hook the team up with the disabled folk who helped out on the Go Genie prototype, who by contrast were delightful and very eager to have their voices heard and I'm sure would welcome the opportunity to have some input into the new Government site.
I'm interested in reading your (non-aggressive!) comments below, or via Twitter @paulannett.