Making an Accessibility Product Measurable

About Hand Talk

Hand Talk is an award-winning accessibility platform that uses AI to translate digital content into sign language through virtual avatars. The plugin runs inside other organizations' websites, which means the same interface can appear in ecommerce, entertainment, education, and public-service contexts.

The measurement problem

The plugin already generated events, but a single event could not explain a journey. We needed to tell apart outcomes that looked identical in a dashboard:

• A translation that completed, paused, failed, or was deliberately cancelled
• An onboarding flow that was completed, declined, or interrupted at a specific step
• A screen that was closed after an action versus closed without any interaction
• A preference that was briefly changed versus the final configuration a user kept
• A link opened from a loading screen versus the same destination opened intentionally from About

The goal was never to track more. It was to make each event answer a question.

Mapping the product

I documented 11 flows across the plugin: unauthorized tokens, About, loading, the legacy survey, the redesigned survey, survey entry, translation evaluation, the translation lifecycle, personalization, first-run onboarding, and onboarding started from the menu.

Each flow included its successful path, its interruptions, its errors and its exits. Mapping those before naming any event is what kept the taxonomy from becoming a pile of unrelated clicks.

A shared event language

The framework used five fields so that a designer, product manager, developer, or analyst could understand the same event without additional translation.

This structure made related events comparable while preserving the context needed to interpret them. Event names stayed stable, while labels and bounded values explained where or why the behavior occurred.

Designing for states, not only clicks

A translation was the clearest example of why click tracking was insufficient. Playback could finish normally, pause, be interrupted by a new request, stop when the menu opened, fail on unreadable content, or end when the plugin closed. Afterward, the evaluation prompt introduced another set of outcomes.

The second description supports a product conversation. The first does not.

Important implementation decisions

Cancellation needs a reason

"Translation cancelled" was not enough. Closing the plugin, opening the menu and starting a new translation are different intentions and call for different responses.

No interaction is still a state

Screens closed without interaction were mapped explicitly, which kept silence from being counted as success.

Capture the final preference

Personalization events fired when the user closed the menu or the plugin, capturing the configuration they kept rather than every adjustment they tried.

Failures need a follow-up path

A translation failure and a user's decision to report it are separate events, which keeps technical reliability apart from willingness to give feedback.

What the framework made possible

The flow maps and event definitions became a shared tracking contract between Design, Product and Development. Every later Hand Talk study on this site runs on top of it, and in two of them the dependency is exact.

The redirect investigation needed one label. The same event, Hand Talk Link Clicado, fires from two places: the plugin's loading screen and its About panel. Because the spec gave them one name and two labels, that traffic could later be split 96% against 4% and the disqualified leads traced to the loading screen. Collapsed into a single event, the two paths would have been one indistinguishable number and there would have been nothing to find. See Why 94% of Our Leads Were Wrong.

The evaluation study needed three states. A positive rating, a negative rating and a prompt closed without a response were separate events from the start. That is what allowed a later redesign to be measured as a change in completion rather than a change in volume. See Translation Evaluation Impact Analysis.

• 11

  Product flows mapped end to end

• 53

  Trackable interactions and states specified

• 3

  Later studies that ran on this instrumentation

A privacy retrospective

The original spec used placeholders for translated content, email and installation tokens. Looking at it now, those placeholders mark a boundary I would draw differently: analytics should not receive raw user content or identifying values just because the tooling permits it.

Lessons learned

Analytics design starts before the dashboard. Mapping the product first is what made later questions answerable at all.

The most useful signal is often not an action. Failure, interruption and no interaction say more about friction than a successful click does.

And a measurement framework is a product decision system, not a reporting chore. Its value shows up months later, in the questions a team can still answer.