Accessibility II - A Guide for UX / UI Designers

08. February 2021

After having given a basic insight into accessibility in the first part of our three-part series - with a special focus on the added value for users and customers - we now get down to the nitty-gritty!

In the second article, we will discuss what constitutes an a11y-compliant website and what all parties involved have to pay attention to during development. The practical guide is aimed in particular at UX and UI designers and front-end developers. But all other participants, from stakeholders to project managers, can also take away a few tricks for everyday project work. The tips and tricks are an important working basis for us to guarantee an optimal user experience, no matter for whom and in which situation. Send us an email at info@sumcumo.com if you have any other recommendations on how to approach accessibility in projects.
Our little guide covers everything from universal design, user-centeredness, language and media, contrast, images and graphics, and fonts and typography in the context of accessibility.

Universal design

When it comes to accessibility and design, many probably still think of special curls and rather unattractive websites. But design, functionality and accessibility go hand in hand. We establish the term "Universal Design" in this context. This guide is explicitly not about building websites specifically for people who rely on accessibility, but about websites that function universally, i.e., the same for all people. This is incredibly exciting from a designer's perspective, because it's all about finding creative solutions to problems that may not be apparent at first glance. Therefore, our recommendations don't offer any guarantee for a perfect accessible website, but are much more meant to give suggestions on what to look out for and what things are worth thinking about.

Let's start with one of the most important principles: Know your Users.

For whom is development done?

A TL;DR of the first article:

There are not only chronic limitations, but also temporary ones.
Many of these limitations also result from classic everyday situations.
Some limitations are also not obvious at first glance and therefore often forgotten in UI and UX design

Questions you should always have in mind: Can I use the app only with a keyboard, one-handed, or by voice? If so, how well does that work?

What parts of the app are worth paying special attention to?

Users who use the website via a screen reader usually have to have the complete navigation read out to them at the beginning in order to get their bearings. They usually have to repeat this step for each subpage until they reach their destination. Are breadcrumbs useful here?

Users who mainly use the keyboard to navigate the website usually have to "tab" through the individual points. How well does this work? Are the main navigation points of the page immediately visible, or does each navigation element have to be opened first?

The classic conflict here is between a shallow and a deep page hierarchy. A sitemap is mandatory, often a search is also useful.

People with cognitive disabilities often have problems with complex navigation structures, this also needs to be considered.

Language and media

Everyone would like to have unique texts on their website. Just as there are stock photos, there are also interchangeable text modules that can be found on every website. Here's something to keep in mind: not only users with cognitive disabilities may have difficulty understanding complex texts, but non-native speakers may also face challenges. Not to mention users who just want to get to their destination quickly and don't want to interpret a novel. Here the following thoughts are worthwhile:

Are the chosen texts unambiguous, clear and close to everyday language?
Are foreign words explained or even replaced by common terms?
Are the sentences complete, structured, and concise?
Is it helpful and useful to offer a version in simple language or is the "first version" of the website already sufficiently accessible?
Can the happy path perhaps also be designed intuitively? Just replace all the text on the page with "Lorem Ipsum". Is it still obvious how I can take out an insurance policy, for example? Visit the website of a Dutch bank or insurance company and test how well you can find your way around at first glance. This little experiment might give you a sense of what's important.
Are "call-to-action" elements named in a way that accurately describes the action they trigger?

Is media included on the website? If videos, can they be understood without sound? Is this media necessary to use the site?

Forms

If we design an interactive website, we will not be able to avoid form fields. Somehow the users have to be able to express their wishes. Here the following thoughts are worthwhile:

Boundaries: Where do I have to click to make an entry? Where does my form field end, where does it begin?
Placeholdertext: As soon as you navigate into the field and make an input, it disappears. What should be there again?
Placeholder text: Are preformatted placeholders really helpful? Does the user understand what to enter and how?
Validations: We can't rely on colors alone. For someone with red-green weakness, a field with a red border is no help in case of an error. How can we make users understand that something went wrong? (Do we need a "hint" at the form field?).
Functionality not by hovering alone: If a field is only recognizable by hovering that it can be edited, the operation by keyboard or touch device leads to restrictions.

Components and their identity

Now it gets a bit theoretical! Actually, each component should have a function. A dropdown menu where you can search and delete found tags right away is a good example of a component with a clear identity.

Colors

Colors serve many functions: They can guide the user:inside, evoke emotions or bring new thoughts. However, the meaning of colors can be lost or misinterpreted if they are not perceived or perceived differently than intended.

Does the app lose meaning if I remove the color?
Will orientation be lost due to missing colors?
For which market is my app intended? Do the colors used have a different symbolic power in other countries?
Do I overstimulate users by using too high contrasts or over-saturated colors?

Speaking of contrast

Color contrasts allow users to distinguish between elements. Images with higher contrast make perception easier. For example, an image with low contrast may be difficult for some user:ins to perceive in difficult lighting conditions, such as in strong sunshine or at night.

