Image containing a draw with the name of the article

Why having an accessible Design System matters — and how to build one

The role of accessibility in the experience of your project

7 min readSep 9, 2019

This is part three of our series about building Bold, Bridge Lab’s design system. Access part one and part two.

Web accessibility is gaining more and more space in software development. It’s not by chance — The World Disability Report 2011 points out that one billion people worldwide live with some form of disability. It represents more than 13% of the world’s population.

In Brazil, this number is even bigger: according to the last demographic census, 45.6 million people have some form of disability — almost 24% of all brazilians. And important to notice, access to information is a right of every citizen guaranteed by the Federal Constitution of our country.

In other words, building an accessible web space isn’t just “cool”, it’s completely necessary. Actually, the Web is fundamentally designed to work for everyone, regardless of their hardware, software, language, location or capacity.

The problem is that if websites, applications, or tools are poorly designed, they create barriers that keep people from using the Web.

We want accessibility for an inclusive society, made up of individuals who see what lies ahead of disabilities: people. Understand what lies behind disabilities: lack of technology, knowledge, and attitude. Every disability has a solution waiting to be discovered. Accessibility is already there, looking at everyone and waiting to be applied
- Marco Antônio de Queiroz, blind and expert web accessibility consultant

That’s why here at Bridge, we aim to ensure access to information and provide the same experience to all users — regardless of their physical and cognitive abilities or the platform and technologies used.

B_thinking: o modelo de processo de UX do Bridge, agora para todos!

But how do we guarantee it?

The first step was to build Bold — our Design System for web applications (here we talk about why we build it). The components followed WCAG — Web Content Accessibility Guidelines — specifications, which are divided into 3 levels of compliance (A, AA and AAA).

The higher the level, the greater the impact on the look of the pages and the narrower the design. At Bold, we followed the AA compliance level recommendations.

Se now the checklist of design practices you should follow to guarantee that yours is an accessible design system.

1. Designing the Components

After reading and rereading WCAG recommendations, we were able to list the requirements necessary for the Design team to develop the graphic part of the components. Here are they:

# 1 Design a visible focus

Here we use a 2px blue border (e-MAG recommendation). Focus helps users navigate the screen and quickly understand where they are.

Range picker component focusing on the 2nd date. Focus is blue and has a 2px border, it’s clear which field is being filled

P.s .: The outline is a native CSS function, but is removed by aesthetic functions. :(

This is the link about visible focus on WCAG.

# 2 Ensure sufficient contrast

Ensure that all components have sufficient contrast between the component and the background. In general, text and images should achieve an optimal minimum contrast of 4.5: 1 (for 14px or smaller fonts).

This requirement is necessary for visually impaired people, but it also benefits users with low-resolution displays. Besides that, it ensures that content will work in different lighting conditions such as sunlight and brightness.

3 passos para sua marca ter uma identidade visual forte

Do’s & Don’ts: Example of contrast at level AA of Tag components and botton.

This is the link about contrast on WCAG.

Here are some tools that can help you build components with a good contrast:

WebAIM Contrast Checker is a contrast check site
ColorSafe generates an accessible palette according to text style and background color
Stark is a Plugin for Sketch, Figma, and XD
And here’s an WebAIM article on contrast

# 3 Don’t use (just) color as information

To convey information, indicate an action, request an answer, or distinguish a visual element, combining colors with other elements is more efficient.

For example, in the alert component, we also included icons that indicate the status of each alert.

But there are exceptions: disabled logos and elements are exempt from this standard.

This is the link about color usage on WCAG.

#4 Clear and visible links

The link should be easily identified from the rest of the text and should use clear descriptions of the actions that will take place. Do not use expressions like “click here”.

Have you noticed how explicit our links are in this article? :)

This is the link about link purpose on WCAG.

#5 Consistent Experience

Ensures that components that repeat over the interface are presented in the same order or follow the same operating pattern.

This is the link about consistent navigation on WCAG.

#6 Use an appropriate title hierarchy

In addition to providing a visual hierarchy for your content, screen reader users use the title structure to navigate the page.

Example of hierarchy, showing multiple letters in decreasing size.

When building a screen, it is also important to think about the hierarchy of information so that the reading is linear.

Imagine a screen reader in the interface you developed.
Does the order of the information make sense?

This is the link about section header on WCAG.

#7 Don’t forget the forms!

Labels should never disappear when the input gets focus.
This is the link for labels or instructions on WCAG
Indicate which fields are required using a caption.
This is the link for required fields indication on WCAG
Help users correct and avoid errors. Provide descriptive instructions, clear error messages, and suggestions for correction.
This is the link for suggested errors on WCAG

#8 Write good alternative texts

At last, the construction of alternative texts (although it’s not a step taken during the development of graphical components) is a requirement that deserves attention.

The purpose of providing alternative texts is to convey the same information and context that is received by people who can see. Be careful not to use subjective words (we separated a talk about image description to help you).

This is the link about non-text content on WCAG.

But hey, those are just a few requirements! It is important that you read WCAG and identify the requirements for your project. Marcelo Sales made a really cool post talking about who is responsible for enforcing accessibility in digital projects.

Okay, so after reading WCAG, identifying my requirements, plan all of my components, then… is all done?

Not at all! Now it’s time for you to put them in practice.

2. Implementing the Components

To exemplify this step, we will describe what we did with our own design system.

First of all, for the construction of Bold components, one of the main documentation used was W3C’s WAI-ARIA Authoring Practices 1.1.

There you can find implementation details, best practices, and design patterns to be used for building common web page components such as buttons, checkboxes and (modal) dialog boxes. Documentation includes general rules and HTML attributes that should be used in each situation.

For prototyping and validating encoded components, we use Storybook, an open-source component prototyping and documentation tool. It creates an isolated environment where the component can be individually tested and validated.

You can check out Bold’s storybook at: https://bold.bridge.ufsc.br/storybook/.

We also use the addon @storybook/addon-a11y, which checks for common accessibility issues that may have been included in the component’s HTML.

Bold’s storybook button page, showing the accessibility checks performed by the addon-a11y that have been accepted

Finally, we use React for the implementation of design system components.

Now, some extra links that may help you.

This is Web Accessibility Course, provided by Google
A11yproject.com is a database with several materials about accessibility in all sort of formats
Inclusive components is a blog fully dedicated to this subject

#Results

Bold enables affordable development by providing semantically correct components, each with their proper ARIA tag. So, they can be correctly identified by assistive technologies.

Now attention! It is important to keep in mind that the Design System is just the basis for developing affordable applications.

Using an accessible design system does not guarantee
that your design will be accessible

We recommend that you review and test your applications (preferably with real users, nothing about “us without us”, ok?) to ensure that they comply with the WCAG standards. In this link, Nathan Curtis talks about other developmental care.

Our next post will be about the accessibility tests that we conducted here at the Lab, so follow our page and activate the notifications so you don’t miss it!

This is a translates story. You can see the origina. . .

The Bridge Laboratory operates at the Technological Center of the Federal University of Santa Catarina (UFSC), with teams formed by graduate students, hired professionals and mentoring teachers. Since 2013, we have developed systems and applications in partnership with the Ministry of Health and the National Health Surveillance Agency — Anvisa.