Accessibility in UX Decisions
Imagine going out for dinner and realizing the restaurant is not accessible for someone in a wheelchair. That’s bad news, for your friend with a broken leg and for the restaurant. Digital experiences are no different.
Web Accessibility helps more people than you would think and doesn’t only apply to users with motor disabilities or the visually impaired. Non-native English speakers, colorblind users or those with weakened eyesight all feel the effects of inaccessible platforms.
In this article, we’ll dive into the importance of accessibility and what it means to build an accessible product.
Why accessibility is crucial
At Usabilla, we believe all users should be able to leave feedback on their digital experiences and so do our customers, which means we need our platform and our feedback forms to be highly accessible. After all, you can’t be truly customer-centric when excluding 15% of the world population.
In the U.S. alone, 57 million Americans have a disability, according to Forrester research. As a result, regulations are increasingly ensuring that platforms are accessible. There are already two accessibility standards in place: Section 508 for the public sector and WCAG 2.0 (Web Content Accessibility Guidelines) for the private sector.
These ‘guides’ are a sort of checklist to help determine whether a site or app is accessible. Though Section 508 is technically mandatory, many sites lag behind when it comes to accessibility.
It’s one of the many roles of a Product Designer to watch out for the groups described in the above image, in each step of building a product. A developer can make accessibility work, but it’s the Product Designer that must first think about it. That is, if you want to do development on a design that’s not accessible, it simply won’t be accessible.
Terms like human-centered design or inclusive design, along with accessibility, all keep in mind one fact:
The average user does not exist.
When such a large demographic is unable to use your site or app simply because it’s not accessible, you miss out on an entirely untapped market. Alienating certain customers is bad for your brand’s revenue and reputation. However, if the UX was built with the mindset of accessibility already, it can really help in the long run.
Ingredients for accessible design
We all want to create beautiful, dribbble-worthy designs. Subtle grays and light color palettes may be aesthetically pleasing to you, but the reality is that color-blind and visually impaired users need high contrast colors for backgrounds and text.
When it comes to accessibility guidelines, the WCAG 2.0 (as mentioned above) has three conformance levels. AA is the industry standard, and it says that you must follow a color contrast ratio of 4.5:1, that is, between foreground (i.e. text, images) and background.
This should be respected especially for your most important call to actions. There are plenty of tools you can use to test for this ratio, for instance, Contrast Ratio.
Here is an example of this check using our own Usabilla colors:
Another important element to accessibility in terms of colors is designing for color blindness. This becomes even more important when designing dashboards and graphs as color-blind users can’t see the difference between certain colors. We’ve dug into the topic thoroughly before, so here is where you can find some tips.
2. Keyboard navigation
Users that can’t use a mouse, and frankly, your power users that want to use your product quickly, need carefully crafted keyboard navigation to achieve their tasks. This means you must first plan the keyboard navigation of the whole page layout, try to understand the most common flow and see just how will your users will jump from one component to the other. In this way, you ensure that users can complete their tasks with only the keyboard.
Our front-end codebase is based on React, and for each component implemented in our design system we make sure it’s accessible to use via keyboard navigation. At Usabilla, our developers won’t approve a design if there is no keyboard specification when a custom component is created by the designer. A developer also won’t merge a PR (pull request) in Github if the designer didn’t check and approve the component.
Here is our own example of the tags our designer would include to make the intended flow of actions clear to developers:
We asked our front-end Software Engineer what she would expect a Product Designer to know when it comes to accessible keyboard navigation:
“As our Product Designer creates the whole commentation for the layout, she needs to think about where each click leads and then write out that keyboard sign so developers can implement it. In writing down the signs moving between these elements, it’s important to respect the standards so that users have an easy time navigating the site (i.e. using keyboard navigation that is similar to that of other sites).”
Katia Agnamazian, Software Engineer, Usabilla
*Trick: Don’t reinvent the wheel. Use resources like component libraries (we like Semantic UI) to tackle accessibility instead of ignoring it.
Here is an example from WebAIM of just a few standard practice keyboard navigation shortcuts to follow:
3. Semantic HTML
Say what? In short, semantic HTML reinforces the meaning of certain elements of a web page rather than just defining its look. Let’s make this more clear with an example.
In HTML, a <p> tag indicates a paragraph, both in terms of semantics and look. Users know a paragraph when they see one and browsers know how to display them. On the other hand, tags like <b> and <i> (bold and italic) are merely presentational, since they only define how the text should look without providing any additional meaning to what’s displayed.
The role of this HTML is for all browsers to easily understand and reflect these components as intended in the visual representation. Be careful to consider the semantic in naming and designing components. For example, if we want a subtle interaction, we might design a button that is only text and underlined.
This might sound like stating the obvious, but a link and a button are two different things. If you are designing a button that looks like a link, you are not only confusing your developers but also your users and screen readers.
If you don’t know what a screen reader is, read on to our next point, which is….
A screen reader is a tool which reads your HTML page and interprets it. Readability for visually impaired users depends largely on screen readers. These work closely with computer Operating Systems (OS) to provide information about icons, menus, dialogue boxes, etc. so that the right information is displayed.
Though screen reading is more concerned with the technical implementation of a design, it’s good to keep in mind when deciding on header structure. Headers must be designed with a hierarchy in mind, rather than a subjective variety of font sizes.
This means that font size should respect the semantic of the webpage, moving from bigger headers to gradually smaller headers. This ensures that font sizes are readable to screen readers so they can interpret and output the correct text, as shown below.
When you align what you are designing with what is going to be built, developers can build accordingly, screen readers interpret correctly and users can understand the structure of your page.
Making a site or platform accessible is not an easy task. It involves the cooperation of everyone on your team, starting from the UX design of a page all the way to its development.
As regulations become more widespread and in effect, accessibility is no longer a plus but the standard. The sooner you acknowledge that ‘the average user’ does not exist, the faster you’ll reach a level of accessibility to be proud of.
“It is not an easy task to be 100% accessible and sometimes you make some compromise, but it all starts with having the right mindset in the team.”
Gal Agmon, Senior Product Designer, Usabilla
Start somewhere and over time, you’ll see the hard work pay off.
Like what you see? Click below to read more blogs in the User-Centric Mindsets Series.