esign is powerful. We chat with our friends and loved ones halfway across the globe, we can check on our pets while at work, and sync as a team in a pandemic. And design systems let us scale those experiences seamlessly to any device or touchpoint.
But who is your design system excluding from the conversation? If you haven’t considered accessibility as part of your design system’s core drivers, you may be excluding the world’s largest minority group, the one billion people globally who experience a disability.
“…15% of the world’s population, 1 billion people, live with disabilities. They are the world’s largest minority.”
– United Nations
Yes, design is powerful. But power isn’t enough. Make it good.
A11y? What’s that?
Accessibility (also shortened sometimes to a11y) is design that works for all people, whatever their hardware, software, language, location, or ability. While people with permanent disabilities are most often thought of as the target audience for accessible design it really is about providing an equivalent experience for all. And in most countries, it’s the law.
Disabilities range from visual, auditory, cognitive to motor specific. And while many people live with permanent disabilities, some impairments can be temporary, sporadic, or even situational in nature.
As a father of children with dyslexia, friends with parents who have children on the spectrum, and a friend losing their sight, I care deeply about providing the brightest future for the next generation. As such, it’s been the honor of my career to work on Pega’s Cosmos design system. As the first enterprise case management design system, Pega Cosmos is prioritizing accessibility — and it’s poised to make a difference for enterprise workers and customers everywhere.
Nothing for us, without us
Like many, there may be a good chance you’ve heard about accessibility but have no idea where to start. And that’s OK. Wherever you are in your journey, we’re glad you’re here.
It may sound obvious, but start with people!
One of the easiest things you can do is watch some of the accessibility perspective videos that the W3C has put together to understand how people experience day-to-day life.
- Understanding keyboard compatibility challenges
- The need for larger links, buttons, and controls
- The necessity of proper color contrast
- Why clear and expected layouts are critical
Better yet, consider partnering with a local disability education group or a third-party accessibility verification and service provider. Or hire people who have “lived experience” with a disability and assistive technology to be part of the day-to-day conversations of the team and design system.
Designing with semantics and standards
When scoping out the Cosmos Design System, one of my first steps was to ask myself, “How do we get the most inclusive experience to market as quickly as possible?”
The answers were available to us for free: standards, guidelines, and all the adopted laws were available online for anyone to explore.
HTML & CSS semantics gave us the baseline types of inputs and elements we had access to, the interaction states for which we needed to design, and the accessible roles and meanings that would be shared to assistive technology (AT).
When we had a question about how a certain component should interact with the keyboard, we turned to WAI-ARIA Authoring Practices. And when we were looking at the constraints or use cases we needed to meet when designing a certain type of component, we looked to the legal and internationally accepted WCAG 2.1 AA, or the less well-known ATAG.
This, in turn, informed the guidelines that we took creating Pega Cosmos, and that we are beginning to give to our designers and designers at client organizations:
- People-first: People take priority over the design system preference. All sizing should scale exclusively on the user’s default text-size preferences. All design system spacing documentation is written in REM multipliers (1x = .5rem, etc.). We are also exploring dark-mode, motion preferences, and more. Additionally, some things are not part of the standards — that through testing, we’ve discovered are common preferences of those using assistive technology.
- Naming: When possible, all components are named after the semantic tag or ARIA role. That means that a button is called a Button, a modal is called a Modal dialog (because both terms are used), and what some designers call an auto-complete or type ahead is called a Combo Box.
- Color: Colors used must be tested for both contrast issues and color-blindness. Color also has meaning when used, but color alone is never used to indicate that meaning. Also, just because a color is in the design system, pairing them without consideration for contrast doesn’t mean it’s accessible. And when it eventually comes to dark mode, it also means avoiding true black for the primary background color.
- Labels: Label everything in a design. This means providing programmatic labels for visual indicators in grouped assets, implied meaning due to layout, images, or hidden labels on icon-only buttons. Additionally, help instructions or errors must be clear in the resolution of the issue and not use solely visual information (e.g. Not “Click the red trash can button to the left” but “Press delete”). Icon-only buttons must be able to display labels on hover and focus, so users navigating by speech alone can learn the names of those assets for future use. Make sure components plan to provide space for long localized text and find ways to reduce the need to translate language-specific phrases (e.g. Instead of “My tasks” and “Jim’s tasks”, use “Tasks: Mine” and “Tasks: Jim”).
- Layout: Responsivity is not just for mobile phones — WCAG states we need to support a design in portrait or landscape mode, and up to 200% zoom. Make sure one line of text never expands beyond 80 characters in Roman-based languages or 40 characters in CJK languages.
- Interaction: Whenever possible, use a default HTML element or fall back to ARIA recommendations. When it comes to any other types of potentially exclusive interactions (right-click, press and hold, shake, speak) always document an alternative way to access those actions. Additionally, whenever possible, avoid timed interactions unless there’s an easy way to re-access that information.
Auto-correct, but for accessibility
One of the great things about the Pega Cosmos design system is its branding flexibility: it can be easily rebranded in a low-code way for any customer, partner, or client. That means Pega Cosmos will feel right at home within a brand’s ecosystem.
Early on, in talks with the developers at Pega, we agreed they would work accessibility linting into their dev pipeline. Even if a designer made a color contrast mistake or missed a step, developers would automatically flag that issue and we could resolve it. (I’d like to say I’ve never needed that, but that would be a lie!)
Additionally, the development team created a way to use design tokens, technology-agnostic style variables, that automatically change the contrast of text based on the background color of the element that text is resting on.
And finally, when an external author uses the low-code interface to brand the design system in an inaccessible way, the color pair is flagged to let them know there is an issue. We also ask to confirm each time inaccessible work is saved, so we can encourage the author to do the right thing over time.
We’ve only just begun
Pega Cosmos React is just launching version 1.0, and we are so excited to bring this new powerful, good, and accessible design system to serve in global workforces everywhere.
I couldn’t be prouder of Pega’s renewed commitment to accessibility, inclusion, and design, and in the team members, designers, managers, and developers that are making it happen.
There is still so much more to do, explore, design, code, craft, and learn. But that’s great — because accessibility is a journey we get to take together, for the good of design.
If you’d like to learn more, visit https://design.pega.com