Motor disability

Motor impairments are one of the two most important disability categories to focus on when designing products and public spaces (the other one being vision impairments). Simply because motor disabled users - just as blind users - may be completely unable to access poorly designed products or services while other disability groups would probably just have a worse than average user experience.

When asked to give examples of motor disabilities, people usually just mention wheelchair users and go on to assume that the only accessibility they need concerns public facilities such as ramps, elevators and wide-doored bathrooms. They couldn't be more wrong!

Indeed, wheelchair users are probably the most visible fraction, but motor disability isn't all about wheelchairs. The formal definition of motor impairment points to loss of function of a body part - not only total paralysis but also things like decreased stamina or muscle control. This means your motor disabled user group also consists of walking cane users, those with reduced fine motor skills and various types of amputees, All this adds up to a vast and diverse group. A lack of fine motor skills for example may impair precise pointing, wrist twisting or finger bending, maintaining a fixed hand position...

And then there are elderly people who often suffer from several different motor impairments at the same time. This makes using computers, smartphones and high tech household appliances all the more confusing.

The most common issues faced by motor impaired users include operating small or unergonomic hardware elements, reaching distant interface elements, operating touchscreens and performing 2D or spatial gestures.

More details to come in the next post on accessibility for motor disabilities!

Accessibility vs UX

Accessibility, usability and user experience are tree terms often perceived as a single step in the whole product development process (and to be performed by a single "general purpose" designer). Which often ends in disappointment when our UX designer approved software turns out to have accessibility issues - and beware, these are often neither easy nor cheap to fix once the product is out on the market.

Formal definitions aside, accessibility means a product is available to everyone regardless of the way they operate their device.

Usability guarantees the product is easy to use, intuitive and easily learnable.

User experience on the other hand tries to make a product attractive and fun - turning it into an experience rather than just another mundane tool.

I've tried and failed to order these terms into a nice, logical pyramid-like structure to visualize the importance and hierarchy between them. Besides, half of the UX designers out there would have probably disagreed on the hierarchy anyway ;).

For maximizing a product's audience, the most sensible approach would be to first make sure the product is accessible to all, then work on it's usability to support the actual functionality we're trying to sell and finally package the whole thing in a compelling user experience design.

Ironically, even though from my perspective product accessibility is a "must" and great user experience would only count as a "nice-to-have", the most basic design decisions such as who an app is for and what it should actually do are questions of unmet needs which should be answered by a UX researcher before anybody even does a line of coding or design work.

Of course, you can decide to ditch accessibility and make a pretty, shiny and totally inaccessible product which will give your young, lean and always energetic audience thrills along their spines and never mind those aging grannies that you're probably discouraging from ever even looking at your new invention, why not? It's a free market.

But keep in mind that accessibility often turns out to have much in common with ergonomics and will also make it easier for your regular audience to effectively use the product.

Top 10 accessibility fails

Choosing just ten major accessibility fails wasn't an easy task, but here's my personal list of bad accessibility and usability practices.

Inadequate color contrast

To many, color contrast is more of a question of aesthetics than usability. Quite the contrary! The color theme you choose for your product can severely influence its accessibility.

Adequate color contrast doesn't mean you need to resort to boring black and white. There are lots of color combinations with a reasonably high contrast rate. But be aware that the extremely popular white & light blue color theme is not one of them.

Poor information architecture

Information architecture is one of those things you never appreciate until it's broken. And you can be sure that once you break it, lots of people will notice and feel entitled to share their discovery with others.

The truth is: your user should never have to think too much while using your product. Finding things should always be obvious and intuitive.

A pretty graphics theme won't help a messy information model. You want your menus to be logically structured and appropriate to the use cases you expect your audience to engage in. You want your links to point to the things the user needs in a given context. And most of all, you want to minimize information clutter and make sure everything your user sees is there for a purpose.

Small action items

Tiny paddingless buttons tightly huddled together, checkboxes you have to explicitly click within that little white square to select, three-letter inline link texts... one thing they all have in common is how inviting they are to error.
  
Reading small text is one thing but misclicks or not being able to perform an action altogether are a totally different story!

