Five easy accessibility quick-wins for UX Designers

Author
VI Company
Categories
Publish date
share-image for the article Five easy accessibility quick wins for UX Designers by Max Senden

As UX Designers we oftentimes place ourselves in the mind of the end-user during the creative process. We do so via user research, empathy mapping, customer journeys, interviews, co-creation sessions, and so on. After all, without understanding the end-users' needs & desires we cannot design efficiently.

However, when it comes to designing for end-users with impairments many UX Designers tend to drop the ball. As a result, the products they design oftentimes receive a low accessibility rating and are either difficult or impractical in use for this particular group of end-users.

Common excuses why UX Designers do not pay attention to accessibility

  • It’s not second nature
    Like the vast majority of end-users, you use these applications through a series of visual queues and web conventions. For you, these things are second nature. Therefore, it’s counter-intuitive to place yourself in the position of an end-user who is blind or lacks control of his or her hands.

  • It’s only a small minority
    The percentage of end-users whose impairments hinder their ability to use the application you're currently designing is negligible, perhaps even non-existent. Thus, there is little or no incentive to accommodate them.

  • It’s too complex
    Sometimes, the problems UX Designers work on are incredibly complex and difficult to understand. Creating a simple solution that is accessible for the majority of end-users without impairments is already a huge challenge in itself.

  • It's too late
    The web application is in the final stage of development, it might even be live already. Making changes now to improve its accessibility rating would delay its launch or might be costly to implement.

  • It’s on the backlog
    Each and every application has issues (i.e. tickets, user stories, bug fixes, etc) that remain on its backlog forever because nobody wants to deal with them. If it's not the Product Owner who drags the item to the bottom, then it's a member of the Product Team.

  • It’s not my job
    Designing for the end-users with impairments is actually part of the job of UX Designers. However, it’s not something UX Designers can do by themselves. A lot of accessibility issues are tackled in the deep-end of the code. Hence, it requires UX Designers and Developers to proactively collaborate.

  • It’s an unnecessary change
    Only a small percentage of all web applications in existence has been fully optimized for end-users with impairments. And so, thanks to years of experience using sub-optimal applications, this group of end-users has learned to make do with what is available to them.

Why UX Designers make excuses to not focus on accessibility issues

Chances are that you (assuming you are a UX Designer) have used at least one of these excuses in the past year as an argument for you to not try harder to make your designs accessible. This is not a value judgment though. Everybody involved in the design process of applications does so from time to time.

After all, designing for end-users whose impairments hinder their ability to use applications is difficult, time-consuming, and costly. However, the good news is that it's not impossible. In fact, there are a lot of easy quick-wins to be made. Next to that, improving the accessibility rating of your application comes with many unexpected benefits.

Why improve a web application's accessibility rating?

There are various reasons why you want your application to be as accessible as possible.

  • The law requires applications to be accessible
    Both the E.U. and the U.S. have implemented laws (The Web Accessibility Directive and The Americans with Disabilities Act respectively) that require applications to be accessible. Breaking the laws is not without consequence. In 2019 alone, 11.053 web accessibility lawsuits were filed in U.S. federal courts.

  • A high accessibility rating improves your SEO rating
    Designing an accessible application makes it easier for Google, Bing, and other search engines to "read" the contents of your application. In turn, these search engines can provide users who are searching for information with more detailed, relevant, and overall higher quality results. Better accessibility can lead to a huge boost in traffic coming from search engines.

  • End-users without impairments also benefit from it
    Applications with a high accessibility rating are easy to navigate and use for all types of end-users. A properly structured application can be scanned within the blink of an eye (or screen reader), interactive elements are clearly marked as such, and the route from point A to point B is intuitive.

  • You'll become a better UX Designer, UX Writer and Developer
    Designing an accessible application means having to design in a structured and descriptive manner. Sexy designs might be good for your Dribbble career, but in the real world, end-users want applications that are useful, functional and add value to their lives.

How to increase a web application's accessibility rating?

The W3C has created the Web Content Accessibility Guidelines (WCAG): a comprehensive resource on web accessibility conventions.

If this is your first time reading the WCAG you might feel overwhelmed and discouraged. Some of you might even come to the conclusion that improving the accessibility rating of your application is a time-consuming, costly, and difficult undertaking. At times this is true, but it doesn't have to be. In fact, there are plenty of easy quick-wins that require little time or effort to implement.

Five easy accessibility quick-wins for UX Designers


###1. Write alt texts for all images Many of us have seen alt texts without knowing what these are. They oftentimes appear when an image link is broken, or the image itself cannot be loaded because of an unstable internet connection.
illustration showcasing the difference between having, and not having, and alt text in your image

Alt texts should not be confused with captions that usually appear next to or below an image and provide the viewer with some additional context. Instead, alt texts have been specifically designed to be read by screen readers and search engines. In normal circumstances, you will not see an image's alt text.

