Recognising Accessibility Issues

Apps, websites and other softwares should be available to everyone regardless of their abilities; a system should work equally well for a sighted person using a standard mouse and screen, as it should for a blind person using a Braille output or screen reader.

There are other issues too; audio cues won’t work for deaf people, features that rely on a mouse won’t work for users who can’t use a mouse etc.

‘Accessibility’ is the ability for ALL users to make use of your system regardless of any impairment to ability.

There are 3 main areas of impairment that we, as designers and developers, need to be prepared for:

  • Sensorial Impairments that make things difficult or impossible to see or hear.
  • Motor Impairments that prevent the use of a mouse, keyboard, or other hardware.
  • Cognitive Impairments that make things confusing and difficult to understand.

Identifying the problem

Perhaps the most common impairment that comes to mind is visual. This is probably because we currently think of computing as a primarily visual medium like a newspaper or a book. When you start to look for problems that visually impaired users might encounter, it doesn’t take long to start finding them: poor colour contrast, links that just say “Click here”, purely visual interface elements, etc.

Problems for users with non-visual impairments aren’t so easy to spot.

Users with motor problems may have difficulty navigating an interface that only works with a mouse. Conversely they may have difficulty operating a keyboard-only interface so we need to be prepared for both eventualities.

Problems for users with cognitive impairments are even harder to spot. These tend to be based around the use of language and visual cues and affect how a user understands the interface they’re working with.

Finding the needs

Cognitive Issues

Users with cognitive problems can be easily confused or disoriented.

Cognitive issues need to be tackled first as they can form part of the system design at all levels. Solving these will also help later on with other issues.

There is an excellent book by Steve Krug whose title neatly sums up finding trip hazards for users with cognitive impairments: “Don’t make me think” – If a process or sequence requires careful (or, indeed, ANY) thought then it’s likely to cause problems.

Users with cognitive problems will be disoriented if links and buttons don’t behave in the way they expect. There’s a trend for large companies to send people on their websites clicking “Contact Us” to a page of frequently asked questions with a further link at the bottom labelled “Still can’t find your answer?”. This is incredibly confusing for users who are not looking for an FAQ page but find they have landed on one.

  • Do your users know what they’re getting into before they start?

Another issue that causes distress and disorientation is when a user with cognitive impairments clicks the “next” button on a page marked as “3” only to find themselves directed to a page marked as “F”. It can also be confusing when a navigation or process sequences ends abruptly or if a sequence is long winded but there is no way of knowing how far you’ve reached and how much is left.

  • Are sequence steps are clearly, consistently and logically marked?

However, it is important to break down content into easily digestible chunks. This is true for both textual or pictoral content and UI controls – a complex interface (think about a commercial airliners cockpit controls) should be broken into discrete areas of grouped controls just the same way as a long piece of text should be broken into discrete paragraphs and sections so that each can be absorbed before moving on to the next.

  • Are large blocks of information or complex content broken down into smaller, bite-sized pieces or ‘chunks’?

The key is to make your interface or content as easy to use as possible – with that in place some of the issues for users with other accessibility problems will start to fall in line too.

Motor Issues

Users with motor impairments may have trouble navigating with a mouse for a number of reasons – the most basic problems would be under-movement (they can’t move the mouse fast or far enough) or over-movement (they have shaky hands or problems constraining their movements.

This makes it a difficult task to simply ‘click here’, and what then happens if they do ‘click here’ and discover that ‘here’ is not where they wanted or expected to be? They then have to complete this tricky task again.

Here you can see that some of the same rules for discovering cognitive issues can be re-applied:

  • Do your users know what they’re getting into before they start?
  • Are sequence steps clearly, consistently and logically marked?

Some new laws also come into play here:

‘Fitts Law’ [https://en.wikipedia.org/wiki/Fitts%27s_law] states that the time taken to move to a target is a function of the distance to the target and that target size. Buttons need to be big enough that someone with an intention to click them should be able to do so without working to hard to find the target – a good rule of thumb is “would this button work on a touch interface?”

The same applies for any clickable element in your interface:

  • Can the users easily activate clickable elements?

Sensorial Issues

Visual impairments cover a whole range of issues from daltonism and deuteranopia (colour blindness) to profound vision loss and everything in between.

Users with profound vision loss tend to use external software to find their way around an interface but this can be problematic if the interface is not prepared for them.

Screen reader software is cumbersome and difficult to use at the best of times but users get around this with coping strategies. One such strategy is to skip through the links on a webpage to find the one you’re looking for. This can fail spectacularly if the developer, designer and writer have only included “Click Here” as their link text: A page full of “Click Here” links is useless to someone using a screen reader.

  • Are link texts and button labels meaningful?

They may also be using the descriptive text for images to navigate. A great example of bad desriptive text (in english at least) is “Orange”. Without being able to look at the image how can the user know if it means “a tasty, juicy orange”, “an example of the colour orange” or “the Orange company logo”. On top of that they don’t know the relevance of the image: it could be “oranges are a healthy snack”, “pests have affected the orange crop this year”, or “the amount of sugar in a glass of orange juice is the same as for the same amount of cola”.

  • Are all images described in a meaningful and contextual way?

Users with colourblindness will have trouble distinguishing the differences between certain colours so you need to make sure you’re not using colour as the only way of signalling information: a status signal that simply changes from green to red will not register any change for someone with Deuteranopia.

  • Is the system still usable if colour is removed?

Users with low vision have trouble distinguishing elements that don’t have strong contrast. Similar to trying to read a book in a darkened room, users with low vision need a stronger contrast to be able to make out words or interface elements.

A great tool for checking your interface meets the right standard for contrast is the Colour Contrast Analyzer (it’s also useful for checking your interface is usable for various types of colour blindness).

  • Is every element clearly visible and text clearly readable?

It should also be noted that relying on vision alone to signal change is likely to be missed by users with a whole range of problems in the cognitive and visual spectra.

Similarly, relying on solely non-visual stimulus such as sound or vibration could be missed by large groups of users.

Successful systems often make use of all three ways to alert the user to change in the form of a visual notification, an alert sound and a vibration whenever possible.

  • Can your users still get feedback despite any sensorial issues they may have?

Designing for everyone

Designing accessible interfaces can sometimes feel a bit restrictive but the truth is that interfaces designed to be accessible are usually the most usable in general terms too. When you stop to think about it, by working with accessibility in mind, you’re creating an interface that’s deliberately made clear, physically comfortable and easy to understand.

If you’re interested in finding out what it’s like to experience accessibility issues first hand, I built an accessibility issue simulation tool that you can try for yourself.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s