Preface everything here with “I think” or “In my experience,“.
The Prime Directive
The design system sweats the details so you don’t have to.
If the design system only did one thing and one thing only, it should be testing components against all the different screen reader + browser combos.
Frontend developers lament at having to test 3 different browsers. So many IE jokes. So many Safari jokes. But the combination of screen readers and browsers is staggering. As of 2024:
| Screen Reader & Browser | # of Respondents | % of Respondents |
|---|---|---|
| JAWS with Chrome | 373 | 24.7% |
| NVDA with Chrome | 323 | 21.3% |
| JAWS with Edge | 173 | 11.4% |
| NVDA with Firefox | 152 | 10.0% |
| VoiceOver with Safari | 107 | 7.0% |
| NVDA with Edge | 75 | 5.0% |
| JAWS with Firefox | 39 | 2.6% |
| VoiceOver with Chrome | 30 | 2.0% |
| Orca with Firefox | 29 | 1.9% |
| Dolphin SuperNova with Chrome | 24 | 1.6% |
| ZoomText/Fusion with Chrome | 18 | 1.2% |
| ZoomText/Fusion with Edge | 16 | 1.1% |
| Other combinations | 154 | 10.2% |
See Web AIM screen reader survey
For this reason alone, you’re already at a significant disadvantage using <YourCleverButton/> over anything open source if you’re not testing these things.
-
Right now, LLMs are notoriously bad at accessibility. It’s insanely difficult. Accessibility isn’t just a marketing term you can slap on your landing page. Adding “make it accessible” to your acceptance criteria or prompt can actually make it worse (no aria is better than bad aria). Your engineers are using AI. Support them.
-
Naming is (still) the most pointless pursuit. Give up trying to create the perfect taxonomy. Instead, invest in making it easier to change your mind. This can be automated code mods, a clear and predictable release cadence, pixel-perfect visual regression tests. (Make upgrading painless).
-
The best design system team is a group of acorn collectors.
-
Design tokens are getting dangerously close to vaporware.
-
Modern CSS/CSS4/CSS5/whatever we’re calling it now is really good. It’s also a full-time job to stay on top of everything. Did you know that we have a native
<dialog>element now? Did you know we have media queries for css custom properties (errr not-design-tokens, not-figma-variables)? Except in Firefox. Wait, you mean all that JS I wrote could have just been done with a few lines of CSS?. If only I could pay someone to keep on top of this stuff for me and bring me the best acorns. Tell me, O Design System, what’s new (that our org can support based off our user analytics)? -
This future CSS article from Volvo’s design system is still absolutely load-bearing for me and one I return to constantly.
With new additions to CSS like :where and @layer we have been able to create CSS resets and defaults that are non-intrusive and won’t override the CSS you write in an application. Instead of starting from a default stylesheet provided by different browsers you start from a default Volvo Cars stylesheet, reducing the amount of CSS you need to write for individual components.
-
Make it easy for users to flag issues, grievances, or nits. Encourage and reward them. Do not force people to fill out codepens and take screenshots (though still encourage it). Trying to adopt the same open source discipline to your design system sounds great on paper, but often just results in people not filing issues. Everyone loses. It takes an enormous amount of context switching to go from product work to filing a design system issue. The majority of people will simply hack around whatever they can to unblock their ticket and never look back.
-
Hiring is still broken and we should stop asking design engineers Big O interview bullshit.
-
Do your radio buttons have a readonly state? They probably should. See: sweating the details, accessibility is hard.
-
So is 1 rem just 16 pixels? Add this snippet to your analytics and find out.
window.getComputedStyle(document.documentElement).fontSize;