What Is Accessibility?
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.
Consider this toilet, for example. It’s designed to be accessible for customers that are disabled, but it’s also inclusive to those that aren’t disabled. Now, nobody is excluded!
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. Beyonce and Target have both been sued due to a lack of web accessibility.
Let’s dive into details.
Designing for Visual Impairment
We’ll start with low-vision blindness. While there is a medical definition of what constitutes as low-vision, what we mean in the context of accessibility is those who experience a visual impairment that isn’t color blindness; and the extraordinary thing about designing for low-vision blindness is that even those with optimal visual acuity (also known as “20/20 vision”) can benefit from improved accessibility, which means:
- Optimizing font sizes
- Optimizing color contrast
- Supporting screen readers
Implement the Minimum Font Size
tl;dr it’s 16px, however this isn’t an official WCAG font size standard.
Ridiculously, Pornhub expects visually impaired users to scroll to the bottom of the screen, then click on a link labeled Visually Impaired under a heading obscurely labeled Discover. Now if that wasn’t obscure enough already, this link is also hidden between 7 other links, and the font size is a minuscule 13px; so not only is this counter-inclusive accessible version difficult to find, but even those with optimal vision will find the text elements difficult to read because of the small font size (the browser default is 16px).
Additionally, 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.
Maintain Optimal Color Contrast
Contrast defines how easy it is for the user to distinguish one element from another adjacent element (such as icon from background, or text from background), and is influenced heavily by color, where more color contrast = better visibility and readability.
Color contrast is measured in numbers — the WCAG 2.0 states an acceptable benchmark, which can be achieved by measuring the contrast between two colors using a color contrast analyzer. Without a doubt, the best color contrast analyzer is the Stark Plugin, since it’s free, works directly inside XD and Sketch, suggests alternative colors if the current ones aren’t contrasting enough, and simulates color blindness.
Color contrast analyzers operate by comparing two colors and scoring the contrast between 21–1, with two levels of conformity at AA and AAA. Sometimes this score is represented as a ratio, for example, the ratio between Pure White #ffffff and Pure Black #000000 is 21:1, the highest ratio of contrast that two colors can achieve. However, the ratio that we need to aim for depends on the font size of the text, since naturally, larger text has better readability, and thus the colors may not need to be as contrasting.
Normal text: below 14pt bold or 18pt normal:
- AA: 4.5:1 (aim for this)
- AAA: 7:1 (but this is better)
Large text: 14pt bold or 18pt normal, and above:
- AA: 3:1 (aim for this)
- AAA: 4.5:1 (but this is better)
AA-level accounts for the loss in contrast for those with low visual acuity, acquired and congenital color deficiencies, and the loss of contrast as a result of natural ageing. AAA is a fantastic result to achieve, but it isn’t required. Anything less than AA simply = Fail.
Below: #FFFFFF achieves near perfect contrast, whereas #7B7E81 only meets the AA benchmark. However, this is totally fine, because AA-level is the minimum requirement.
Additionally, a ratio of at least 3:1 is required for the following:
- Icons and form elements
- Graphical objects such as charts
- Focused, hovered, and active elements
Cater for Color Blindness
Different colors have different meaning. For instance, yellow can mean cheery or optimistic; however, this meaning can differ depending on the context or the user’s culture. For example, yellow can also be used as a cautionary, meaning hazardous.
And then there’s color blindness, or to use the technical term, Color Vision Deficiency, of which 4.5% of the world suffers from. Wikipedia describes CVD as “the decreased ability to see color or differences in color”, and there are different types of CVD, yet females are less likely to suffer from literally all of them. Different types of CVD include:
- Tritanopia (rare)
- Tritanomaly (rare)
- Cone Monochromacy (very rare)
- Rod Monochromacy or Achromatopsia (extremely rare)
Also, many devices today have a feature that makes it healthier to read at night by switching blue light to red light, because blue light keeps us awake and damages our eyes. When working on a design that involves a lot of reading (especially at night), this is something to consider — colors will appear more red when night mode is activated.
Considering all of the facts above, using color as the sole method of visual communication might not be the best idea. Another example: imagine a hyperlink wrapped in a block of text — some color-blind users won’t notice it, so we’d need to underline the link for additional contrasting. We all interpret color a little differently, so for best results, use the aforementioned Stark Plugin for quick color-blind simulations.
Assist Screen Readers
Disabled users often use assistive technology. A common example of assistive technology is the screen reader, also known as dictation or text-to-speech, which essentially dictates text-based content to visually impaired users. To help screen readers do this properly, visual elements like images, icons, form fields, and so on should be accompanied by some text, or at the very least, invisible text descriptions (referred to as “alt text” by developers) that are only visible to screen reader technology.
Equipped with at least an invisible text description, visual elements can then be deciphered by screen readers and audibly described to those with visual impairments.
Designers need to consider:
- Alternative text for images and hotspots
- Alternative text for icons without visual text labels
- Alternative text for video-based media, i.e. a transcript
- Visual text labels for form fields (for those not visually impaired)
- Dictation for on-screen changes like errors, alerts, and notifications
- Logically-ordered content, since screen readers read from top-to-bottom
Additionally, designers should bear in mind these three rules:
- Never use an image when text can easily convey the same meaning
- Page titles should be descriptive, since screen readers dictate these first
- When using alt-text with visual text labels, both should use the same wording
Designing for Reading Difficulties
Difficulty reading is one of those scenarios that designers often have trouble empathizing 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.
Design for Dyslexia
Dyslexia affects the reading ability of around 5–17% of the world — it’s a relatively ambiguous disability, hence the wild statistics. Dyslexics find it hard to interpret words and letters, which doesn’t mean that we must use a dyslexic-friendly font, but some are clearer than others, so this is something for us to consider when designing for dyslexia.
Fonts aside, we also need to think about the following:
- Alignment: left or right only (don’t justify)
- Line spacing: at least 1.5x the font size
- Paragraph spacing: at least 1.5x the line spacing
- Paragraph width: max. 80 characters; 40 for CJK characters
As well as the styling tips above, keep these in mind too:
- Headings: use them to structure content logically
- Backgrounds: define their color so it cannot be implied otherwise
- Horizontal scrolling: ensure that content doesn’t overflow the viewport
Designing for Motor Disabilities
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.
Require Simple Gestures
Interactions are difficult for those with motor disabilities, so try to avoid complex requirements such as swiping and shake-to-undo when simple tapping will do fine.
Additionally, ensure that tap targets are large enough for those unsteady with their hands, and also those with fat fingers. Size them at at least 44px² and space them appropriately. For links within a body of text, the 44px² rule doesn’t apply, but there should still be enough spacing so that users don’t click the wrong thing accidentally.
Allow More Time
Sometimes the user needs a little more time. In scenarios such as online banking, interfaces often “timeout” due to security concerns; however, we can reduce incurred frustration by letting the user request more time, and in the event that inactivity can accidentally lead to a loss of data, simply issue a warning so there are no surprises.
Anticipate Human Error
Disabled or not, all users make mistakes. It’s simply human nature. However, it’s important to alert users when errors occur, ideally as they arise; and if we can’t fix mistakes behind-the-scenes, the next best option is to help users fix them themselves.
Consider these tips for making forms more accessible:
- Let the user recover example data (if needed)
- Let the user verify their input before submission
- Enable auto-fill/complete to reduce typing requirements
Disabled users that navigate interfaces with the keyboard typically tab through elements using the tab key, which, as you can imagine, can be a bit tiresome; but we can improve this experience by making the first tab item a link that skips to the main content. Initiate a Google Search and hit the tab key to see how this works exactly!
Additionally, try to offer at least two ways to navigate; e.g. menu + search.
Accesskeys are single-key shortcuts. While these are convenient for some users, disabled users meaning to hit, say, K, but instead end up hitting L, might end up Liking something by accident*. Keyboard shortcuts can also conflict with screen readers and various app or OS-defined shortcuts, so it’s best to avoid defining them completely.
*Example taken from Dribbble, Twitter, and Facebook.
Exceptions can be made if shortcuts are switched off by default, although it really depends on the context and how well the interface deals with accidental interaction.
Responsive design refers to apps and websites that adapt to mobile, tablet, and desktop devices. When it comes to web accessibility, the WCAG 2.0 - Web Content Accessibility Guidelines specifically indicates that websites must be accessible on all screens all the way down to 320px in width, and functional when zoomed to 200%.
Orientation is crucial too — don’t forgot to design for landscape.
Designing for Cognitive Disabilities
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.
Without a doubt, the most stalling aspect of any user interface is usually the navigation, so dedicating extra attention to this area will inclusively improve the experience for all types of users. Bear in mind the following tips to reduce confusion:
- When linking, use anchor text that sets realistic expectations
- Maintain anchor text consistency when two links lead to the same destination
- Implement breadcrumbs to convey where the user stands in an event sequence
- Highlight the current keyboard focus (for input fields, a blinking cursor isn’t enough)
Popups that users weren’t expecting, layouts that aren’t consistent across screens, interfaces that abruptly change the keyboard focus, and other sudden changes not communicated beforehand — these types of cheeks are always a bad idea. They’re extremely difficult for visually-impaired users, confusing for cognitively disabled users, frustrating for those with motor disabilities, and outright annoying for everybody else.
Eliminate obstacles, and always design for user expectation.
Allow More Time
Repetitive and/or frequent alerts such as chat messages, reminders, and auto- updating newsfeeds can be somewhat frustrating; users with cognitive disabilities should be able to manually control the timing of these updates to allow themselves more time to read and understand, and in the event that the user feels bombarded, allowing them to dismiss alerts and modals using the esc key can be a nice touch.
Literally nobody likes autoplaying videos; but regardless, the WCAG 2.0 states that there should be a mechanism to control any audio that plays for more than 3 seconds.
Additionally, anything that moves, blinks, or scrolls automatically (i.e. carousels, animations, marquees, etc.) and lasts longer than 5 seconds should be controllable.
Anything that flashes more than 3 times/sec should be reasonably avoided, since flashing can induce seizures. Exceptions can be made if the flashing is small, low-contrast, and doesn’t contain too much red; however, like with autoplay and other unanticipated behaviours as mentioned above, it’s usually best to avoid making interfaces reliant on sound or animation, as the risk is often not worth the reward.
Designing for Hearing Difficulties
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. For example, a satisfying “ding!” upon task completion could be twinned with a check ✓ animation.
Naturally, sign language is optional due to the complexities of its implementation.
Disabilities are very common, but also, the advantages of meeting accessibility standards without us having to design specialized 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.
This guide forms part of our ebook, A Beginner’s Guide to Designing Great UX.
Got feedback? We’d love to hear it. Send us a tweet @uxtricksdesign.