Include all users: how to make your designs more accessible

Accessibility in UI/UX design refers to creating apps that are easy to use for those with auditory, physical, visual, neurological or cognitive disabilities. These types of users won’t be able to read, view and interact with content the way others can, or they navigate apps using screen readers, screen magnifiers, keyguards, or mouse replacements. This means that designers should build apps with these restrictions in mind, so that users with disabilities can still fulfill their goals like any other user.

Plus, well done web accessibility benefits other people as well, says the Web Accessibility Initiative: 

• people using mobile phones, smart watches, smart TVs, and other devices with small screens, different input modes, etc.
• older people with changing abilities due to aging
• people with “temporary disabilities” such as a broken arm or lost glasses
• people with “situational limitations” such as in bright sunlight or in an environment where they cannot listen to audio
• people using a slow Internet connection, or who have limited or expensive bandwidth

Generally, you should ensure at least a sensible degree of accessibility. Giving users good color contrast, Alternative Text descriptions for images, audio transcripts, a well-structured navigation and easy to understand copy is the bare minimum.

So in this article, we’re going to compile a series of rules for accessible design. Most of these are standardized by the Web Accessibility Initiative, which goes into lots of detail about accessible websites. We’ll be focusing on design principles, so for more info, check out their platform.

Make your pages less confusing

Visual impairments are the main types of disabilities that UI/UX designers can create better designs for. They rely the most on design elements such as colors, typography or layout. To get a better understanding of what these impairments mean, here is a list of bad design patterns that can affect these users:

• Images, controls, and other structural elements that do not have equivalent text alternatives - in other words, you should provide helper text, tooltips, and descriptions for all images.

• Text, images, and page layouts that cannot be resized, or that lose information when resized - lots of users with visual impairments will need to zoom into web pages. Make sure your designs can support that. Some browsers let you increase the size of text content, so you need to make sure that bigger text won’t ruin your designs - text bits shouldn’t overlap or disappear, buttons and forms should be visible, and you shouldn’t make your users scroll horizontally to read something. The key here is making your apps responsive. Here is an article we wrote that can help.

• Missing visual and non-visual orientation cues, page structure, and other navigational aids - these are your “next” or “back” buttons alongside arrows, clear headings and progress bars.

• Video content that does not have text or audio alternatives, or an audio-description track - YouTube provides AI-based closed captions for most videos, so don’t hesitate to upload video content there and embed it into your website or app. Unless you have the right budget to do captions or descriptions, this is quicker and more efficient.

• Inconsistent, unpredictable, and overly complicated navigation mechanisms and page functions - standard design patterns exist for a reason: they work. Creating a more complex, abstract navigation will create trouble for those using keyboard navigation or screen readers.

• Text and images with insufficient contrast between foreground and background color combinations - The standard contrast ratio is 4.5:1, and you can test that here.

• Websites, web browsers, and authoring tools that do not provide full keyboard support. This means that you have to make sure your app follows a logical navigation for keyboard use - don’t put standard items like headers, menus or footers in unexpected places.

To help users navigate through your app or website efficiently, you should follow a couple of standard page structure models. A clear structure will help those with cognitive disabilities, those using keyboards, screen readers, browser tools that only show crucial page content, or those with visual impairments.

So here are a few elements you should consider:

• Page regions: the header, footer, navigation, main content and potential sidebar content must be clearly marked. This can be done in development, but your designs should also make them clear. The header is always at the top, the footer is at the bottom, the navigation is either on the left or on the top, the main content is in the center and any additional content will go on the right.

• Headings: headings go from 1 to 6, 1 being the biggest and 6 the smallest. Using these, you can structure content in a logical way. The key is ordering them correctly: Don’t start with a Heading 2 and continue with a Heading 4. Heading 1 will always go first, followed by 2, 3 and so on, until 6. Make sure they’re marked accordingly in code as well - what you can try is building a typography page in your design document, to mark the style of each heading you used. You can take some inspo from UI Kits.

