Published in


Carbon v11 Accessibility

For Carbon, web accessibility isn’t just about compliance. Even if a component or experience meets an established standard, it could still be problematic for users. On the Carbon team we approach accessibility, not as an end state, but as an ongoing practice. We integrate expert guidance, user research, and state-of-the-art development techniques throughout the lifecycle of a project, from initial ideation to release — doubling back, refactoring, or reconsidering past approaches — as new techniques, research or standards become available.

Building an accessibility practice
Carbon’s accessibility has its foundation in the Web Content Accessibility Guidelines (WCAG) — a constantly evolving document that represents our industry’s current understanding of how to make the web as inclusive as possible. When new problems become apparent, solutions are proposed and either accepted or rejected. Subsequently, the WCAG document is updated with version numbers much like any piece of software. For Carbon to anticipate these changes and implement the guideline’s recommendations holistically, a cross-team collaboration of designers, developers and IBM Accessibility experts was born: The Carbon Accessibility Guild.

The guild allows us to move quickly and decisively around improvements and remediation in Carbon’s upcoming v11 release and beyond. With their help we’ve revisited and refactored two long-standing, essential components — notifications and tooltips — to provide everyone with a more accessible and usable experience.

Better actionable notifications

Two toast notifications updating the user on a server’s status

From an accessibility perspective, notification types (e.g., inline, toast) are not only differentiated by styling and usage. Under the hood, implementation details, like ARIA (Accessible Rich Internet Applications) — a technology that allows for expanded and customized accessibility — and focus management, are crucial when the user needs to carry out an action contained inside that notification, like clicking a link or pressing a button. If the action supports task completion, a keyboard or screen reader user may find it impossible to navigate to the notification, because its location in the DOM (Document Object Model) — and by extension the accessibility tree — is inconsistent. This oversight in v10 created the potential for keyboard or screen reader users to become stranded unless teams built custom app level focus management.

In the v11 release, InlineNotification and ToastNotification have been refactored and no longer support user actions. The newly introduced ActionableNotification has unique focus management and ARIA to provide a consistently accessible experience and can be configured for either a Toast or an Inline usage context.

More accessible icon tooltips

Hover or focus on an interactive component triggers any associated Tooltip

TooltipIcon has also been removed in v11. For anyone using a screen reader or keyboard, it didn’t make sense to have a tooltip inside of a non-interactive icon element. In that implementation, the tooltip would never be revealed to the users since the icon wasn’t capable of receiving focus. Instead, the recommendation — and user expectation — here, would be something closer to a disclosure pattern, in which a button triggers a dialog that rendered on top of the existing page.

An icon button beside a Tags label. When the user clicks on it it reveals a Tooltip.

To remedy this, we’ve split TooltipIcon into 2 components: Tooltip and Toggletip. Tooltip reveals a text-only tooltip when an interactive component receives hover or keyboard focus. Toggletip uses a button that reveals information when the user activates it (via click or Enter). As such, it can be used to provide text information or reveal further actions. Sighted users still have UX consistency with v10, while keyboard users have an improved and predictable experience.

Moving forward accessibly

Not described here are dozens more accessibility updates and fixes — like improved contrast for certain color tokens in certain use cases, better compatibility with Windows High Contrast mode, and expanded component accessibility documentation, to name a few. The Carbon v11 release represents a more inclusive, accessible, and usable foundation on which to build future products and services at IBM. That said, there’s still plenty of work to be done and we will always strive to deliver a more empathetic and kind experience for all of our users. Coming up we’ll have component specific deep dives highlighting v11 improvements you can take advantage of now. We can’t wait to build it with you.

Carbon is the design system for IBM software products. It is a series of individual styles, components, and guidelines used for creating unified UI.

Recommended from Medium

How to Make Docker Containers Talk to Each Other

How to Automate Google Cloud SQL Backups

Eloquent Relationships Cheat Sheet

AI Models On Silicon (Series) — Part 1

How AI Could Help Coding

READ/DOWNLOAD#) Introduction to Recursive Programm

CS373 Spring 2022: Matthew Escobar Blog #10: In Hopes for a Normal Week

Python: Why You Should Start Using Logging Instead of Print()

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
D.A. Kahn

D.A. Kahn

More from Medium

Into Design Systems Weekly — Issue #21

Testing Figma Components

Masthead image of an UI component being inspected for space padding and margins.

Float Design System

Piping Design Tokens from Figma