Providing large clickable items and enough space between them is crucial to low-vision and motor disability accessibility. It also helps elderly people and all those who lack fine motor skills.

Partial or no keyboard access

Most people never even think of using a computer without a mouse. But believe it or not, quite a few people actually do use the keyboard for more than just typing text. Blind, low-vision and motor disabled users may all resort to keyboard access in order to compensate their disability and move around faster.

Nowadays, keyboard access is quite simple to provide - all you really need to do is adhere to good programming principles like setting up headings or adding basic keyboard shortcuts etc.

Text as images

The only good cases for using images of text are logos and artwork. In all other cases text should be entered as text (e.g. as a label) and preferably also be selectable and copyable.

If for some reason you really, really need your text to be an image - be sure to add an alternative text to it.

Overcomplicated language

Why is the polite "Please enter your e-mail address" inferior to a crude "Enter e-mail" command? Well, being polite is great but when it comes to user interfaces you want your labels and descriptions to be as short, clear an concise as possible. Why?

For one thing: you don't wan't your user to waste time on reading more than is absolutely necessary to perform the task they're aiming to finish.

Secondly, your audience may also contain intellectually disabled users who find it difficult to understand or concentrate on complex expressions.

And last but not least - remember that a low vision user may enlarge the text of your website or application which often results in the software's labels not fitting in their corresponding text areas.

Handling input errors

Input errors don't just happen do disabled people. But when they do, it can take quite a while to figure out what exactly has gone wrong and how to correct the erroneous input.

An input error message should always let the user know which field triggered the exception and provide instructions for supplying a valid input (e.g. the desired date format, password size requirements).

Incorrect text alternatives

Text alternatives are descriptions of non-text elements to be displayed to people using text-only viewing interfaces like screen readers or text browsers. Their sole purpose is to provide useful information. Why then add a "pretty smiling lady" alt text to an add or "green floral decoration" to a banner?

Actually, there's a good practice solution for just such a case. All uninformative or purely decorative content should be given an empty string as their alt text. All other content should be tagged with a concise description.

Hover menus

Hover menus are not inherently evil but they do tend to be a real pain in the ass for many elderly, motor disabled or low-vision users. E.g. a hover many may work fine at the standard browser magnification level, but could go all over the place once you set magnification do 300%. Moreover, they're unbelievably irritating if you're not too good at moving the mouse precisely: the menu will hide and reappear each time you accidentally swipe too far.

Hover menus were meant to save space. But at the same time they're barely usable when their items start sprouting submenus. And besides, having this enormous menu you can't fit on your webpage... are you absolutely sure you've got your information architecture right?

Blinking content

There's a good change you've heard about photosensitive epilepsy and know that blinking light's may trigger an epileptic seizure. But on the other hand, flashing, moving or blinking content is so widespread on the web it seems a must-have.

The truth is there aren't all that many photosensitive epileptics. And even among them, not every one will automatically have a seizure from looking at an animation. But flashing content may also cause discomfort or eye strain to many able-bodied users so it's good practice suggests you minimize flashing and blinking whenever possible.

Setting accessibility priorities

Although disability comes in all shapes and sizes, when it comes to using technology, some impairments are more hindering than others. Consider a partially deaf user and one with severe visual impairment. When given a device with no accessibility features whatsoever, the deaf user will probably be able to use it out of the box while the visually impaired one may get stuck as early as the device's login screen unable to enter the password or PIN code. Similarly, a paralyzed user may not even be capable of holding the device or entering text using its keyboard. On the other hand, an epileptic or someone suffering from ADHD won't experience the same difficulties at such a basic level of device operation.

That's why, when it comes to usability and accessibility, some users' needs are more of a priority than others'.

Typically, the first thing that comes to mind when you think about accessibility features (or at least the first thing I hear from the attendees of my accessibility trainings) is large fonts. Some also mention magnifiers and screen readers (not necessarily actually calling them "screen readers" - rather "talking computers" or something of the sort :) ).

And indeed, designing accessibility features to boost software and hardware usability for visually impaired users is on the top of every manufacturer's priority list (assuming they are already at the point of caring about accessibility in the first place). Why?

