Forge UI Accessibility Audit

Embedding Section 508 accessibility compliance into the Forge UI Design System to create an inclusive user experience for Honeywell Forge applications.

3 screen designs showing the process of auditing Forge UI
3 screen designs showing the process of auditing Forge UI
3 screen designs showing the process of auditing Forge UI

Product

Honeywell, Forge UI Design System

Project type

Accessibility

Project type

Accessibility

Platform

Web app

TL;DR

Overview

Forge UI is the official design system for Honeywell Connected Enterprises, and is used in the context of enterprise software (I.E., Asset Management) for distribution centers, buildings, and manufacturing plants.

Role

UX designer, Accessibility auditor

Tools

Figma, Miro, Storybook, WCAG

Tools

Figma, Miro, Storybook, WCAG

Completed

January 2024

Problem statement

The Forge UI design system lacked a formal accessibility evaluation, leading to usability challenges for users with disabilities. Without clear accessibility guidelines for designs or code, the UI components risked meeting Section 508 compliance—leading to limited user accessibility and potential loss of customers for Honeywell.

Goals

  • Identify accessibility gaps between Forge UI components and Section 508 guidelines (WCAG 2.1 standards)

  • Suggest recommendations and update UI components to comply with Section 508

  • Collaborate with developers to implement accessible UI components in Storybook

  • Improve documentation to establish clear accessibility guidelines for ongoing use

Implemented UI component in Storybook

The Accordion UI component uses proper ARIA patterns and code.

Research

I conducted an audit of all Forge UI components housed in Figma; this included an accessibility-focused heuristic evaluation. I also used this research to benchmark other accessible design systems, such as IBM Carbon and U.S. Web Design System (USWDS).

Approach

  • Methodology: Heuristic evaluation, competitive benchmark, and UI component testing

  • Stimuli: Forge UI components (Figma and Storybook), WCAG 2.1, IBM Carbon, USWDS

Forge UI design system's radio button component in a Figma file
Forge UI design system's radio button component in a Figma file
Forge UI design system's radio button component in a Figma file

Key findings

  1. Color contrast: Several UI components fail WCAG 2.1 color requirements

  2. Focus management: UI components do not support a "Focus" state

  3. Form patterns: Input fields do not include "Required" or "Optional" labels

  4. Keyboard accessibility: Some UI components do not abide by ARIA patterns

The "Action menu" component doesn't trap the keyboard focus in the modal once opened; the focus is sent outside the modal.

User stories

To better understand and focus on user needs, I created 3 user stories that prioritize users with disabilities that are most likely to interact with Honeywell Forge applications.

User with low-vision

  • As a screen reader user with low vision, I want form inputs to have clear labels and error messages announced so I can accurately complete forms without missing important information.

User with motor disability

  • As a keyboard-only user with a motor disability, I want to navigate through all interactive elements using my keyboard that shows a clear focus indicator so I can efficiently access all features.

User with color blindness

  • As a user with color blindness, I want clear text in addition to color-coded indicators so I can understand important information without relying solely on color.

User stories for Forge UI's accessibility audit, including screen reader and keyboard-only users
User stories for Forge UI's accessibility audit, including screen reader and keyboard-only users
User stories for Forge UI's accessibility audit, including screen reader and keyboard-only users

Solutions

Main accessibility issues found in audit

  1. Color contrast

  2. Focus management

  3. Form patterns

  4. Keyboard accessibility

  1. Color contrast

❌ Issues

  • "Status badge" includes no visible text-based label

  • "Categorical badge" uses color alone (text can be altered)

  • "Horizontal stepper" fails to meet the 3:1 color contrast requirement

Comparison between the original component with their accessible version for the Badge and Stepper components
Comparison between the original component with their accessible version for the Badge and Stepper components
Comparison between the original component with their accessible version for the Badge and Stepper components

✅ Solutions

  • "Status badge" includes a text-based label (can't be removed)

  • "Categorical badge" includes a meaningful icon and text (text can't be altered)

  • "Horizontal stepper" has a 2px white-space between steps

  1. Focus management

❌ Issues

  • All UI components lack a focus state for keyboard-only users

  • UI components with 2+ tab-stops don't include correct focus order

Comparison between the original component with their accessible version for the Button and Global header components
Comparison between the original component with their accessible version for the Button and Global header components
Comparison between the original component with their accessible version for the Button and Global header components

✅ Solutions

  • Custom focus state applied to all UI components for light and dark mode ("Button" shown)

  • Components with multiple tab-stops were given proper tab order ("Global header" shown)

  1. Form patterns

❌ Issues

  • Component variants include option to use placeholder text as a label

  • Form fields don't include "Required" or "Optional" labels

  • No guidance on "Helper text" for developers

Comparison between the original component with their accessible version for the Dropdown, text field, and radio button components
Comparison between the original component with their accessible version for the Dropdown, text field, and radio button components
Comparison between the original component with their accessible version for the Dropdown, text field, and radio button components

✅ Solutions

  • Removed component variants including a label-less option ("Dropdown" shown)

  • Added "Required" and "Optional" indicators to component labels

  • Included notes for ARIA attributes (I.E., aria-required and aria-describedby)

  1. Keyboard accessibility

❌ Issues

  • "Global navigation" component doesn't trap the keyboard focus in the modal

  • "Tree menu" component doesn't use proper ARIA keyboard patterns

✅ Solutions

  • "Global navigation" traps the focus in the modal when opened

  • "Tree menu" uses arrow keys to expand and collapse parent menu items

Results

Compliance

Optimized the Forge UI Design System to meet Section 508 requirements by remediating accessibility issues found in 25+ UI components.

Figma file showing the Forge UI component for the Contextual Menu
Figma file showing the Forge UI component for the Contextual Menu
Figma file showing the Forge UI component for the Contextual Menu

Efficiency

Streamlined the development process by adding accessibility annotations to design handoffs, performing QAs on UI components, and embedding accessibility checks in Storybook (I.E., Accessibility add-on).

Storybook for Forge UI showing the Accessibility add-on for File upload component
Storybook for Forge UI showing the Accessibility add-on for File upload component
Storybook for Forge UI showing the Accessibility add-on for File upload component

Inclusive user experience

All Forge applications who adopt Forge UI will now use Section 508 compliant UI components—enhancing the inclusivity of Honeywell software. This allows products who require Section 508 compliance to have a foundation to build their products.

Form titled "Create product content package" with multiple text fields and file uploads
Form titled "Create product content package" with multiple text fields and file uploads
Form titled "Create product content package" with multiple text fields and file uploads

Conclusion

Lessons learned

  • Remediating UI components that are already developed requires more advocacy and time versus designing and developing for accessibility first.

  • Close collaboration between designers, developers, and project managers is crucial to ensure designs are implemented properly.

  • Continuous testing with Honeywell Forge apps and feedback loops are essential to maintain accessibility compliance and maintain usability.

Next steps

  • Conduct periodic accessibility audits to ensure ongoing compliance.

  • Expand Figma and Storybook documentation with more detailed accessibility guidance and ensure UI components are properly used.

  • Provide accessibility training for Honeywell design and development teams.