How to Create an Accessible Design System in 60 Days
Accessibility was the backbone of ETS’s 2024 rebrand and website refresh. Code and Theory Lead Experience Designer of Accessibility & Design Systems Mike Mai shares how it all came together.
Just 4% of the internet is accessible to individuals with disabilities. It’s not enough today to create digital experiences that look beautiful if they’re not accessible. The Code and Theory approach to designing and building holistic digital experiences ensures accessibility is considered and infused in the experience from the foundation of every project we tackle. Our latest launch with ETS — a complete rebrand, anchored by a website rebuild and redesign for the nation’s most reputable education and research institution — demonstrated how to develop an accessible experience at speed and scale.
Rebranding is a big task; the average time from start to launch is about 12 to 18 months, but sometimes clients need to move fast. Really fast. In the case of ETS, they needed to reveal their new branding on their website within two months of development time. Keeping its core diversity and inclusion values in mind, having an accessible website was a huge priority for the brand.
To help ETS achieve its key business and brand goals, we built an accessible and engineered design system to ensure speed, reliability and quality. We also integrated modern CSS to make everything in the system flexible and scalable. Read on to learn how we stayed true to ETS’s brand mission digitally by engineering a design system with accessibility baked in from the start.
Architect a token system
To maximize the efficiency of a team of four front-end developers, we established a well-defined token naming convention to translate the visual design into code. Developers should be able to inspect the design file and figure out the specific design tokens to apply for color, spacing and typography. Design tokens are design decisions that get translated into data. For example, cyan is the ETS’s primary action color — so “primary” is the token. Design tokens are represented in Figma through Variables and Styles. Figma Dev Mode enables developers to see the token usage in every component, which saves us countless hours and makes for clear communication across teams.
Theming
The first step to defining design tokens is defining all the themes used in the designs. Theming is critical in building accessible user interfaces because it defines the relationship between colors. No single color is considered accessible. Only when you pair up colors and evaluate the contrast ratio between two colors can it be considered accessible.
Theming also handles typography and spacing. ETS’s new branding defines a font for corporate branding and another font for individual product branding. Each font has its own unique traits, therefore, spacing has to adapt and change accordingly.
We went through all of ETS’ page template designs and narrowed them down to the following six themes:
- ETS xlight: white background, brand ink color text
- ETS light: brand eggshell color background, brand ink color text
- ETS dark: brand midnight color background, brand eggshell color text
- ETS xlight: brand ink color background, brand eggshell color text
- TOEFL xlight: white background, black text (plus different fonts and spacing)
- TOEFL xdark: black background, white text (plus different fonts and spacing)
Colors
After defining the themes, we reviewed designs and started to name each color with a purpose. As mentioned earlier, the contrast between the two colors is what makes it accessible. By giving each color a semantic name instead of primitive names like red, white, and blue, we are setting up pairings of color tokens that would be intuitive to apply to components. All pairings are tested for Web Content Accessibility Guidelines (WCAG) Level AAA color contrast requirements, which was mandated by ETS, based on user testing they completed.
The defined relationship and built-in accessibility allowed developers to code with speed and ease.
- Primary: High-emphasis fills, texts and icons against surface.
- On Primary: Text and icons against primary.
- Surface: Default color for overall page background.
- Surface Container: Module and card background.
- On Surface: Text and icons against any surface color.
- Error: Attention-grabbing color against surface for fills, icons, and text, indicating urgency.
- On Error: Text and icons against error.
- Outline: Important boundaries, such as a text field outline.
- Outline Variant: Decorative elements, such as dividers.
- Outline Dim: Also decorative elements but even more de-emphasized.
- Outline Highlight: Also decorative elements but takes on a vibrant brand color, used sparingly.
- Scrim: Overlay that obscures page content.
- Overlay: Overlay that obscures module content, allowing text to be placed on top of a video or image.
Internally, we have a few different naming conventions for semantic color tokens. The one we used here is similar to how Google Material Design names colors, which benefits ETS because its lightweight nature resulted in a lean codebase.
Typography
Typography utilizes the standard practice of naming each style based on purpose and separating styles from HTML semantics, which means none of the text styles are named H1 to H6. Instead, we named them based on how they are used. We suggest this direction because it allows for flexibility in handling both accessibility and SEO. Just because a piece of text is large in size, it doesn’t mean it should be the H1 of the page. We applied the following convention when naming ETS’ text styles:
- Heading-[size]
- Text-[size]
- Eyebrow-[size]
We also used fluid typography to ensure font size can grow with screen size and is compatible with browser and/or device font size settings. This ensured text was readable across all devices:
- Base font size is defined with a % value
- CSS clamp is used for certain headings to define a min and max size
ETS aimed for WCAG Level AA and our approach took care of Success Criterion 1.4.4 Resize Text, which stated: “Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.”
Spacing
For spacing, a 4-pixel grid (or 8-pixel grid) was used. This is a common baseline grid that designers utilize to create consistent spacing and vertical rhythm.
- Spacing-4: 4px (design) / 0.25rem (code)
- Spacing-8: 8px (design) / 0.5rem (code)
- Spacing-12: 12px (design) / 0.75rem (code)
- Spacing-16: 16px (design) / 1rem (code)
- Spacing-20: 20px (design) / 1.25rem (code)
- Spacing-24: 24px (design) / 1.5rem (code)
- Spacing-28: 28px (design) / 1.75rem (code)
- Spacing-32: 32px (design) / 2rem (code)
- Spacing-40: 4px (design) / 2.5rem (code)
- Spacing-48: 48px (design) / 3rem (code)
- Spacing-56: 56px (design) / 3.5rem (code)
- Spacing-64: 64px (design) / 4rem (code)
- Spacing-72: 72px (design) / 4.5rem (code)
- Spacing-80: 80px (design) / 5rem (code)
- Spacing-96: 96px (design) / 6rem (code)
- Spacing-120: 120px (design) / 7.5rem (code)
The number generally means the approximate pixel value; for example, spacing-48 is approximately 48px. When converting them to code, one added benefit is that the absolute values became relative values with the rem unit. This allows the spacing to grow with the base font size. This helped the ETS landing page layouts to transform more smoothly across different screen sizes and eliminate the chance of failing WCAG Success Criterion 1.4.10 Reflow (Level AA).
Design tokens in action
With a good foundation setup, we started building out components at an incredible speed. Let’s look at how we style components using the design tokens.
.component {
@include heading-ets-2xlarge-regular;
margin: var(--spacing-4);
padding: var(--spacing-16);
color: var(--color-on-surface);
background-color: var(--color-surface);
border-block-start: var(--color-outline);
}As you can see in this example code block, no value is hardcoded. Every line of CSS is declared with either a CSS custom property (design token) or a SCSS mixin (a group of design tokens) for something more complex. The raw values are never used in component CSS. This allows for something to be built once and automagically rendered in 6 different themes. Each design token is defined as a specific value in each theme using a data attribute selector: data-theme.
Here’s a simple view of the surface and on-surface design token definitions for the ets-light and ets-dark themes. These are defined globally and do not belong to any particular components:
[data-theme="ets-light"] {
--color-surface: var(--brand-eggshell);
--color-on-surface: var(--brand-ink);
}
[data-theme="ets-dark"] {
--color-surface: var(--brand-midnight);
--color-on-surface: var(--brand-eggshell);
}This method of theming is infinitely scalable because every time a new theme is needed, we just define the design tokens with new values and scope them to a particular data theme attribute. We likely won’t have to touch the CSS of any existing components.
Style with logical CSS
Styling with logical CSS ensures future-proofing, which aligns with our approach to localization and accessibility, and is proactive rather than reactive. Given ETS is an international brand and its websites are already available in nine different languages, we applied logical CSS properties everywhere, making absolute terms like “top, right, bottom, left, width, and height” not necessary to use in the CSS.
Why is logical CSS important for accessibility? Let’s take a closer look. The following is an absolute way of defining text alignment:
.component {
text-align: left;
}The problem with the “left” value here is that the text will always be left-aligned, even if the content is in Arabic and the reading direction is right to left. Forcing left alignment on content that is supposed to be read right to left will make it much harder to read.
Instead, logical CSS should be defined in this scenario:
.component {
text-align: start;
}The “start” value here means the starting direction of the current web page. If the web page is in English, then “start” means “left” because English reads left to right; if the web page is in Arabic, then “start” means “right” because Arabic reads right to left.
Set up accessibility features for special components
Something often overlooked while coding out a design is ensuring all interactive controls and essential content have accessible names. We focused on correctly using the aria-label attribute, aria-hidden attribute and the CSS visually hidden technique throughout certain components. This allows all ETS visitors equal access to essential information even in complex user interfaces.
Icon-only CTAs
No visual text is rendered when we use icons for calls to action (CTAs). In this case, we applied the aria-label directly to the interactive element and ensured screen reader users could also read the CTA.
<button type="button" aria-label="Close dialog">
<svg>...</svg>
</button>Uncommon characters
Just like any software, screen readers are not perfect. Sometimes they don’t properly pronounce words or abbreviations that are not commonly used in writing, like “40M+” might not get announced as “more than 40 million.” In these cases, we used a technique that combines aria-hidden and visually hidden text. By doing so, we maintained the visual brevity of the design while providing non-sighted screen reader users with proper phrasing.
<span aria-hidden="true">
40M+ TOEFL takers and counting!
</span>
<span class="visuallyhidden">
More than 40 million TOEFL takers and counting!
</span>Read about the CSS visually hidden technique.
Animations and transitions
Certain components come with subtle animations and/or transitions that would give the ETS website a modern flare, however, motion can cause severe sickness to some people. We took that into consideration when designing with motion, building components to be compatible with device-specific reduced motion mode or animation off mode.
We used the prefers-reduced-motion CSS media query to detect whether a user has reduced motion enabled on their device and declared the styles accordingly.
.component {
// Static styles go here.
}
@media (prefers-reduced-motion: no-preference) {
.component {
// Animated styles go here.
}
}Integrate the design system with the CMS
We believe a component is not considered “done” until it is integrated with the CMS. Integration was the final step in delivering an engineered design system to ETS. After building out all of the necessary front-end components, we moved quickly into integrating with Adobe Experience Manager, and we made sure that ETS content authors also got the same great features that are available in code for ETS engineers.
An inclusive new experience
The ETS rebrand and website refresh was launched in April 2024 with an accessibility score of 100 in Lighthouse — Google’s automated tool for measuring the quality of web pages. It was the result of a partnership and commitment to excellence in design and code, delivering on ETS’ brand promise across diversity, equity, inclusion and belonging.
Get in touch to discuss how Code and Theory can help make your next experience more accessible.
Mike Mai is a Lead Experience Designer, Accessibility & Design Systems at Code and Theory.
