“Accessible” Design Systems Don’t Guarantee Accessible Products

Accessibility is an Adopter’s Job Too, and They’ve Got Work To Do

Nathan Curtis
Nov 29, 2018 · 6 min read

In late 2016, I helped pitch a design system all the way up to executives that included the CEO, COO, CPO, Head of Design, and other peers. The pitch’s mood shifted when accessibility came up:

“Oh, our teams will make accessible products if they use the system? Sold!”

Some embraced accessibility in the design system’s role to optimize quality and promote inclusivity as a core value. Others heralded that the system would cut costs (by solving challenges shared by many) and mitigate risk (by reducing litigation occurrence and/or scale). Together, leadership connected good business with doing the right thing.

However, touting system accessibility can grossly distort expectations. Half a decade into their design system journey, leaders of a similar organization were confounded as accessibility across their portfolio remained incomplete.

“So, we aren’t accessible? I hear we can’t say that, even though everyone adopted the system. How’s this possible? Inclusivity is a part of our identity!”

If accessible experiences are the goal, the role of a design system and the limits of what it provides remain unclear. Beyond the accessibility-ready parts provided, there’s more work to do? If so, what? And who’s supposed to do it?

System Adopters Make an Experience Accessible. And It Takes Work.

As a result, design system programs position their kit as an enabler providing accessible components for adopting squads. Salesforce Lightning positions their toolkit as an accessible basis for another team’s development:

“The Lightning Design System provides accessible markup which will serve as a foundation for your application development.”

However, the higher up the ladder of leadership and management you go, they’ll read this and falsely perceive that with accessibility baked in to a foundation, accessibility is achieved. Mission accomplished, move on.

Not so fast. Each adopting team still has work to do to:

  1. Configure individual system components for accessibility.
  2. Compose multiple components together accessibly.
  3. Customize components from scratch accessibly, using a system’s documented foundation.

#1. Configure Individual Components for Accessibility

A design system can help by:

  • Itemizing blanks to fill, such as aria labels for popovers, lists and buttons.
  • Embedding required HTML elements and properties in scripted output.
  • Requiring and throwing errors for missing properties, such as a hidden label for a checkbox overlaid on an object that lacks a visible label.

#2. Compose Components Together Accessibly

“Need someone to appreciate how hard this is? Challenge them to experience their work through a screenreader. As it flows from one element to the next, they’ll quickly get how hard this is to do well and how much can go wrong.”
Adam Rowe, Morningstar Design System

A design system can help also by:

Nevertheless, composition reveals how preposterous it is to think a design system’s parts guarantee accessibility. There’s more than element order and attributes: orientation, audio & video timing control, input technology, the readability of words. Today’s design systems offer advice, but it’s up to each author of an experience to understand and implement the depth of WCAG’s dense standards.

#3. Customize Their Own Components Accessibly, Too

This is undoubtedly the most difficult part for teams and individuals. Often, product designer and engineers lack expertise (and access to experts) compared to the systems team. They have so many other priorities. It’s hard.

Design systems can help by:

  • Heavily infusing accessibility guidance and tools into color, form design, and other system concerns most relevant to accessibility.
  • Providing experts and/or how-to kits for conducting an accessibility audit.
  • In addition to per-component guidance, housing more general content on accessibility within design system documentation. The mission could be to provide a plainer introduction to WCAG content that many of us can admit reads as a dense, academic prose.
  • Modeling collaborative behavior, such as how they thread copywriting into all the design and dev that focuses on accessibility.

On Cost, Success, and Getting to “Good Enough?”

Ok, if the system gets us part way, how far along is that? And how much more will it cost to be good enough?

I appreciated his pragmatic attitude, pairing a recognition of system value with conceding that work remains (and the implication that it’ll force tradeoffs). That a system and adopting product share the responsibility shouldn’t be a surprise. Most have lived this reality for some time. It’s more that adopters often need a nudge — or shove — to prioritize their part.

How much more work? That’s impossible to precisely estimate. “So, are you saving each team 50% of their time dedicated to making things accessible by using your kit?” I’d hope it’s at least that much time, but I can’t say for sure.

Accessibility Belief Varies by Organization, Often Wildly

“That doesn’t matter to our of users. It’s not a priority.”

Sigh. There, we build accessibility-ready features anyway, harnessing passions of those who share our ideals without (visibly?) impacting delivery.

On the other hand, another client valued accessibility so much as to contractually require it within the master services agreement (MSA). 20% of the dense, dense document focused on accessibility.

“To work for us means that you deliver accessible solutions. Period.”

Extraordinary! Now THAT’S a declaration of commitment. We had no problem integrating accessibility into our process (it got its own step!), accessing in-house experts, and positioning its value to other teams.

So, tighten up your explicit goals for accessibility, both as a system program and an organization overall.

Is Perfect Accessibility Unrealistic? If So, What’s “Good Enough?”

Audits reveal the hidden truth: there’s so many accessibility improvements to choose from. Audits identify tens if not hundreds items to consider. It’s up to teams to prioritize what’s important and begin cranking away. In practice, at some point they reach a threshold of “good enough” before attention shifts to other features, optimizations, defects, and research.

So, in my experience at least, perfection isn’t the outcome.

Instead, like most tasks of optimization, “enough” might be 70%? (or 90%? or 98%?) of audited and/or checklist requirements to form what seems objective measurement. Once you reach that threshold, can you declare success?

This convergence on a limit hints at a mindset shift. Accessibility is best a quality pervasively pursued from discovery through design and code to testing, delivery, and optimization. It spans definitions of done across disciplines of design, content, research, engineering, and testing. Accessibility is not one box checked by one person, and a design system is central way to model and amplify that tone through it’s tools and communications.


A collection of stories, studies, and deep thinking from…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store