Accessibility for UX Designers I

Dec 13, 2012

First part of notes from an Accessibility workshop with Derek Featherstone.

Yesterday I had a marathon eight-hour accessibility workshop for UX Designers with Derek Featherstone of Simply Accessible.

My interest in accessibility and interest in this particular course, was just down to the fact that it is obvious - surely we should build websites that everybody can use, and not just those who we associate most closely with. All of my friends are able-bodied, being bespectacled is perhaps the only noticeable disability that some suffer. I have no idea if any of them suffer colour blindness, but nobody is deaf, or has motor or cognitive disabilities, or I should say, I don’t associate anybody in my circle with a disability that is noticeable.

Before the workshop we were asked to rate our current knowledge between 0-5 based on what we felt we knew about accessibility, I went with 1 (0 being none), I figured that I knew how to check for colour blindness, I felt I was fairly smart with my <alt> tags, I knew a little about ARIA, and I have already tried to steer away from phrases such as, click here or press any key on the keyboard, but I am also very aware that there is a lot more that I needed to know on this subject.

Notes from the workshop

Here are some notes and examples, I will try to put some context in when possible:

  • Example: a website had “News 12/12/12” at the top of the page, when you would open the menu you would see that it was a recent news area, the date next to it merely pointed to the current date. For people using screen readers, the implication would be that this was the news from December 12th 2012.

  • Tip: look at opposite ends of the spectrum when you consider a person, if you look at the average height of people as an example, you would see that most people fall between 5’5 and 5’11, that doesn’t mean that people under or above those heights don’t exist. People with disabilities that aren’t considered average are easily forgotten. To put it into a basic web context, consider the young and old, and their motor control. How we operate a mouse, and where we click on a screen does not mean that we should forget those who may have difficulties with operations we could consider simple.

  • Drag and drop is a complex action.

  • Tip: look at the tools that people with disabilities use, and don’t assume. Blind users may prefer to use a braille keyboard over JAWS screen reading software, or importantly, they may switch between the two depending on the task. It may need less concentration to use one device over the other.

Braille keyboard
Example of a braille keyboard
  • Tip: Braille keyboards are left to right (in left to right languages), and the indentations allow for 40 characters at a time. Consider these two <alt> tags, <img alt="This is a video showing the features of the website">, and now consider <img alt="Video: Features of the website">. For people using braille devices for example, then they will know that it is a video after five characters. Those users could then decide whether to skip the content at an earlier stage. Always put things into context though, if you were running a website whose entire purpose was to review toasters, then <img alt="Philips HD2566 review"> would make more sense than <img alt="Video: Review of Philips HD2566">

  • Tip: Omnidazzle is an app that is used primarily for screencasts, but it is also good to show focused areas of the screen. Being a low-vision user of a site does not mean that you use a screen reader, you could be using a magnifier. Alternatively blow up the size of your fonts, and see how easy it is to use your website. Something that could be technically fine for a screen reader, could be horrendous for a user who is using a magnifier.

  • Tip: For users who have auditory disabilities, then supply captions in multimedia, for even higher levels of accessibility then also give a link to a transcript of the video, this is beneficial for users with low-vision who may use a screen reader. A video may take 7 minutes to watch, however a screen reader could read a transcript in just a couple of minutes. Supplying a transcript not only helps accessibility, but it also helps SEO

  • Mobility and dexterity impairments may include prosthetic limbs, tremors, just using one hand, there could be a mix of hardware used. For someone with a tremor they may be able to move the pointer to a button to press, but struggle with actually pressing on that button.

  • Tip: forms are terrible, if you are filling in a form, and type one field incorrectly then you should go to that field in particular, and not wipe the form and get the user to fill it in again. This is already annoying for somebody without a disability, but, for example, if a user had cerebral palsy then they could be typing one character every 3 seconds. To retype an entire form because of one field would be really frustrating, likewise for users with cognitive impairment, this experience would not be a positive one.

  • The Nexus 7 has some smart functionality. If a user taps on a link, and other links are close by, then you will first see a magnified area. This means that if the tap was ambiguous, then it make it easier for the user to press the link that they want. This is especially useful for people with motor disabilities.

This post is already long so I will cut off here, I am on page 3 of 14, and expect to break certain elements down further. Before I finish though, I can say that despite rating my knowledge before the course as a 1, I now realise that it was more of a 0.1. After checking out a few websites I think 0.1 is probably the number that most designers/developers have. I now think I would raise my hand confidently at around the 0.6 mark, but that gap from 0.1 to 0.6 is huge. Next step is getting to one and beyond.