Accessibility Assistant for Klaviyo Forms
Accessibility Assistant for Klaviyo Forms
Bringing industry leading accessibility tools to a flagship Klaviyo product.
Bringing industry leading accessibility tools to a flagship Klaviyo product.
Overview
Hundreds of thousands of sites throughout the world use Klaviyo sign-up forms to gather information from their visitors, with over 2 million forms published in the last year in aggregate. With the immense reach of our product we recognize a duty to Klaviyo users to ensure each of their end users experiences the web in an inclusive, accessible way.
When we discovered many Klaviyo forms were not meeting accessibility standards, we took action to build a solution that would help those without familiarity with such standards to learn and resolve common issues with ease. From the research we conducted we can say with confidence that no other marketing tool on the market has built a tool that is far-reaching and user-friendly to meet this specific need.
Without sacrificing the flexibility of our builder or introducing barriers that would negatively impact top-level metrics like publish rates and NPS scores, the Accessibility Assistant was developed. Using a warning system of actionable cards to ensure our users are alerted of potential issues and can resolve them quickly.
I was the sole designer on this project, working with a product manager, one software engineer, and a user researcher to execute the vision. Development took approximately 2 months and the tool launched to Klaviyo users in May 2023.
Overview
Hundreds of thousands of sites throughout the world use Klaviyo sign-up forms to gather information from their visitors, with over 2 million forms published in the last year in aggregate. With the immense reach of our product we recognize a duty to Klaviyo users to ensure each of their end users experiences the web in an inclusive, accessible way.
When we discovered many Klaviyo forms were not meeting accessibility standards, we took action to build a solution that would help those without familiarity with such standards to learn and resolve common issues with ease. From the research we conducted we can say with confidence that no other marketing tool on the market has built a tool that is far-reaching and user-friendly to meet this specific need.
Without sacrificing the flexibility of our builder or introducing barriers that would negatively impact top-level metrics like publish rates and NPS scores, the Accessibility Assistant was developed. Using a warning system of actionable cards to ensure our users are alerted of potential issues and can resolve them quickly.
I was the sole designer on this project, working with a product manager, one software engineer, and a user researcher to execute the vision. Development took approximately 2 months and the tool launched to Klaviyo users in May 2023.
Final screens
The interactions below outline the core functionality for the Accessibility Assistant. The alerts, generated as the user works to build their form, appear in a centralized sidebar where they can manage and resolve issues without leaving the sidebar.
Final screens
The interactions below outline the core functionality for the Accessibility Assistant. The alerts, generated as the user works to build their form, appear in a centralized sidebar where they can manage and resolve issues without leaving the sidebar.
Adding descriptive text to an image block
Addressing an alert for missing alt text on an image in their form, with the title and description providing them with direction.
Adding a label to an input field
A user adding an input label for a field on their form, previously using only inaccessible placeholder text.
Increasing the size of the button
User adjusting the height of the primary button to meet mnimum touch target standards.
Improving color contrast of a button
Setting a darker color for the primary button to meet WCAG AA standard for color contrast.
Adding descriptive text to an image block
Addressing an alert for missing alt text on an image in their form, with the title and description providing them with direction.
Adding a label to an input field
A user adding an input label for a field on their form, previously using only inaccessible placeholder text.
Increasing the size of the button
User adjusting the height of the primary button to meet mnimum touch target standards.
Improving color contrast of a button
Setting a darker color for the primary button to meet WCAG AA standard for color contrast.
Card anatomy
Anatomy of the action card. As the building block of the experience, each of our action cards needed to follow a predictable and actionable structure. Working closely with content design partners, we developed and validated a format that was instructive, educational, and actionable.
Card anatomy
Anatomy of the action card. As the building block of the experience, each of our action cards needed to follow a predictable and actionable structure. Working closely with content design partners, we developed and validated a format that was instructive, educational, and actionable.
Card catalog
Examples of the action cards available to users to address accessibility issues in their forms. While the most effective path was to allow resolution within the cards, in cases where that wasn't possible we directed users to the appropriate area in the builder with a simple CTA.
Card catalog
Examples of the action cards available to users to address accessibility issues in their forms. While the most effective path was to allow resolution within the cards, in cases where that wasn't possible we directed users to the appropriate area in the builder with a simple CTA.
Design process
Understanding the user and problems
The discovery phase began with a third-party audit that flagged a number of potential issues in our form product. Not only was this an issue from a values perspective, inaccessible forms expose users to legal risk and can result in fines or lawsuits. From this audit, we were able to break issues that could be resolved on the engineering side and worked to resolve those behind the scenes while a solution for the user-facing issues could be determined.
In an ideal world designing sign-up forms should be able to publish accessible forms without additional work. However, the freedom of a visual builder means problems are inevitable. User action was needed to resolve a number of issues as they are creating, for example: alt-text, color contrast, touch target size, and input field labels. Given most users were unfamiliar with accessibility, one major problem was combining education with new behavior, helping users understand the value of accessibility so it's not just another error or warning to dismiss.
While we have error and warning patterns in our design system, none quite fit the approach we were looking for as far as errors that were instructive and actionable. This necessitated a new pattern that needed to be adaptable to all of the potential actions. To ensure the effectiveness of this new pattern, we collected feedback to refine the pattern based on user input.
For external research, we conducted user testing sessions to gather insights on which accessibility concerns were most important for our users, enabling us to address them accordingly. We also reviewed patterns that exist within the builder tools of competitors and were surprised to find accessibility as a blindspot for most. Of those that offered some kind of accessibility check, the types of issues they checked tended to be limited, the review did not update as a user worked, and many required manual review. Even popular tools outside of the marketing landscape turned up very little as far as accessibility goes.
During this phase, I also worked closely with my engineering partner to understand the limitations of the tool that was selected to power the back-end of the check so any solutions I built would be achievable in our planned time. Through close collaboration and continuous communication with the engineering team, we were able to identify and address any technical constraints early on. This collaborative effort helped streamline the implementation process and ensure the feasibility and efficiency of our accessibility solutions.
Research findings
We approached five different participants for hour-long interviews to get input on early prototypes and better understand their feeling about our tool and our positioning as a guide and expert.
Users trusted us to know the best practices, but they would like to see the reasons behind the alerts. If possible, providing further resources outside of the platform, such as support articles or blog posts explaining accessibility. To address this, we incorporate explanations directly within the alerts, enabling them to deepen their understanding of accessibility issues without leaving their workflow.
Regarding alerts, users wanted the option to ignore them as part of the publishing process if a recommendation was not in line with their brand or tone. They were okay with prompts reminding them about outstanding alerts as part of the publishing process, but did not want to be blocked from publishing if they wanted to move forward without addressing them. Based on these findings we implemented an alert system that allowed users to selectively dismiss alerts based on their relevance and significance, ensuring a more tailored and streamlined experience.
Broadly, users were interested in resolving issues related to accessibility but wanted to make sure we wouldn't be interrupting their workflow while doing so. Therefore, we chose to position the starting point in an area that was not disruptive to the existing product, displaying alerts in a non-intrusive manner, minimizing disruptions and allowing users to address accessibility concerns at their own pace.
Flows and iterations
Review of expected user flows, proposing three steps to resolve alerts starting from the field they’re editing, with the card-based assistant serving as the last step. This approach was based on the idea that an area full of alerts, as beautiful and actionable as the alerts are, is a failure and that focusing earlier on in the experience is ideal.
Design process
Understanding the user and problems
The discovery phase began with a third-party audit that flagged a number of potential issues in our form product. Not only was this an issue from a values perspective, inaccessible forms expose users to legal risk and can result in fines or lawsuits. From this audit, we were able to break issues that could be resolved on the engineering side and worked to resolve those behind the scenes while a solution for the user-facing issues could be determined.
In an ideal world designing sign-up forms should be able to publish accessible forms without additional work. However, the freedom of a visual builder means problems are inevitable. User action was needed to resolve a number of issues as they are creating, for example: alt-text, color contrast, touch target size, and input field labels. Given most users were unfamiliar with accessibility, one major problem was combining education with new behavior, helping users understand the value of accessibility so it's not just another error or warning to dismiss.
While we have error and warning patterns in our design system, none quite fit the approach we were looking for as far as errors that were instructive and actionable. This necessitated a new pattern that needed to be adaptable to all of the potential actions. To ensure the effectiveness of this new pattern, we collected feedback to refine the pattern based on user input.
For external research, we conducted user testing sessions to gather insights on which accessibility concerns were most important for our users, enabling us to address them accordingly. We also reviewed patterns that exist within the builder tools of competitors and were surprised to find accessibility as a blindspot for most. Of those that offered some kind of accessibility check, the types of issues they checked tended to be limited, the review did not update as a user worked, and many required manual review. Even popular tools outside of the marketing landscape turned up very little as far as accessibility goes.
During this phase, I also worked closely with my engineering partner to understand the limitations of the tool that was selected to power the back-end of the check so any solutions I built would be achievable in our planned time. Through close collaboration and continuous communication with the engineering team, we were able to identify and address any technical constraints early on. This collaborative effort helped streamline the implementation process and ensure the feasibility and efficiency of our accessibility solutions.
Research findings
We approached five different participants for hour-long interviews to get input on early prototypes and better understand their feeling about our tool and our positioning as a guide and expert.
Users trusted us to know the best practices, but they would like to see the reasons behind the alerts. If possible, providing further resources outside of the platform, such as support articles or blog posts explaining accessibility. To address this, we incorporate explanations directly within the alerts, enabling them to deepen their understanding of accessibility issues without leaving their workflow.
Regarding alerts, users wanted the option to ignore them as part of the publishing process if a recommendation was not in line with their brand or tone. They were okay with prompts reminding them about outstanding alerts as part of the publishing process, but did not want to be blocked from publishing if they wanted to move forward without addressing them. Based on these findings we implemented an alert system that allowed users to selectively dismiss alerts based on their relevance and significance, ensuring a more tailored and streamlined experience.
Broadly, users were interested in resolving issues related to accessibility but wanted to make sure we wouldn't be interrupting their workflow while doing so. Therefore, we chose to position the starting point in an area that was not disruptive to the existing product, displaying alerts in a non-intrusive manner, minimizing disruptions and allowing users to address accessibility concerns at their own pace.
Flows and iterations
Review of expected user flows, proposing three steps to resolve alerts starting from the field they’re editing, with the card-based assistant serving as the last step. This approach was based on the idea that an area full of alerts, as beautiful and actionable as the alerts are, is a failure and that focusing earlier on in the experience is ideal.
Wireframes exploring position of accessibility alerts. Given feedback about a drawer overlay our approach shifted to the sidebar.
Wireframes exploring position of accessibility alerts. Given feedback about a drawer overlay our approach shifted to the sidebar.
Exploration of treatments of the drawer approach. Utilizing the left sidebar was determined to be the most feasible approach through feedback, existing models of interaction, and engineering complexity.
Exploration of treatments of the drawer approach. Utilizing the left sidebar was determined to be the most feasible approach through feedback, existing models of interaction, and engineering complexity.
Execution
Collaboration between the design and engineering teams was essential to implement Accessibility Assistant. Working closely with the engineer, we conducted regular meetings to align our understanding of the feature requirements, address any technical challenges or bugs, and ensure that our design solutions were feasible within the planned timeline. By maintaining open lines of communication, sharing knowledge, and looping in key stakeholders we were able to make informed decisions and find efficient solutions to overcome some of the challenging problems we faced here.
To validate and refine our feature implementation, we decided on a 2 week limited release period to a select group of users. This allowed us to gather real-world feedback, identify potential bugs or usability issues, and validate the effectiveness of the card approach. The limited release period was a valuable testing ground and gave us an opportunity to engage directly with users and incorporate their feedback into the final iteration.
Thanks to the partnership between the design and engineering teams and the valuable insights from the limited release, we were able to ship the feature quickly and with limited bugs, despite its inherent complexity. This approach, combined with regular testing and feedback loops, ensured that the final implementation met user expectations and provided a seamless and delightful experience for Klaviyo users. The successful execution of the feature highlighted the importance of cross-functional collaboration and user-centric development in delivering high-quality and impactful solutions.
Outcomes
Accessibility Assistant went live to all users in early May 2023. We are monitoring qualitative success metrics but the quantitative response has been extremely positive, from customer-facing roles internally to public call-outs on social media. We're deeply proud of strides we've made toward equity on the web and look forward to further developing the tool as standards evolve.
Future
Out of scope for this project were enhancements I proposed that involved smarter solutions like AI-powered alt text generation and in-context contrast resolution. While work was done to understand the tooling necessary to execute these concepts, achieving the desired features was ultimately not feasible for this launch.
Execution
Collaboration between the design and engineering teams was essential to implement Accessibility Assistant. Working closely with the engineer, we conducted regular meetings to align our understanding of the feature requirements, address any technical challenges or bugs, and ensure that our design solutions were feasible within the planned timeline. By maintaining open lines of communication, sharing knowledge, and looping in key stakeholders we were able to make informed decisions and find efficient solutions to overcome some of the challenging problems we faced here.
To validate and refine our feature implementation, we decided on a 2 week limited release period to a select group of users. This allowed us to gather real-world feedback, identify potential bugs or usability issues, and validate the effectiveness of the card approach. The limited release period was a valuable testing ground and gave us an opportunity to engage directly with users and incorporate their feedback into the final iteration.
Thanks to the partnership between the design and engineering teams and the valuable insights from the limited release, we were able to ship the feature quickly and with limited bugs, despite its inherent complexity. This approach, combined with regular testing and feedback loops, ensured that the final implementation met user expectations and provided a seamless and delightful experience for Klaviyo users. The successful execution of the feature highlighted the importance of cross-functional collaboration and user-centric development in delivering high-quality and impactful solutions.
Outcomes
Accessibility Assistant went live to all users in early May 2023. We are monitoring qualitative success metrics but the quantitative response has been extremely positive, from customer-facing roles internally to public call-outs on social media. We're deeply proud of strides we've made toward equity on the web and look forward to further developing the tool as standards evolve.
Future
Out of scope for this project were enhancements I proposed that involved smarter solutions like AI-powered alt text generation and in-context contrast resolution. While work was done to understand the tooling necessary to execute these concepts, achieving the desired features was ultimately not feasible for this launch.