Often, the answer goes something like "because everybody else has it", which isn't a very good answer, but does illustrate the point that accessibility for blind and low-vision users must be important since it's so widespread.

Actually, the reason it's so important is because visually impaired users (especially blind and very low vision users) could be completely cut off from your product or content unless you provide some accessibility enhancements. Other special needs groups will probably be able to use an inaccessible product to some extent - though they will probably experience lowered usability and user experience compared to non-disabled users.

A similar problem arises for those suffering from various motor impairments - especially when it comes to small physical devices like smartphones or smartwatches.

That's why accessibility usually starts with magnifiers and big button interfaces. Which isn't to say that other disability groups don't deserve their own accessibility features!

Accessibility's invisible target group

So, who are we working on all this accessibility stuff for? Business and marketing specialists will obviously want to have a clearly defined target group so they can assess whether a project is worth working on to begin with. Vaguely saying that "it's for disabled people" doesn't really mean much to anybody. Most of us have absolutely no idea how many disabled there actually are. We tend to see them as some tiny little minority which makes going to all the trouble of learning about accessibility and redesigning all our products seem rather counterproductive. Besides, why would a blind person want a TV since they can't watch it anyway?

Well, let me clear up a few misconceptions.

To start with, the World Health Organization estimates that around 15% of the global population has some form of disability. That's over a billion people worldwide. You wouldn't exactly call that a tiny minority, would you?

For most people this single figure is quite shocking. I tend to start my accessibility training sessions by asking whether anybody knows a person with a disability and then ask for a rough estimate of the percentage of disabled people in the population. The answers vary from "I have absolutely no idea" to about 5%. Surprise!

So, where are all these disabled people hiding? 15% is about 1 in 7 people. But it's not like every time you get on the bus and look around you see a couple of disabled passengers beside you. Ever wondered why?

The answer is simpler than you may think. We tend to envisage people with disabilities as either permanently blind, wheelchair bound or with some terrible physical deformation and don't really think of someone to be disabled until we see them with a white cane or in a wheelchair. But the truth is most handicapped people have less extreme forms of their disabilities. For example, there's a whole range of visual impairments between normal 20/20 vision and blindness. The same goes for other disability types. Sometimes you may not even be aware of someone's disability until they tell you about it.

Disability comes in all shapes and sizes - from partial color-blindness to full body paralysis. Basically, you're considered disabled if you have an impairment (i.e. a bodily dysfunction) or activity limitation (difficulty performing a basic task). You can have a look at the various legislative definitions of disability at the European Disability Forum's website or see the WHO's website for more details on its definition of disability. The bottom line is: we don't really have a single, widely accepted definition but pretty much everyone out there agrees that disability should be thought of as an impairment of an individual's social functioning rather than a purely medical issue.

Of course, not all disabled people are officially recognized as such by their national governments or health care systems. However, for the purpose of working on accessibility, we should concentrate on users' actual abilities (or disabilities) rather than their formal disability status. Especially since disability assessment procedures vary between countries - which further blurs the few available statistics in this field...

An inclusive mindset

If you've ever heard of accessibility, you've probably been told that it's supposed to make websites and software accessible to disabled users. That it's like a set of UX rules and optimizations which let your product's visually impaired audience enlarge the text and maybe even listen to some information spoken aloud instead of having to read it on screen. Of course, you probably realize that blind and visually impaired users are not the only disabled users out there but somehow they tend to be the group we focus on most when it comes to accessibility.

At the end of the day, web designers put an obscure little "enlarge text" button at the top of their web pages and most software providers just add a bunch of basic voice output or magnification features and then boast of it in their press releases. In the mean time, the average user struggles to understand what the hell the accessibility label in the settings means and why make such a fuss over letting people change the fonts from 10 to 16 pt since it makes the whole thing look damn ugly.

The inclusive mindset I see accessibility to be is a completely different story.