Source

• Numbered lists: these might look cool if you create custom list items, like numbers placed in circles and their respective texts near them. But it’s important to mark these elements as numbered lists if that’s what they’re supposed to be: this way, your developers will code them as such, which can be read by screen readers. Otherwise, those users will just hear that there’s an image, and then a piece of text.

• Moving items: carousels, ads that change after a few minutes, scrolling feeds, or anything that flashes or blinks. This kind of content can be tricky to navigate for those with ADD or cognitive disabilities. Make sure users can control this kind of content, by giving them Pause, Next and Back buttons.. Let your development team know what time interval these items should move at - and make sure they’re not too fast. Go for 30 seconds, or up to 2 minutes for longer content. Flashing content could also trigger seizures in users with epilepsy, so keep that in mind (you can read more about that here).

In terms of content, you should also consider users with cognitive disabilities. To help them, you need to make sure it’s clear what language your content is in (if it’s not English), you should provide definitions for complex terms or abbreviations, and use the clearest words possible. For the last tip, you can also provide an additional simplified version of your content. 

Also, make sure that key info (alerts, especially) doesn’t disappear too fast. You can use this platform to see reading time for a piece of text. If you want to play it safe, double that time when creating alerts.

Make your pages more readable

A study conducted by the Nielsen Norman Group revealed that older users find the Internet difficult to navigate due to the small fonts. In fact, lots of designers choose small fonts for purely aesthetic reasons, or to fit more content into a small space. But this makes it more difficult for a part of their audience to view their content. The solution?

1. Make body copy at least size 16, or 18 if possible. Avoid going lower than that, or make sure users can zoom in without losing page structure.

2. Use a bold font weight for important information.

3. Create good contrast between the foreground and background: black text on white backgrounds or the other way around. No need for light shades of gray, pastel colors or neon colors on white backgrounds. On dark backgrounds, feel free to use pastels and neons, but don’t go too dark. The general rule is: dark background - light text colors, light background - dark text colors.

4. Use readable fonts. Those pretty, Pinterest-y handwriting fonts might be cute, but for maximum readability, stick to classic web fonts like Roboto and Lato, or system fonts like Arial, Calibri or Verdana. Sans-serif fonts are generally easy to read, as they have simpler, less detailed structures. Serif fonts, in comparison, have more strokes to each letter, which can make them harder to read.

What about Times New Roman? You might ask. Even though it’s such a classic font, Times New Roman is a serif font, and might be difficult to read.

There’s another layer to this, however: the styles used for text aren’t everything. The way content is arranged is also very relevant:

• Leave spaces between paragraphs and avoid big blocks of interrupted text.
• Mark listed items accordingly: use numbered lists or bulleted lists.
• Make a clear distinction between headings and body copy: this means making the headings bigger. If your body copy is size 16, try 24 for your headings and 20 for subheadings. 
• Don’t make text full width, as it becomes hard to read: there’s more horizontal space for one’s eyes to scan through, which can quickly tire them out. Using around 50-60% of your screen width for a single block of text will be easier to scan through.

The Web Accessibility Initiative also talks about the importance of dividing bits of content properly. Use clear titles that describe the content accurately, headings that divide content in a logical way, proper spacing between elements and clear relationships between text and images.

Source

Provide good contrast between elements

Remember those diagrams where a number is “hidden” in a background with a slightly lighter color and you should be able to tell what number it is? Imagine you can never tell the number apart from the diagram background. That’s a good way to understand what color blindness is like, and to design apps accordingly.

It’s highly essential to create a good contrast between elements in the foreground and those in the background. Otherwise, your users won’t be able to tell things apart. As we’ve already mentioned, this means using dark foreground colors on light backgrounds and light foreground colors on dark backgrounds. But that sounds quite broad, so how can you tell if you have good contrast?

Export your design as an image and turn its saturation to 0. This way, you have a grayscale view of your design. Take a good look at every element and see if those that serve different purposes actually look the same: these are the elements that you’ll need to modify, to improve their contrast. If all elements are still distinct while in grayscale, then you’re all set.

