Accessibility featured image showing a man struggling to view his phone

The Correct Way to Embed Accessibility in Your Design Process

Aanchal B.'s profile pictureAanchal B.'s profile picture
Published on

No fancy introduction – 15% of the world’s population equivalent to more than 1 billion people live with some sort of disability, and we need to consciously acknowledge that accessibility need not be limited to physical infrastructure. We need to effectively design digital products that are accessible to everyone.

When the Covid-19 pandemic began in 2020, most industries turned to technology and remote working to keep going. We saw multiple groups of people suffer the blow of this sudden transition. While boomers figured how to use Zoom and share their screen, the reality of tech products was brought forth – they are inaccessible, exclusive & discriminatory – designed for able-bodied, younger generations. That needs to change.

Designing for accessibility is not an overnight process, it takes time, resources and empathy, but I can promise you it’s not difficult. What’s difficult is a visually-impaired individual figuring out what an image is about because the alt text reads “sunsets, sun sets, city, sun, orange, beautiful, cityscape, sky, city vibes, Sydney, skyline” and not, “Sydney skyline during a sunrise”.

Note: Using the alt text space to insert keywords for SEO is NOT COOL.

Did you know you could be sued if your website does not meet accessibility standards? Netflix, Domino’s Pizza & Beyoncé (yes, THE Beyoncé) have been sued for inaccessible websites, leading to massive payouts.

This piece is meant to enable us to think about who is responsible for accessibility, and what to address in all stages of our design process, from project kick-off to build.

Understanding Current Web Accessibility Standards

Let us introduce you to the holy grail for web accessibility, Web Content Accessibility Guidelines (WCAG) published by World Wide Web Consortium (W3C).

WCAG outlines requirements and considerations on how to make web content more accessible. There are different versions (1.0, 2.0, 2.1) & conformance levels (A, AA, AAA). Currently, websites must conform to a minimum of WCAG 2.1 AA. However, WCAG 2.2 is set to be published in June 2022.

Latest: A Working Draft of WCAG 3.0 has been recently published.

The goal of WCAG is to have one single shared standard that everyone can meet for web content accessibility. If we all strive to follow these guidelines, we are all making a contribution to making accessible design “the norm”, not a “nice-to-have”.

Applying Accessibility in the Design Process

Gantt chart explaining responsibility of OMs, Designers & Developers to apply accessibility in the design process

Having browsed on how to design for accessibility, it was found that there are 100s of pages full of tips and do’s & don’ts but no particular information on when it is the right time to incorporate them in the design process and the consequences for not considering or addressing it at the right time in the process.

Here are some tasks and considerations you can take on in the design process.

1. Project Kick-Off

At every project kick-off meeting, ensure that it’s a non-negotiable requirement in the brief. Do you know that saying “pick your battles”? Well, this is your battle to fight! Setting an expectation right from the start with your client and/or stakeholders will justify and explain why you’re spending time on making your designs accessible. Laying the groundwork for accessible design is far easier than struggling at the end… or even worse, getting sued for an inaccessible product.

2. Design System

A design system provides an opportunity for both designers and developers to incorporate accessibility and inclusivity principles in the designs from square one.

However, not everyone has the luxury to build out a design system that is completely accessible. It requires a lot of time and effort from both designers and developers to design and build a single component, let alone a whole design system (but we’ll leave this for another blog post).

If time is not your friend, a great place to start is addressing inclusivity and accessibility using WCAG guidelines in your design foundations.

With more than 2.2 billion living with some type of visual impairment, designers can ensure web content is readable by establishing accessible design foundations, such as typography and colour, from square one. This is quite pivotal as these design foundations will influence the design of your components and overall web experience moving forward, rather than trying to incorporate accessibility guidelines at the end of a project.

Here are a few design tips to use in your next project, or as an accessibility checklist for current or old projects. 👀 (We’re definitely going through some changes on the Raw.Studio website too!)

Typography

  1. A font size of at least 16px, ideally 20px for body text.
  2. Use bold and UPPERCASE when the text needs to be small.
  3. Use fonts that have good x-height, especially body text.
