Blog
-
Tech Talks

Designing Accessible Application User Interfaces (part 2)

Reading time: ca.
3
minutes

Welcome back to our Optis Tech Talk on designing user interfaces with the user experience and accessibility in mind! In the last part, we looked at colours, contrast, fonts and hierarchy. In this part, we will check out spacing, buttons, cards and forms. Joining us once more are Carlo Nomes and Daphne Deckers, two of our developers with a knack for UI and UX.

Spacing

Use rem units instead of px units to ensure consistent spacing throughout applications and increase accessibility. This includes font sizes, but also margins, paddings, and all other visual elements.Using rem allows for easy scaling should a user increase their font size, which often happens for users with a visual impairment or on large screens. This will also implicitly help to improve the spacing in your layout.

When deciding on spacing, always use relative instead of absolute spacing. Instead of “this title needs to be 100px away from the previous element and 50px from the next paragraph”, say “I want this title to be twice as far away from the previous paragraph as from the next paragraph”.

Another tip is to always start with too much white space and reduce it until you are happy with the result. Working from narrow to wide will often lead to a user interface that feels cramped.Keep in mind that dense interfaces have their place, though, such as dashboards that need to display lots of information at once.

Image source: https://www.refactoringui.com/

Buttons

We recommend placing buttons in the bottom right corner for most elements, since this is the position most recognised by users. You should align their visual design and location with their purpose.

-> Primary actions like save or confirm should be in the rightmost corner and obviously marked. You can make these stand out by making this button the only one that is filled with the primary colour.

-> Secondary actions should also be present, but less obviously so. One way of doing this is by using outlined buttons.

-> Tertiary actions like cancel and close should be clearly visible, but demand less attention from the user.For these actions, use a text button with the default text colour.

-> Destructive actions like delete or remove should be marked by the danger or warning accent colour in your palette. If this action could cause potentially unwanted side effects, warn the user through a confirmation window.

Image source: https://www.refactoringui.com/

Cards

Applications will often need to show a grouped collection of data. You could use either tables or cards, so determine which is most useful for your use case first. If you decide to use cards, make sure that you structure it in a way that shows the user what the most important information is. Don’t just use a [label: data] format, since users can generally infer what the type of data is. 

Let’s use a user overview page as an example. Don’t just give a box of information:

name: Nomes
first name: Carlo
location: Antwerp Belgium
title: JavaScript Consultant
company: Optis
email: carlo.nomes@optis.be

Instead, use a sequence and visual cues that make it feel logical to the user:

Carlo Nomes

Living in Antwerp, Belgium
JavaScript Consultant (Optis)

carlo.nomes@optis.be

Another way of providing a clear understanding for users is using icons, but be cautious when doing so. Screen readers have a hard time coping with icons, so your accessibility level may decrease. We recommend using the aria-label attribute to deal with this.

If you use cards or boxes, don’t overuse them. If there are too many of them, your application will look busy and untidy. Instead, look at alternatives like dividers or use larger spacing.

Forms

In most cases, forms will be the primary way of interacting with your application for users. As opposed to cards, users will generally not clearly understand what they need to enter, because there is no data yet to interpret.

You should always provide a label for every single input and make sure that they do not disappear while it is still being used. Do not rely on placeholders to do a label’s job.

Finally, include the for=”elementID” syntax on all labels or nest your input inside the label. In some cases, your framework will do this automatically. This will ensure that screen reader users can also clearly understand which value the input expects. As an added benefit, an input will get focused when a user clicks a label.

Conclusion

There are a lot of elements to keep in mind when designing the user interface of an application. This list is therefore not exhaustive, but it mentions the most important aspects. We highly recommend asking a specialised designer for help if your application will be used frequently. However, the information in this article is a good way to start with the basics and avoid some frequently made mistakes. Whatever you do, always keep accessibility in mind!

Looking for some help with coding and designing your next application? Give Optis a call, and we will love to help you out!

Daphne Deckers

April 6, 2022

Read the highlights of our blog

"Each project pushes our skills farther and expands our expertise"

Let's talk!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
We value your privacy! We use cookies to enhance your browsing experience and analyse our traffic.
By clicking "Accept All", you consent to our use of cookies.