The Web Accessibility Initiative also talks about the opposite situation, where users with reading disabilities might need lower luminance in text elements. So how can you please everyone? It’s best to make sure your app or website supports custom colors, which gives users the freedom to make apps work for them.

Don’t use colors as the only way to convey information

The key here is making sure that anything you’re telling apart through colors also has a text description. A classic example is that of most Save and Cancel buttons - the first is often green and the second is often red or gray. Even in grayscale, you can tell them apart by the button text. But what happens when it’s not something as black and white as buttons?

One good example is that of inputs. Don’t just use red text to show that something is required, says the Web Accessibility Initiative. Add an asterix as well - and remember to explain what it’s for, and make it visible. We’d also like to add one more principle here: with input validation, it might not be enough to make the input margins red if there’s an error. Add an error text below the input to further prove that there’s an issue. This is standard with most frontend development frameworks, so make sure it’s not excluded.

Another example is using colors to indicate status. This is generally fine, as long as you offer an explanation for those colors, either by tooltip or right where the colors are. Or keeping it simple with high contrast, commonly recognized colors - such as red for something negative, yellow for something not bad nor good, and green for success.

Make it clear that an element is interactive

Most of us have been on the Internet long enough to recognize 2 major types of interactive elements: links and buttons. Links are identifiable by their classic sky blue color and underlined text, while buttons are almost always filled in and large enough to be visible for users. The key is for them to stand out from regular text. But just to make sure that both you and your users are on the same page, create different states for these elements to tell apart when:

• The button or link hasn’t been clicked yet
• You’re hovering over them
• You’ve selected them via keyboard controls or other accessibility tools
• They’ve been clicked on and will lead to something
• They’re not clickable at the moment

In short, you need these states: primary, hover, focus/selected (can be different but are usually one and the same), and disabled.

Source: Hannah Milan on Dribbble

You can also create an extra state for those using keyboards to navigate, like the Web Accessibility Initiative tells you:

Why is this important? You might ask. Users navigating through keyboards will need to know when they’ve selected an item they want to interact with. Plus, they should be given ample controls that assist them: arrows to go to the next or previous step, Back buttons, Next buttons, a clear menu with items listed one below the other, and so on.

Add text and audio descriptions to photo and video content

Not everyone will be able to properly view photo or video content, either due to auditory or visual disabilities, or due to weak Internet connection. Thus, it’s essential to provide proper captions for such content. Especially if this content is important to the users’ experience on your app or website: tutorials, videos that sum up an article, graphs & reports, and so on.

When it comes to photo content, you can try 2 methods:

• Write a description of the photo as a caption right below it. Make sure to clearly describe everything going on in the photo, and that it’s not smaller than size 14.
• Write a description that your development team can code in as an alternate text. This won’t show up in your design, but it will be included in the code - which means screen readers will pick it up. Same principle applies: describe everything in the photo.

When it comes to videos, there are a few things you can do:

• Provide an audio description that not only covers what’s spoken in the video, but also the images shown. This is helpful for those with visual impairments.
• Provide captions that show up in the video itself. Same principle: describes what’s happening plus what’s being said.
• Provide a transcript of the video that can be opened separately. This is helpful for users with screen readers, and the transcriptions can also be translated, if need be, since they’re just bits of text.

Source

You can read more about ALT text and even check the ALT text you’ve made here.

And there you have it, these were some of the most important tips out there for inclusive design. You can go a lot more in depth via the Web Accessibility Initiative, which provides additional tools and instructions for more specific needs. We mostly scratched the surface, so if you’re designing an app directed towards users with disabilities, it’s best to check their website. But the tips we gave should be enough for general accessibility in your apps. Don’t forget to collaborate with your development team, as their code will solidify all the measures you took in your designs.

If you’re just looking to get software built, contact us and let’s see what we can create together.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.