X height Do 1 - Raw.Studio
Do use a font with an x-height that is legible. This is subjective for each use case but use your best judgement based on its context.
X height Don t - Raw.Studio
Avoid using fonts with low x-height, especially for body content, as it makes it more difficult to read.

Reading Experience

  1. WCAG recommends using a line-height of 1.5x of the font size. However, this varies from font to font, so use your best judgement. At Raw.Studio, we use 1.1x-1.3x for headings & 1.3x-1.5x for body.
Line Height Do - Raw.Studio
Do use recommended line-height for body content for a good reading experience.
Line Height Dont 1 - Raw.Studio
Having too little space between lines can result in readers having difficulty reading, losing their place and/or skipping a line.
Line Height Dont 2 - Raw.Studio
Having too much space between lines does not provide a good reading experience, and may result in a broken reading rhythm.
  1. Use no longer than 80 characters in a line of text. We recommend 50-60 characters.
  1. Avoid using centred text alignment for large content. Instead, use left text alignment.
Reading Experience Do - Raw.Studio
Do use less than 80 characters in a line of text and left-align the paragraph of text for the optimal reading experience.
Reading Experience Don t 1 - Raw.Studio
Don’t use more than 80 characters in a line and centre align large bodies of text. This results in readers having difficulty keeping track of their place and spending extra time finding where the next line begins.
Reading Experience Dont 2 - Raw.Studio
Don’t use short lines of text. This results in a broken reading experience.


Colour Contrast

  1. Don’t use colour combos that affect those with colour blindness.
Colour Blindness 1 - Raw.Studio
  1. Meet a minimum of Level AA with a contrast of 4.5:1 (foreground:background) for best visibility. Stark is a great Figma plugin to do quick colour contrast checks.
Colour Contrast Check 1 - Raw.Studio
  1. Don’t rely on colour to distinguish interactivity, states or communicate messages. Instead, use multiple signals such as text treatment, border treatment or iconography.
Colour Do 1 - Raw.Studio
Do use multiple signifiers. In this case, the text link uses underline as an additional element on top of colour to signify interactivity.
Colour Don t - Raw.Studio
Don’t rely on colour as a signifier. This example presents a text link using only colour to signify interactivity.

Iconography

  1. Always use supporting text with decorative icons to communicate a clear message.
Decorative Icons Do 1 - Raw.Studio
Do use supporting text with decorative icons.
Decorative Icons Don t - Raw.Studio
Don’t use decorative icons alone. This is not accessible and does not clearly communicate what it is.
  1. We recommend using action-based icons for interactive elements, specifically buttons.
Action based icons Do 1 - Raw.Studio
Do use action-based icons for interactive elements.
Action based icons Don t - Raw.Studio
Avoid using decorative icons in interactive elements, specifically buttons. This can add unnecessary visual clutter and does not add any functional value.

Decorative Elements or Images

Any element or image used for decorative purposes do not need to fulfil colour contrast requirements but make sure to use relevant alt text. If no alt text is required, make sure to keep the alt attribute but leave it empty. When a screen reader comes across an empty alt text, it will completely skip over the image without announcing its presence. If you don’t have an alt attribute, the screen reader will read the file name.

Decorative Elements - Raw.Studio
Decorative Elements Do 1 - Raw.Studio
Do use an empty image alt tag.
Decorative Elements Don t - Raw.Studio
Don’t leave out the alt tag attribute.

Interactive elements such as buttons

Allow for an adequate touch zone. WCAG states a minimum of 44px by 44px.

Touch Zone Do 1 1 - Raw.Studio
Touch Zone Do 2 1 - Raw.Studio

3. Design

Although the context for each digital experience may differ, if you’ve addressed accessibility in the previous stage, this design stage should be a breeze (hopefully)! It becomes easier and won’t seem like an ‘extra’ task you need to check off the list. All you’ll need to do is apply the accessible design foundations!

But of course, no surprise here, there is a new layer of accessibility that you would need to consider in this stage. Designers need to ensure that what they’re proposing, whether it’s design components or user flows, can be built for accessibility through regular collaborative sessions with developers. This will help developers understand what designers want to achieve so that they can provide accessible solutions or suggestions.

