November 25, 2024
Volume 22, issue 5

Download PDF version of this article PDF

Design Systems Are Accessibility Delivery Vehicles

Making accessibility support for applications scalable, productive, and consistent

Shahtab Wahid

Over the years, design systems have grown to play critical roles in building software on all platforms. They offer common sets of building blocks that designers and developers can use for functionality and value to be delivered to users. Well-known examples include IBM's Carbon Design System,² Google's Material Design,⁷ and Salesforce's Lightning Design System.⁶

While there are different ways to characterize what a design system is made of, it can be boiled down to four parts:^4,5

Foundations determine visual aspects such as colors, spacing, and typography used throughout the system.
Components leverage the foundations to build out common elements such as buttons, checkboxes, input fields, and tables.
Patterns illustrate how a combination of components laid out and interacting together solve for common user interface workflows.
Guidelines provide an overarching layer for all the foundations, components, and patterns by describing what they are and how they should be used.

Design systems are infrastructure built for consumers—the designers and developers—working on applications. A successful one allows consumers in an organization to quickly scale design and development across applications, increase productivity, and establish consistency. Design systems are also products with their own user bases. They must grow, evolve, and address the needs of consumers who are building applications. If a design system becomes stagnant and fails to deliver on its promises of scalability, productivity, and consistency, then consumer adoption will decrease.

A multitude of factors, including diversity initiatives, employee productivity, regulations, and revenue implications, can drive an organization's need to provide accessible software. Many consumers, however, are not prepared to build for accessibility. In such cases, couldn't an organization make building accessibility support for applications scalable, productive, and consistent?

The central tenet of this article is that design systems are prime vehicles for delivering accessibility support to consumers. By ensuring that foundations, components, patterns, and guidelines take accessibility into account, consumers can adopt these benefits for "free" and make their own applications more accessible. The method by which the design system builds and deploys accessibility benefits greatly impacts whether accessibility can become a scalable, productive, and consistent initiative within an organization. To this end, this article dives into accessibility and its relation to two design system parts: (1) how to make design system components accessible; and (2) how to document accessibility guidelines that are tailored to consumers of a design system.

The first topic covers accessibility factors that need to be defined in all component specifications. The second focuses on strategies when creating guidelines for accessibility. Both discussions are presented with the Web Content Accessibility Guidelines (WCAG)⁹ and Accessible Rich Internet Application (ARIA) specifications¹ in mind.

Accessible Components

Design systems, particularly those tailored to the web, include a wide range of components. Common ones are form elements such as input fields, buttons, and checkboxes; and navigational components such as tabs and accordions. More complex components such as tables, toolbars, and headers may also be included. Table 1 shows the aspects that need to be defined when designing a component.

TABLE 1: Design system component specifications

Component Aspect	Description
States	All the conditions that a component can be in, such as default, hover, focused, disabled, read-only, selected/unselected, opened/closed, and error.
Layout and Structure	The arrangement of pieces such as labels, icons, and interactive elements, along with their sizing and spacing definitions.
Colors	The colors used for borders, backgrounds, text, icons, and any other element.
Typography	The text styles used for any text in the component.
Interactions	The use of keyboard, mouse, and touch events to activate the component and transition across states.
Variations	Alternative configurations of the component that may change the layout, structure and interactions by adding, removing, or rearranging elements.

WCAG and ARIA documentation describe what accessibility factors need to be included in component specifications,^1,9 along with examples.³ The factors shared here are not meant to be comprehensive but to escalate the most important issues. They apply to components on web platforms, but some will extend to other platforms as well.

Color contrast ratios

WCAG requires appropriate color contrast ratios to ensure something in the foreground can be distinguished from the background. For example, a dark gray is not as noticeable on a black background as a light gray is. This should be kept in mind when defining the colors for the border, background, text, icon, and any other part of a component in any of its states.

Font size changes

Text may need to be enlarged to support reading without any need for assistive technologies—as defined by WCAG. Browsers typically offer default font sizes that can be changed in the settings. Components need to support the ability to display the full text inside them should users choose to enlarge the font size. For example, when text in an input field or a table column header must be enlarged, this could require the size of the component to grow to accommodate the text.

Keyboard navigation

All functionality should be available through a keyboard (with exceptions such as drawing), requiring components to be keyboard accessible. ARIA practices provide examples^1,3 for keys to use. There are expectations about the behaviors of certain keys when navigating components:

Arrow keys — Move through a list of items (such as in a dropdown or menu) or through a two-dimensional space (such as the dates in a calendar).
Home and End keys — Jump to the first or last item in a list.
Space and Enter keys — Invoke an action (such as a button) or make a selection (such as a checkbox or dropdown item).
Esc key — Close (such as a dropdown) or exit a more complex component (such as a toolbar component made of multiple simpler components).
Tab key — Move focus from component to component. The Tab key should not be used to move focus within a component because the expectation is that it will move focus to the next component in accordance with the page's tab sequence.

