Accessibility refers to how accessible the apps and websites that we design are to disabled users.
Approximately 19% of the world is disabled in some way or another, making it fair to say that bottom lines are somewhat affected by neglected accessibility.
While blindness is what hinders most user’s ability to engage with interfaces, designers also need to consider those who have difficulty reading, interacting, understanding, and hearing.
Luckily, the WCAG 2.0 – Web Content Accessibility Guidelines and its sequel, WCAG 2.1, offers rules and tips for improving accessibility.
Also, there’s the ever-useful A11y Project, which also includes tests.
However, does catering for disabled users affect non-disabled users? Does it ruin their experience? Absolutely not. Accessibility improvements won’t diminish the experience of non-disabled users in any way. In fact, they too will have a much better experience.
Which is ideal, right? We don’t want to be designing two versions of everything.
Providing all users with the same experience is called inclusive design, and inclusivity not only benefits all users, but it’s morally corrupt to neglect any subset of users. In fact, denying access to disabled users is subject to human rights and discrimination laws worldwide.
The WCAG 2.0 requires that layouts fluidly adapt to all screen sizes upwards from 320px, and remain fluid even when the viewport is zoomed to 200% — this is to ensure that text elements aren’t overflowing beyond the viewport accidentally.
Difficulty reading is one of those scenarios that designers often have trouble empathising with. Some of us simply don’t read well, but luckily, those that do, nonetheless find it easier to interpret simple language anyway; hence, choosing uncomplicated words over complex ones is a really easy way to design inclusively.
However, complex words like terminology are often unavoidable. Thankfully, when terminology arises, all we need to do is explain the terms; and for abbreviations, either define them the first time they’re used, or otherwise link to an external definition. For documents that are overall complex, it’s best to link to a version that’s more readable.
People with motor disabilities such as cerebral palsy, muscular dystrophy, multiple sclerosis, Parkinson’s disease, Lou Gehrig’s disease, essential tremors, arthritis, and of course old-age, can experience extreme fatigue, decreased muscle movement, or involuntary movement, resulting in difficulty using a keyboard, mouse, or touchscreen.
Accessibility for those with motor disabilities largely revolves around designing interfaces that aren’t tricky to physically interact with. As a mobile user yourself, I’m sure you’re already aware that anything beyond simple taps and scrolls is unnecessary anyway, and anything that moves too quickly, or is too small, isn’t worth the effort.
Sometimes, apps and websites can be so difficult to use they’re literally headache-inducing. When this happens — when an interface is too confusing, or moves too quickly, or forces the user to think too hard — this frustration is multiplied for those with cognitive disabilities, where cognitive thinking requires more effort and energy.
Interfaces rarely use sound. However, if using sound adds to the experience, don’t neglect to include a clear visual indicator of what the sound means.
Disabilities are very common, but also, the advantages of meeting accessibility standards without us having to design specialised or segregated experiences for disabled users, also apply to those that aren’t disabled. It‘s a win-win for everybody.
When we invest in accessibility, by default we also invest in usability.