The general rule of thumb is that the one who creates or selects the image is responsible for writing the image's alt text. Oftentimes, this is either an SEO specialist, Marketeer, or Designer. It's never a Developer's responsibility to write alt texts for images that he or she did not create or select.

How to write a proper alt text

A proper alt text provides screen readers and search engines with a detailed description of the image. This way screen readers can read the image out loud to users with impairments and enables search engines to optimally "index" (i.e. see, read, understand, and categorize) the image. Using relevant keywords in the alt texts significantly boosts your application's SEO rating.

For a detailed explanation on alt texts, and what makes a good alt text give MOZ's article on the topic a read.


###2. Write ARIA labels ARIA labels are similar to alt texts. However, instead of providing a description for an image, ARIA labels provide descriptions for all other visual web elements in an application. Contrary to alt texts, ARIA labels are not indexed by search engines.

In practice, you use ARIA labels whenever text-labels are not visible on the screen (i.e. logos, icons, some buttons, etc) or when visible texts function as a label an element (e.g. a title that defines the subject of a group of radio buttons). Proper use of ARIA labels greatly benefits end-users who rely on assistive technologies to use your application.

illustration showing the various uses of ARIA labels

How to write a proper ARIA label

ARIA labels can be as short or long as you want them to be. Preferably they are descriptive and to the point. However, don't stop yourself from writing a somewhat longer ARIA label if it helps clarify a web element's function or purpose.


###3. Include focus states for all interactable web elements Some people prefer or rely on a keyboard to navigate the web application. Therefore it's important to add a proper focus state to all interactable web elements. Without it, users who lack a mouse cursor will not know where the application "thinks" their focus lies.
GIF animation showcasing how tabbing works with, and without, proper focus states

What makes a proper focus state

It should be clear at all times where the focus is located. So avoid low contrasts, drop-shadows, or other barely visible effects. The more visibly distinct the focussed interactable element is from "unfocussed" interactable elements, the better.

For more information on focus states, and how it fits in with your design system loon into the gov.uk's design system page on the topic.


###4. Have sufficient contrast levels Many UX Designers love using low contrasts with small font sizes. It can look cool from a visual perspective or hide undesirable content, but from a proper UX perspective, it equals horrendous design. After all, low contrasts make it difficult for users to see or read content, they might even miss the content.
Illustration of various contrast levels and the corresponding contrast ratios.

How to check your contrast ratios easily

It's an age-old trick, but usually squinting your eyes does the job. Is it somewhat difficult to read or see the content for you? Then probably it's either too small, has a low contrast ratio, or it's a combination of both.

If you don't trust squinting your eyes try out one of the numerous plugins available for tools such as Figma. 'Contrast' by Alex Carr does the work for you.

Alternatively, WebAIM has created a simple contrast checker. Preferably all of your web application's content has an 'AAA' rating (which is easier said than done). However, the absolute minimum should be an 'AA' rating. This means the content of your web application is readable by most end-users.


###5. Properly structure the HTML document outline In the ideal world, the document outline of a web application is coded (or generated) in semantically correct HTML. This results in a web application that is intuitive to navigate for users who rely on assistive technologies.

To help you see whether or not the document outline of a web application is semantically correct a guy named Dominykas Blyžė created a free Chrome plugin. Once it's installed you can effortlessly read the document outline of any web application as is shown below.

Example of how semantically incorrect HTML negatively affects the document outline of a web application.

A semantically incorrect document outline read by assistive technologies is the real-life equivalent of a highway sign that providers drivers with incomplete information. The document outline can be so badly written that it might even negatively impact end-users who do not rely on assistive technologies.

Example of how semantically incorrect HTML can be compared to a bad roadsign.

For an extensive deep-dive into HTML document outlines make sure to read this article by Accessibility Developer Guide.

How to write proper semantic HTML?

Coding or generating semantically correct HTML requires a thorough understanding of HTML. Therefore, seek the help of a Developer. He or she can take care of the HTML, while you put your talent to use by doing some UX Writing. Be descriptive and keep it concise. Treat your web application's document outline as a highway sign.


## Time to crank up that accessibility rating! I hope these five examples of easy accessibility quick-wins have inspired you to look into improving the accessibility rating of your own web applications.

If you still find yourself struggling to decide where to start give Google Lighthouse a try. This free tool thoroughly analyses many aspects of your web application. Within less than a minute, it will provide you with suggestions on what to improve, and (oftentimes) how to do so. Good luck!

Contact us

This article was originally written by Senior UX Designer Max Senden. If you have any questions or remarks about this article please contact us via info@vicompany.nl.

Back to top

Accept cookies?

We are actively scouting for new talent to join us and would like to remind you outside of Vi. With your consent, we place small files (also known as 'cookies') on your computer that will allow us to do that.

Find out more about cookies or .

Manage cookie preferences