Designing building for accessibility is a shared responsibility - Raw.Studio
Designing & building for accessibility is a shared responsibility amongst designers, developers & product managers

4. Build

In an ideal world, all front-end developers follow good code & accessible practices when building designs. This is another great time for developers to reference the resources provided by the W3C. However, developers do not need to bear all of the responsibility in ensuring the experience is accessible in the build stage. In fact, it can be shared with the designers too.

A UI/UX designer could address all the design accessibility requirements in the design stage but if a developer does not integrate good code & accessibility practices, it becomes redundant.

How a designer can assist is through build review(s). A build review typically involves making sure the designs are pixel perfect in build, however, designers can take it up a notch and learn to inspect the code to ensure good code & accessibility practices have been implemented. This is why it’s a big bonus that a UI/UX designer understands the basics of HTML/CSS. Authoring & evaluation tools, such as HTML & CSS validators, can also be used to assist in accessibility checks.

Here are a few actionable tasks that both developers and designers can do to ensure you’re set up for accessible success:

  1. Use legitimate header tags. ScreenReaders use header tags (H1, H2, H3, H4…) to provide a sense of hierarchy to the user. Hence, make sure you correctly attach the tags and don’t skip any.
    Remember: One page usually only has one H1 tag. 💡  (RE: designer<>developer communication)
  2. Build accessible forms. This means labels and important information should always be visible in form fields. There have been trending aesthetics used for form fields where the label is placed within the field, however, this is essentially killing accessibility. Screen readers won’t be able to pick it up. You can definitely try to build it in an accessible way, but you’re spending time and effort on something unnecessarily complex for the sake of a ‘pretty’ design. You’ve got 99 problems but this ain’t the one!
Accessible Form Fields Do 1 - Raw.Studio
Do display labels and other important text (such as help text) outside its relative form field.
Accessible Form Fields Don t - Raw.Studio
Avoid having field labels sit inside the field. This adds unnecessary complexity to build and if not built right, screen readers will not be able to pick it up.
Accessible Form Fields Don t 2 - Raw.Studio
Do not display important information (such as help text) in a temporary manner. Instead, find a placement where it is always present so that users can reference it at any point in time.
  1. Use ARIA labels for every form field. We like to call them invisible labels. It is important to use the ARIA label especially when a form field label is not visible on the screen so that screen readers can pick it up and inform the users. For example, use “Edit”, not “Pencil” as the ARIA label for a pencil icon denoting the ability to edit.

    Remember: When using ARIA labels, describe the function, not the vector. Example: Say “Edit”, not “Pencil” for a pencil icon denoting the ability to edit.
ARIA Label Example 1 - Raw.Studio
ARIA Label Do 2 - Raw.Studio
Do describe the function of the icon in the ARIA label.
ARIA Label Don t - Raw.Studio
Don’t describe the subject of the icon in the ARIA label.

5. Delivery

After build reviews are successfully completed and verified by the designers & the developers, the finished product is reviewed by the product manager for final approval.

Although accessibility has been part of the conversation throughout, it is at this stage where a thorough, critical review needs to be conducted to ensure that the accessibility requirements are fulfilled. If the product meets all the criteria, you’re good to go!

💡 Pro tip: Test the full product with only the keyboard or a screen reader to empathetically secure accessibility features.

Conclusion

We must acknowledge that there’s not one single person that is responsible for delivering an accessible experience. It is a shared responsibility between product managers, designers and developers, some more than the other, depending on the stage of the design process.

However, designers have the power to create designs that can be experienced by everyone, regardless of ability, and ensure good practices are implemented throughout the design process. As we move towards Web 3.0, a decentralised internet by the people, for the people, it’s now important to design for accessibility, for everyone.

  • Conduct an accessibility review for your existing products.
  • Review W3C guidelines.
  • Empathy is your best friend.

Let’s make 2022 the year we strive for inclusive, non-discriminatory design.

We’re going to leave you with one thought, “Designers don’t design for designers.”

Need some help? We’re here for you. Sign up for a FREE 30-min Strategy Session with Raw.Studio