Imagine you start designing your product with all its potential users in mind. Not just the young, white, geeky male target audience we automatically default to when it comes to software (or any other technology related product for that matter). Imagine the product is actually intuitive enough for your technophobic grandma to manage with little or no assistance and yet rich enough for a power user to want to use it. Imagine the product can be used just as efficiently by somebody with 20/20 vision, low vision or no vision whatsoever. Or by someone who only has one fully functional hand. Or by a child with an attention deficit disorder. Bare in mind you need totally different accessibility solutions to make your product usable for each of these target groups.

If you wanted to make an existing product accessible for all these audiences you'd probably have to spend loads of time and money on redesigning it and adding extra accessibility features. That's why pretty much nobody does it.

But if you start the whole production process with a notion of universal design, you'll be in a much better position to succeed at achieving accessibility for all. And will probably end up with a better user experience for your regular users too.

The concept of viewing accessibility as a mindset and not as a checklist isn't entirely new (see Access IQ's article on web accessibility as a mindset), but so far it hasn't yet been widely adopted. Obviously, it takes more time and knowledge, especially - though not only - in the initial planning and product design stages. Worst thing is, currently barely anyone in the market has enough experience in the accessibility field to jump straight into universal design. Most of us would first have to conduct costly user and requirements research on not-so-easy-to-obtain groups of users with various disabilities to get an understanding of what we're dealing with.

Moreover, the payoff doesn't seem all that clear either. Global estimates put the number of people with disabilities at around 15% of the population (see the UN Factsheet of Persons with Disabilities) but honestly, how many disabled people do you see on an average weekday? From an everyday perspective it can often seem they're barely there...

Well, the whole idea of an inclusive mindset is to be aware of the various forms of disability all around us, actually understand it instead of merely recognizing its symptoms and try to create products which can be operated pretty much by anyone. That's so much more than just following one of those magic accessibility checklists your project manager suddenly shows you in the final stage of post-production product testing, isn't it?

So what is this accessibility thing?

Once upon a time I met a friend who asked me about my (then) new programmer's job. Being a programmer himself and knowing that - in the corporate world - "I'm a programmer" can mean pretty much anything from programming micro-controllers to graphics design, he dared to inquire what it was I was actually doing. I said I was in the accessibility team and that we were working on an accessibility framework for a software platform. To this my friend responded by asking "So, what is this Accessibility thing? Is it a tool you use?". I was so dumbfounded by the question that I barely managed to think of any decent answer and finally just went with the old "Accessibility is about suiting software to the needs of people with disabilities". The friend then gave me a kind "Oh, I see." and left me feeling slightly perplexed for the rest of the evening.

Only after a few conversations of the sort did I realize that - to put it frankly - many if not most programmers have either never heard of accessibility or have only a vague idea of what lies beneath the name. This includes very good programmers. Even very good and very experienced programmers who I definitely admire just don't grasp the concept. Well, you can't have it all, I guess.

That was the first time I thought it might be worth spending a little time now and then to write a blog on this mysterious thing called accessibility. Sure, you could just go on and read the W3C's Accessibility Guidelines, but all the recommendations out there aren't very accessible (sic!) to those who don't already know quite a bit about accessibility.

Actually, all the accessibility standards and legislation (there are quite a few, but that's a topic for a different time) give the impression that just making sure the fonts in your app are of a specific size will ensure your products usability for the disabled users you've never seen and suspect they don't even really exist. Setting accessibility targets like "reach 80% compliance with the X accessibility standard" and then eagerly crossing off items on a checklist (a common site in the corporate world) doesn't help much either, I'm afraid. Believe it or not, accessibility is more than setting up a few extra preferences for your UI.

So what is accessibility? Unsurprisingly, it's not all that easy to find a comprehensive definition. Legislators usually define the concept of "assistive technologies" and assume that accessibility is something to be achieved by using them. For the proper, formal and unexciting definitions see the glossary appendix to WCAG 2.0 or the definition paragraph of Section 508.

Personally, I prefer to think of accessibility as an inclusive mindset which should naturally emanate to product design. And I don't just mean software design. I mean software, hardware, services, everyday items, public spaces - you name it.

Surprised? Well, that's what this blog is going to be about: an insider's perspective on accessibility and disability, you've never seen before.

Stay tuned.