vinitium · field note

Accessibility results, uninvited

Role
Product designer, accessibility × dashboard
Duration
Research phase
Status
research

Auto-enabling accessibility scans on ordinary test runs puts a11y results in front of teams who never asked for them — value realization and lead generation in one move. The design problem: presenting an uninvited, deliberately lightweight scan honestly, inside a dashboard built for a different job.

Problem

A sample scan is not a compliance audit. Showing auto-generated a11y results next to a team's functional tests risks two failures at once — overselling (the team believes they're covered when the scan is partial) and clutter (the team resents results they didn't request on a surface they rely on daily).

Where it leads

This is research work — it ends in open threads, not outcomes. They're below, stated plainly.

The research mapped the existing accessibility product’s mature use-case hierarchy — from listing scanned tests, through issue drill-downs, to trend analytics — against the functional dashboard’s information architecture, to find where auto-enabled results could live without colonizing the surface.

Where uninvited results could live An abstract map of the functional dashboard's build view, the accessibility product's own dashboard, and the candidate integration point between them — a summary card that links across rather than embedding everything. scan surfaced full story lives there build view a11y summary a11y product

The integration shape under exploration: a scoped summary on the busy surface, with the full experience one deliberate hop away.

The finding I’d defend anywhere: an uninvited result must introduce itself. The card leads with what was scanned and what wasn’t — sampled pages, a subset of rules — before it shows a single count. Trust survives partial coverage; it does not survive discovered partial coverage.

Open threads

The full walkthrough — screens, numbers, names — happens in conversation. Start one →