Iris

Iris Accessible Design System

Iris is Alkami's Design System, a refined library of components and tools that rapidly enables designers, developers, and SDK teams to solve real problems on the Alkami Platform daily.

The design system reflects an outstanding compilation of work, representing an investment that promises enduring returns. It has empowered Alkami to expedite product development at scale while maintaining a steadfast commitment to delivering a user interface that consistently assures a superior user experience for our valued clients.

As a User Experience engineer, I acted as a subject matter expert for Web Accessibility to help identify, suggest, and develop/design components that met all ADA compliance and brought solutions for accessibility barriers.

The Design System

We understood that creating a design system featuring components aligned with the Web Content Accessibility Guidelines (WCAG) standards, to be used universally across all feature teams, would ensure platform accessibility for all users. With the backing of the product team, we gained consensus across the organization, affirming Alkami's commitment to incorporating accommodations for users of screen readers, individuals with low or impaired vision, and those with manual dexterity challenges.

The Research

Recognizing the importance of ensuring a uniform platform experience for all users, I proactively embarked on the journey of crafting the initial accessible components while self-educating on accessibility matters. This endeavor provided valuable insights into making components accessible for screen readers, keyboard navigation, and users with cognitive disabilities. I fully embraced the responsibility for accessibility, aiming to set an example for fellow user experience developers to follow.

The Theme Colors

We needed to address the issue of diverse client-specific branding theme colors on the platform, many of which lacked accessibility.
To ensure accessibility and eliminate custom design colors, we implemented an automated and dynamic color system. This system takes the base color and generates a range of lighter and darker shades, rigorously testing each one against the base color until it achieves a color contrast ratio of at least 4.5:1. If no suitable shade is found, the system evaluates whether pure white or black can be used.
If neither option meets the criteria, the base color is slightly lightened and adjusted until black can be used as the “On Color”.

The ADA Checklist

To proactively address accessibility concerns, I developed a comprehensive checklist covering design and development aspects. This checklist is a valuable resource to detect and rectify accessibility issues before the design and development phases, ensuring compliance with accessibility standards. Additionally, it aids team members in adhering to these standards throughout their respective stages of work.

The Documentation

To meet accessibility standards, integrating documentation into the component lifecycle is paramount, right from the project's inception to its completion. This entails incorporating accessibility annotations into mockups, design, and engineering documentation.These annotations serve as invaluable aids for developers, enabling them to comprehend the various interactions and states of a component. For instance, consider the Text field component, which encompasses multiple states:

Default State
This represents the component in its standard condition.
‍
Focus State
Crucial for keyboard users, it indicates the focused state of the component.
‍
Error State
This state not only conveys errors through color but also includes a warning icon and a user feedback message.
‍
Disabled State
‍In this state, the component is grayed out and non-clickable. It's important to note that the disabled state is the only instance where muted colors are permissible according to accessibility standards.
‍

In addition to this, it is essential to incorporate the appropriate HTML elements, ARIA attributes, or role attributes for the Text field component. Furthermore, thorough documentation should cover interactions with keyboard and screen readers. Consider the following examples:

Default to Focus State
When transitioning from the default to the focus state, the keyboard should focus on the text field. For users of screen readers, the correct reading order should be:
‍
1. Announce the label of the text field.
2. Announce the helper text from the text field.
3. Announce the character count.
4. Announce whether the field is required.
‍
Error State
In the error state, the error message should be announced immediately.
‍
International Text Field Interaction
For an international text field, the interaction sequence should be as follows:
‍
1. Initially, the focus should be on the international dropdown listing countries, announcing the current default selection (e.g., USA).
2. The focus should then shift to the entire text field.
3. Announce the label of the text field.
4. Announce the helper text from the text field.
5. Announce the character count.
6. Announce whether the field is required.

Documenting accessibility not only benefits fellow designers and engineers but also promotes a deeper understanding of accessibility principles. It necessitates thoughtful consideration of user interactions and is essential for smoothly onboarding new team members. Most importantly, it ensures that accessibility is an integral part of the development process rather than an afterthought.

The Training

I conducted multiple training sessions tailored to different stakeholders' needs. For product owners, the emphasis was on the importance of utilizing the component library within their teams to meet accessibility standards, ensure a consistent user experience, and mitigate potential legal risks.
‍
The training sessions for the UX team encompassed not only the significance of user experience but also practical aspects, such as utilizing Figma plugins, conducting component testing during development with keyboards and screen readers, and sharing insights on WCAG documentation and aria and role attributes. These sessions were designed to equip team members with the knowledge and tools to champion accessibility in their respective roles.

image that shows how documentation is layout on figma for a component

The Usability Testing

We reached out to several clients to assist us in identifying visually impaired users who actively engage with our platform for testing our component library. Our usability testing involved two visually impaired users, and we designed multiple tasks to assess their navigation experience. It was known that the authentication, transfers, and accounts teams were already utilizing our design system library, which led us to focus on tasks such as resetting passwords, logging into bank accounts, checking the ten most recent transactions, and transferring funds between checking and savings accounts.We requested that the users employ their preferred screen reader tools. User 1 utilized VoiceOver, while User 2 used JAWS. Despite our components not being originally tested with JAWS, we were interested in observing their interaction with it. User 2 also had NVDA installed, providing us with an opportunity to evaluate both interactions.The outcome of the session yielded valuable feedback and areas for improvement.
‍

✅ Positive

Approximately 70% of the user experience was keyboard accessible. The remaining 30% pertained to elements outside our component library on the page.
‍
VoiceOver and NVDA accurately conveyed information and provided feedback to users using our component library.
‍
Prior to using the component library, some visually impaired users had to seek assistance from their banks to perform some of these tasks. However, with the component library, they reported no longer requiring external assistance.

🛠️ To Improve

As anticipated, JAWS did not work seamlessly with our components. Although not an immediate priority, we left this as a consideration for potential future support.
‍
Certain page elements not part of our component library were inaccessible. Although these elements were outside the library's scope, we worked with the platform team to ensure their accessibility or consider adding them into the library.
‍
User 2 utilized Internet Explorer with their screen reader, encountering instances where information was not accurately announced for some of our web components.
‍
The reset password task still needed full integration with Iris components, as elements from the pre-Iris era made it impossible for the user to complete the task.

company

DELIVERABLES

role

ADa Tools

Iris Accessible Design System

The Challenge

The Design System

The Research

The ADA Tools

WCAG

Screen readers

Plugins