Designing tiles that are accessible
Recently, core Carbon has updated its tile component implementation and we’d like to tell you a little about the accessibility issues we encountered with the original component and our process for addressing it.
First, what is a tile?
The term ‘tile’ sometimes confuses our users — i.e. why not call it a ‘card?’ So just to level set, core Carbon ships a basic tile structure that responds to the grid. Tiles can contain type, images, components, and/or blocks of color. However, core Carbon tiles have no pre-set flows for the content inside. Tile usage guidance focuses solely on basic tile functions, not the information hierarchy within the tile, or guidance around additional interactive elements that the tile may contain.
In essence, tiles are simple and foundational, whereas cards require composition. This is why core Carbon considers the ‘card’ a pattern, instead of a component. Cards are built upon the tile foundation and have various patterns of information hierarchy, which can involve multiple actions, overflow menus and/or selectable features. Although Carbon doesn’t have a card pattern yet, we link out to several internal resources within our product community in our tile usage documentation.
Why are tiles important to the design system?
Even with a tile, you can’t escape complexity. Tiles are one of the most widely used components in the Carbon ecosystem. They form the foundation of many UI layouts across product and digital experiences, which makes them integral to our brand expression. Since tiles are almost always displayed in sets, we rely on them as a vehicle for the Carbon 2x grid — to organize information, highlight key alignments, and reduce cognitive load for the user. Simultaneously, there’s quite a variety of tile implementations across the Carbon ecosystem:
In the interactive or actionable camp, you have:
- clickable tiles
- editable tiles
- sortable tiles
- selectable tiles
- draggable tiles
- expandable tiles
In the static camp, you have:
- non-actionable tiles that contain non-actionable content
- non-actionable tiles that contain a single actionable item (e.g. a link)
- non-actionable tiles that contain multiple actionable items (e.g. buttons, menus, data visualizations, etc.)
So what’s the problem?
When we looked at all the jobs tiles need to perform, a problem space started to come into focus. Our Accessibility liaison approached us with a Github issue he created against actionable tiles. He pointed out that there was no visual cue to help users distinguish an actionable tile from a non-actionable tile.
For non-interactive tiles acting as containers, any actionable elements inside the tile have their own cues for interaction — and their own requirements to meet the 1.4.11 Non-Text Contrast requirement. Whereas, when a tile itself is actionable, it faces three challenges.
First, users can’t distinguish actionable tiles from static tiles because they have the same background styling.
Second, users can get confused with non-interactive icons that appear in such tiles. If there’s no visual cue that nothing in the tile is interactive, users may waste time trying to activate controls that do not exist.
Third, if an actionable tile contains interactive elements, users may not understand that the tile itself is a clickable zone — causing them to inadvertently trigger the main action while trying to activate a link inside the tile.
Overall, there are challenges for all users trying to discriminate between the two — but for users with disabilities, the problems of discernment and interaction become much more pronounced.
Our Accessibility expert then suggested creating a clear visual distinction between actionable and non-actionable tiles to solve this problem. Originally, he referred us to 1.4.11 Non-text Contrast, which requires that all controls, or user interface components, have 3:1 contrast against adjacent colors. In simple terms, he asked us to put a 1-pixel stroke around our interactive tiles to achieve a 3:1 contrast against the page background, cuing users to interact with them. Meanwhile, the static or non-actionable tiles would not have the stroke.
Enter design
First our designers did an audit across both IBM.com and product experiences. It’s one thing to have a list of tile behaviors, it’s another to see them in context. In the actual UI, we identified a lot of inconsistencies in tile (and card) usage, and we were able to synthesize our findings into some initial recommendations. Often, the only affordance on actionable tiles was an icon (usually, some type of arrow or chevron) and these icons were inconsistent in appearance, placement, and color across experiences.
So the problem was two-fold:
- Actionable tile layers did not meet the accessibility ratio contrast against the background, making it hard for users to distinguish between actionable and non-actionable tiles.
- The guidance for icon and CTA visual and placement on actionable tiles was inconsistent across the various Carbon Pattern Asset Libraries (PALs). Consequently, when we did try to distinguish actionable from non-actionable tiles, the effort was both confusing and insufficient.
Exploration
Given the suggestions, we tried several border values and drop shadows on tiles and evaluated them in the context of various user interfaces. We ruled out drop shadows immediately, because when the tiles are grouped with a very tight gutter (Carbon’s condensed grid mode), it’s difficult to distinguish tiles as interactive. Satisfying the 3:1 contrast ratio with the border also proved difficult in that it was too similar to the selectable tile border, which would create confusion.
Fortunately the Accessibility liaison explained that the nuance of 1.4.11 allowed designers to decide what features were “required to identify” a component. In other words, the ‘loose’ wording of 1.4.11 allows designers to use their own judgement to balance enhanced accessibility with design intent.
In the end, we chose a neutral color value for the interactive tile border that was just shy of the accessible contrast ratio. We made the final decision based on its distinctive look from other states, making these interactive tiles more accessible without being heavily emphasized and distracting from other interactions.
In addition to the border, we aligned icon position and color on clickable tiles across the system. This both resolved design inconsistencies and added extra visual affordance to the interactive tiles, since the border stroke did not quite meet the 3:1 contrast requirement.
Alignment (buy-in)
We brought our recommendations to the product-community-led Design System Adoption Guild for feedback and reactions. Although, better accessibility is an unimpeachable enhancement justification, product designers were hesitant to embrace the new tile, simply because they had a hard time anticipating how it would affect their dashboards. Despite our comprehensive audit, the dashboard design was so varied across products, even we knew that the tile update could have unintended consequences.
Although it may take some time for the product teams to adopt the new interactive tile, the Carbon for IBM.com team was eager for the update. They worked closely with us during our exploration phase and identified some inconsistencies in the current Carbon for IBM.com static and actionable card patterns. Because the Carbon for IBM.com team provides tight layout guidance and fewer card variations for the IBM.com community, they were able to quickly incorporate the new actionable tile styling into their upcoming major release.
Next steps for the product community
Due to the complexity of tiles and their extremely diverse applications in IBM Software, we keep the original tile in the Storybook and introduced the new actionable tile styling under an experimental section. This way, product teams can choose to opt into the new experimental tiles if they can afford the resources. However, our usage guidance has new updates on experimental tiles, along with the added icon guidance. Ultimately, the goal is to encourage all design teams to use the new experimental tiles in their products moving forward.
Collaborators and co-writers: Jeannie Servaas, Michael Gower, Olivia Flory.
Questions or comments about Carbon? Reach out at carbon@us.ibm.com or tweet us @_carbondesign.
