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.
Product
Honeywell, Forge UI Design System
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
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—limiting user accessibility and potential loss of customers for Honeywell.
Goals
Identify accessibility gaps between Forge UI components and Section 508 guidelines (WCAG 2.0 standards)
Recommend 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 QA
Stimuli: Forge UI components (Figma and Storybook), WCAG 2.1, IBM Carbon, USWDS
Key findings
Color contrast: Several UI components fail WCAG 2.1 color requirements
Focus management: UI components do not support a "Focus" state
Form patterns: Input fields do not include "Required" or "Optional" labels
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.
Solutions
Main accessibility issues found in audit
Color contrast
Focus management
Form patterns
Keyboard accessibility
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
✅ 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
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
✅ 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)
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
✅ 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)
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.
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).
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.
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.