Mouse interactions

WCAG mentions recovering from accidental or erroneous mouse clicks. Interactions triggered using a click should be invoked on mouse up, allowing a user to move away after a mouse-down event to prevent the action from being invoked. A mouse-down event should be used only for actions that do not commit, such as clicking into an input field to bring focus to type into it.

Screen-reader support

Supporting the use of assistive technologies such as screen readers is key. Components must be fully accessible through screen readers. On the web, semantic HTML achieves this goal. ARIA plays a large part in providing accessibility support when semantic HTML may not be enough. By using semantic HTML or ARIA, a screen reader should be able to do the following:

Identify the role of a component. A role, such as a button, checkbox, or table, is used to describe the type of component being accessed by a screen reader to the user. Common ARIA roles include button, checkbox, listbox, and table.
Say the label of a component. Many components such as inputs, buttons, radio buttons, and checkboxes have visible labels. In cases where a visible label does not exist or is not programmatically associated with the component, the screen reader must still be able to read out a label. ARIA provides properties such as aria-label and aria-labeledby to accomplish this.
Indicate the state of a component and any messaging associated with it. A component might have expanded/collapsed or selected/unselected states that can be described using ARIA's like aria-expanded and aria-checked. When an input field is in an error state, a screen reader should relay this and any messages describing the error.
Provide dimensional context. With a dropdown or menu, providing the total number of items available and expressing which item is currently in focus lets users understand where they are situated. For a table, ARIA can be leveraged to mention the total number of rows and columns and to which row and column a cell in focus belongs.

Documenting Accessibility Guidelines

The next part of this article focuses on how to document accessibility guidelines for the design system. Many consumers are not aware of what must be done to build accessible software. Accessibility documentation must be crafted carefully to address the needs of the audience.

WCAG is canon when it comes to accessibility documentation. The guidelines are comprehensive and will take time for a captive audience to digest. To provide some structure, they are based on four distinct principles: perceivable, operable, understandable, and robust. There is value in understanding these principles. Unfortunately, it has been shown that the principles may not be clear enough and the documentation can raise many questions.⁸ As a simpler route, some choose to visit sites with WCAG checklists to understand what the requirements are. These generic checklists do not have any connection to the design systems being used.

When in doubt, consumers may choose to use design systems with built-in accessibility support in hopes of becoming accessible. Using such a design system, however, provides a false sense of security. Accessible components provide consumers only a head start in becoming accessible. It does not mean an entire application becomes accessible. Therefore, introducing guidelines for accessibility in a design system is of vital importance. The approach to creating the documentation introduced here focuses on three steps: (1) identifying themes; (2) focusing on accessibility use cases; and (3) assigning responsibility.

Three steps to creating accessibility guidelines

The first step is to identify themes to organize all the guidance. By listening to the consumers and aligning with their needs, a set of themes, such as those shown in table 2, can be developed. The themes can be identified through workshops, conversations, and questions that consumers have among themselves; training objectives; and the breadth of issues covered by WCAG. For example, consider a developer community that is familiar with the need for keyboard navigation and screen reader support but lacks awareness of the particulars on how to provide such support. One could create themes that cover these two topics in particular.

TABLE 2: Accessibility documentation theme sets

Theme	Description
Keyboard Navigation	Keyboard usage to navigate content, enter information, and invoke actions
Screen Readers	Allowing users of screen readers to understand content structures, identify content types, listen to content, and navigate
Colors	Contrast ratios and information encoding through color
Textual Information	Labels, instructions, headings, and long blocks of text
Enlarging and Zooming	Controlling the size of content to aid viewing
Inputs and Errors	Inputs to enter information and error handling
Mouse Interactions	Invoking mouse actions and handling content that appears as a result
Nontextual Information	Images, charts, audio, and video content
Dynamic Content	Content that moves, animates, or changes automatically
Page Navigation	Navigating within and across pages
Language	Language used on the page
Workflow Design	Design of overall page or series of pages
Hardware	Phone or tablet access

The second step is to focus on the identification of use cases. Possible use cases in the keyboard navigation theme mentioned in table 2 include navigating within components, navigating across components, and skipping to the main content area of a page. These use cases account for existing WCAG recommendations. Use cases should be created until all accessibility rules in the WCAG are accounted for in at least one use case.

The third step is to carefully determine who is responsible for doing the accessibility work. The responsible party could be the design system (in which case the work may already be done), the consumer, or both. This makes the accessibility value that the design system is bringing even clearer to the consumer, while also making it apparent where the consumer must step in.

When all three steps are done, the documentation for each use case can follow a structure such as those shown in tables 3 and 4. Each use case is tied to a theme. The description of the use case is written to reflect the user's perspective, emphasizing the accessibility value. Associating the use case with the WCAG rule ensures consumers are aware of which guidelines would be satisfied. Additional background information and what should and should not be done provide extra context to consumers so they understand the why and how.