Contrast ratios indicate how one color differs from another, usually indicated by 1:1, for example. The greater the difference in ratio, the greater the difference in luminance between the colors. According to the World Wide Web Consortium (W3C), the contrast ratio between a color and its background ranges from 1-21.

The W3C recommends the following contrast ratios for body text and image text:

Large text (above 14px bold/18px normal) and graphics 3:1 against the background.
Small text (below 14px bold/18px normal) 4.5:1 in front of the background

So: do foreground and background colors of all text, symbols, icons and controls comply with the contrast ratio guidelines?

To check this, there are some handy online tools:

Material Design
Colorable
Contrast Grid
To not leave Sketch or Figma in the design process, there is a great Plugin.

Images, Graphics & Icons

Images can emphasize a design and the message of an application, but they can also illustrate complex ideas. Whatever the purpose of an image, everyone should be informed of its meaning, including user:s who rely on screen readers.

Ideally, designers should annotate the images in their designs to convey the meaning. Developers can include this information in the alt text of the image.

Hints for good alt text:

Don't describe what the image looks like, but what information is included.
Include decorative elements via CSS if possible, so that screen readers don't stumble over irrelevant content and confuse users.
Create concise and short descriptions, no more than two sentences of under 20 words each.
If the information in an image requires a longer description, it should be inserted as a heading, caption (within a picture element), paragraph, or similar. The Alt tag then contains only a short description.
Diagram descriptions should be detailed enough to reflect all facts and figures.

Always keep the following questions in mind:

Does an image contain information that would be lost if it were not visible?
How could I provide the information in a non-visual way?
If an image upload is possible, can user:s also provide an alt text description?

Fonts & typography

Not only should design be responsive to different output devices, but text should be flexible enough to allow users to adjust font size, line height, or letter spacing to make it comfortable to read. Many users with permanent limitations use custom CSS that helps them have a better reading experience.

It's interesting to note that it's not the font that determines good readability, but the font style: decorative or italic font styles are difficult for many people to work with, especially those with dyslexia. The same is true for small font sizes and text in capitals.

Overall, larger text, shorter line lengths, higher line heights, and increased letter spacing can help all user:s have a better reading experience.

**These texts are ideal for a wide reading audience.

left- or right-aligned
with a minimum font size of 16p
with a line spacing of at least 1.5 times the font size
with a paragraph spacing of at least 1.5 times the line spacing
with a line length of at most 80 characters

Font sizes below 400 should be avoided: They may work for large headings, but are too difficult to read at smaller sizes.

The Web Accessibility Guidelines, WCAG 2.0 does not recommend a fixed font size, but 16px is a reasonable guide for the browser standard. However, it also requires that layouts of 320px or larger adapt fluidly to all screen sizes and remain fully readable even when the view is zoomed to 200% - this ensures that text does not accidentally overflow the window.

It's important to consider:

Is the design flexible enough that the font can be adjusted by the user to a comfortable and readable typeface?
Is the font style easy to read?

Animations

Animations are great, aren't they? They can direct our user:s focus, give them orientation. Moving elements bring pages and brands to life, can make them special. But there are two sides to this coin: Animations can also distract, confuse or even trigger health problems.

Fast flickering (more than three flashes per second) or expressive animations and patterns can cause epileptic seizures, but also headaches and dizziness.

Users with vestibular disorders (the vestibular system controls balance and the sense of movement) may also develop dizziness with other phenomena such as parallax or motion effects. Continuous animations can be distracting for all users:inside, especially for those who suffer from concentration difficulties.

We don't want to ban animations, but it is important to know what purpose they serve and how to design "safe" animations. In general, you should try to design animations that cover small distances, match the direction and speed of other moving objects (including the scroll bar), and are relatively small in relation to the screen size.

Users can enable the "reduced motion" mode on their devices, allowing moving elements to be played out alternatively. And the best: Developers can intercept this mode and play out other styles via a media query. Here you should ask yourself the following questions:

Are there effects that could cause seizures or dizziness?
Are there animations that could be distracting due to constant movement or auto-updates?
Can I provide options to stop, pause, hide or animations/effects?
Can I already control effects specifically via CSS?

Testing

Here you can help yourself with small tricks and quickly test the usage from an accessibility point of view yourself by putting yourself in typical situations where you are limited. And don't worry, you don't have to break your arm. Just try to use the app (e.g. as a prototype) on a bus or train while holding on with one hand. Is it still possible to use the app? Are all functions easily accessible and applicable with one hand? Do I manage to reach the desired usage goal? If you have to answer one of the questions in the negative after the small accessibility test, you should adjust the concept in the appropriate places and then simply do the test again. Such a small test during development guarantees an optimal user experience and saves expensive adjustments afterwards.

If you have thought about all these questions once during the development process, an important step towards universal design is already done. It is now up to the developers to implement the frontends accordingly. In the next and last part of our article series, we will tell you what you should pay special attention to.

Author See author profile