Notarize Signer Accessibility

Overview

We updated every page of the signer experience to make it accessible and adhere to WCAG 2.1 AA standards, without negatively impacting any KPIs.

Background

Notarize (now rebranded to Proof) is a platform that allows users (referred to as “signers”) to get documents signed or notarized online. The platform caters to enterprise customers that send business and real estate documents to their signers to be signed or notarized, as well as signers that need their own personal docs signed or notarized.

Previously, the signer’s experience wasn’t built accessibly.

Problem to solve

Our signer experience was originally built without accessibility in mind. 1 in 4 people in the United States have a disability. Without having an accessible product that met WCAG standards, Notarize wasn’t able to support a large portion of the US population that may have wanted to use Notarize for remote, online notarization.

Larger enterprise customers started to question the accessibility of the platform and wanted to make sure that their Signers could expect an accessible experience on Notarize. By not being able to show that we had an accessible product for Signers, we were limiting the number of customers that would ultimately onboard with our product.

My role

I was the Product Manager on this project. I worked with Deque to do an accessibility audit and have our Voluntary Product Accessibility Template (VPAT) written. I also worked with Finance and Procurement to get a budget and contract to work with Deque, and worked with Marketing to communicate the changes we made.

I worked with a Product Designer that redesigned components, a UX engineer that built out web components, and 2 Full-Stack Engineers to rebuild steps in the Signer experience accessibly. I QAed all updates and fixes to ensure that we passed subsequent audits, and monitored data to ensure we didn’t hurt our main KPIs. I also was responsible for communicating with customers all of the changes we were making and when they could expect our full VPAT to be issued.

Metrics

We released the accessible changes weekly, over a 5 month period. While we didn’t make any major changes to the signer experience, we did need to update components and make other UI tweaks to ensure accessibility. I monitored our KPIs every week to ensure that numbers stayed neutral with all of the changes we were making.

• Transaction conversion

• Drop off - cut by step in the signer funnel

• Number of transactions completed per day

Key takeaways and learnings

• Notarize got our first VPAT! We hit WCAG 2.1 AA standards, showing that we were committed to supporting an accessible signer experience. Since getting our VPAT, this has become an important feature that every new enterprise customer is asking about before agreeing to onboard with us.

• Shortly after our VPAT was achieved, other teams built new experiences that weren’t accessible. We put automation in place that runs the Deque aXe Chrome extension to ensure accessibility checks are passing and will block Engineers from merging code that doesn’t meet the WCAG 2.1 AA standards.

• We’ve continued to conduct talks and trainings to help teach other PMs, Product Designers, and Engineers at the company the importance of accessibility. We focus on what it means to design an accessible experience, what you need to do to build an accessible experience, and how QA can test for accessibility.