Mobile accessibility tells half the story

I audited five public design systems. The one built for mobile, Material 3, hands designers accessibility as first-class properties. The web still treats the same moves as bespoke, and no system has assembled both halves in one place but mobile accessibility comes through with the first half.

A pattern I kept seeing

As part of my consulting practice, I’ve been holding office hours for a large software firm lately, in which I help the UX designers work through ambiguous accessibility questions in their specs. These designers are smart and talented and demonstrate a strong grasp of accessibility regardless of their formal training. In addition, the design system they work in has a strong accessibility foundation. Nonetheless, these designers sometimes miss a chunk of necessary accessibility markup on their web apps. Naturally, I wondered why. Then it occurred to me: web app design systems may need to take a lesson from one on a different platform. The mobile-only Material 3 for Android has provided a way to integrate a11y into its functionality, instead of treating it as bespoke.

Five systems, one rubric

The value of any design system is to provide the designer, and ultimately the end user, with a framework. A good design system will think through the visual and layout as well as define interaction patterns that will make any designed experience part of the system. A simple way of thinking about this is that a design system will make sure the font throughout the app is of the same family, the colors are clear and on brand, and key interactions such as form handling remain consistent. A great design system will do all that and also define the interaction rules for blind and low-vision people as well.

For the last few weeks, I audited how five awesome, publicly available design systems handle accessibility at the structural level:

• Adobe Spectrum,
• IBM Carbon,
• the U.S. Web Design System,
• Shopify Polaris,
• and, as a comparison, Google’s Material 3.

To keep track of how these systems handled accessibility issues, I created a rubric to apply to each: tokens, component contracts, testing, documentation, how well accessibility survives when a designer extends the system, and how much craft the system actually lets a designer express on purpose.

Filed in a separate tab

The one expressly designed for mobile, Material 3, strongly influenced this exercise. Let’s first consider that all web design systems create an excellent conformance baseline: adequate color contrast, the proper roles, keyboard support, etc. Every system I looked at mostly clears it. Unfortunately, a designer focused on creating a unique app may feel compelled to extend the design system in which they work. On the web, especially, this puts conformance at risk and may cause a lot of one-off developer coding using a supplemental accessibility language, called ARIA.

For example, the Spectrum documentation shows this gap: it files accessibility in a separate tab on every component page, sitting next to Usage, Style, and Code, as if it were a fourth concern rather than a property of the first three. This forces the designer into the mindset of something tacked on (even if it’s really not). Another system asserts on its site that it will not merge code that fails accessibility, while its public repository has no such check wired into its build at all, which forces the same mindset in the mind of the developer.

Accessibility as a property

Material 3 handles this differently, by highlighting functionality from a disability-first perspective. “Read this first” is a property that can be called through traversalIndex. “Confirm this with a haptic” is a property: performHapticFeedback, with a typed set of feedback kinds to choose from. These are integrated into the design system instead of a separate reference.

As a result, any Android engineer can name these APIs, and many have shipped with them for years. What’s surprising isn’t that they exist. It’s how rarely they enter this conversation: in the design-system accessibility writing I follow, the examples are almost always web. Another platform already solved a chunk of the same problem, on a separate track, and it barely comes up.

One gap no system has closed

The web’s version of those same two moves is uneven. There is a generic Vibration API, but it has no semantic types and doesn’t run on iOS. aria-flowto is in the ARIA spec, but screen readers don’t dependably support it, so the markup source order is the only reliable one. The audit also found that the web has things mobile does not: prefers-reduced-motion, prefers-contrast, prefers-color-scheme — clean, declarative ways to respond to what a user has already told their device they need. And therein lies a different problem, as web apps may need to ask the user in different contexts about things that are globally set on the device.

Due to this, full above-the-floor accessibility is split across two platforms, and no design system has assembled it in one place. Mobile shipped traversal order, announcement priority, and haptics. The web shipped user-preference reactivity. Each solved a different half. And this is where the designers I consult with hit the wall: what can one expect from the system in which I’m delivering? To complicate matters, some of the designers I work with are designing for mobile (so Material 3 comes into play) and others are in web apps.

I tried to keep things simple, so my rubric has a number ranking. There are four categories of above-the-floor capability. Across the four web systems I audited, each ships at most one of them as a real, reach-for-it primitive. Material ships three. This is a measurable difference in what the system hands the designer for free.

The sequential dependent loop

Most app designers have a lot to consider: a PRD, an org’s visual language, software opportunities or limitations, and a deadline. Accessibility ends up being one more thing on the pile. If a designer is interested in integrating accessibility from design inception, they usually have to take it upon themselves to read and implement the standard as a separate task. I have started calling that the sequential dependent loop, and every designer who has tried to be good about accessibility knows it on sight. Alternately, a lot of designers may be encouraged by the org to focus on accessibility in the QA phase. I used to get a lot of accessibility-based change requests after submitting my designs for build at more than one org I have worked at.

Material shows the loop is not inevitable. When “read this first” is a property you set, the designer never leaves the canvas to express it. The intent goes straight into the component. The floor takes care of itself, and the designer gets to spend their attention on creating a compelling, accessible app. Considering component variations is where a designer’s individual accessibility judgment merges with their ability to create something cool and useful. It is exactly the part the current web tooling makes hardest to reach.

What I’m looking at next

The reconsidered issue, then, is how can we build all design systems to structurally incorporate component-level accessibility rules, regardless of the delivery platform, so the application-level designer can use accessibility features as smoothly as they choose a color token? Why does the web still treat as bespoke engineering what mobile treats as a property, and what would a design system look like if it just handed designers the whole kit, both halves, in the place where they already work?

That last question is the one I am looking at in a longer piece about where accessibility should live in a design system. This mobile finding is one part of a larger survey. If it is useful to you, the full argument is in the companion essay, coming soon.