TABLE 3: navigation where design system assumes responsibility

Theme	Keyboard Navigation
Use Case	I want to use the keyboard within a component.
Responsibility	This is supported by the design system; the consumer is not responsible.
Related WCAG Rules	Rule 2.1.1: All functionality is available from a keyboard, except for tasks such as drawing. Rule 2.4.7: All page elements have visible focus indicators when focused. Rule 3.2.1: Focus changes do not trigger unexpected actions. Examples include submitting forms and opening new windows.
Background	—The design system has built-in support for keyboard navigation within components. —All components have visible focus states when using the keyboard. —None of the components invoke actions when they receive focus.
Do	Use the default keyboard navigation behaviors and focus states.
Don't	—Override the keyboard navigation behavior of a component. —Override any focus states.

A design system's intention should be to provide consumer-digestible documentation. Consumers would rather build the accessibility support than spend time understanding which guidelines apply to their products and what needs to be done. With the suggested structure in place, creating a table of contents that showcases the themes and use cases within them aids consumption. A reader can first identify a broad area of accessibility support by scanning through themes—increasing their familiarity with the breadth of accessibility considerations. Within each theme, the specific use cases illustrate the user value they can deliver. Each use case makes it apparent whether or not the reader is responsible for the work. Consumers can avoid the complexities in understanding guidelines organized by WCAG principles and generic checklists that are not related to the design system in use.

TABLE 4: Navigation where consumer assumes responsibility

Theme	Keyboard Navigation
Use Case	I want to use the keyboard to move across components.
Responsibility	The consumer is responsible for determining in what order a user would navigate through all the components.
Related WCAG Rules	Rule 1.3.2: The correct reading sequence and the order of the content in the code is the same. Rule 1.4.13: If content is to appear on mouse hover or keyboard focus, it must be dismissible, hoverable, and persistent. Rule 2.1.2: The user can use the keyboard to move through all page elements without getting trapped. Rule 2.4.3: Users can sequentially navigate (tab) through page elements in a logical order.
Background	The design system cannot determine an application's tab sequence and, therefore, cannot provide support for this.
Do	—Use the tab key to move focus to the next component and Shift+Tab to move to the previous component. —Include all interactive elements that should be able to get Tab focus. —Tab orders should start at the top of the page. —When moving focus, try to go left to right and then top to bottom. —Where possible, allow components that are grouped together or within the same area (such as a form or sidebar) to get focus one after another. —When you reach the last component of the page, the next Tab keypress should take you back to the first component.
Don't	—Jump focus to components on different parts of the page as the user can get lost. —Prevent the user from moving focus to another area of the page or limit the user to a subset of the page. —Reveal new content when a component gets focus; reveal the content only when an action is invoked.

Conclusions

The process of designing components and writing documentation as presented here is the result of a web design system initiative at Bloomberg. The initiative continues to lean on specification factors that help take accessibility into account even as the design system continues to evolve by adding and modifying components.

As mentioned, however, having accessible components is not enough. They must also be supported by guidance tailored to consumers incorporating themes, use cases, and responsibilities. Bloomberg's initiative spends time understanding the accessibility knowledge consumers have to ensure the documentation is highly consumable.

Taking steps in these directions will hopefully create an ecosystem where the accessibility needs of consumers are addressed through the design system, and product adoption increases as a result. This is the mark of accessibility support becoming scalable, productive, and consistent.

References

1. ARIA Authoring Practices Guide. W3C Web Accessibility Initiative; https://www.w3.org/WAI/ARIA/apg/.

2. Carbon Design System; https://carbondesignsystem.com/.

3. Combobox Pattern. ARIA Authoring Practices Guide. W3C Web Accessibility Initiative; https://www.w3.org/WAI/ARIA/apg/patterns/combobox/.

4. Fessenden, T. 2021. Design systems 101. NN/g; https://www.nngroup.com/articles/design-systems-101/.

5. Frost, B. 2016. Atomic Design; https://atomicdesign.bradfrost.com/table-of-contents/.

6. Lightning Design System; https://www.lightningdesignsystem.com/.

7. Material Design; https://m3.material.io/.

8. Snider, S., Scott II, W. L., Trewin, S. 2020. Accessibility information needs in the enterprise. ACM Transactions on Accessible Computing 12(4), Article 16, 1-23; https://doi.org/10.1145/3368620.

9. WCAG 2 Overview. W3C Web Accessibility Initiative; https://www.w3.org/WAI/standards-guidelines/wcag/.

Shahtab Wahid is a user experience designer at Bloomberg. He blends his design and research expertise to solve problems in the areas of desktop and web platform design, design systems, and accessibility for the financial industry. He studied Human-Computer Interaction and earned his Ph.D. from Virginia Tech's Department of Computer Science in 2011.

Originally published in Queue vol. 22, no. 5—
Comment on this article in the ACM Digital Library