Menu
UX Design
research
2025
Increasing lead conversions with context and clarity
The AudioEye accessibility Scanner
My Roles
UX Design
User Testing
Project Management
The Team
SR UX/UI Designer (me)
Lead Developer
Sr Brand Manager
Digital Marketing Manager
TLDR
The main lead capture tool was an accessibility scanner that could detected issues present on their homepage, and positioned their tool as the solution for maximum potential complaince - but the conversion rate was steadily declining.
+34%
Conversion Rate on Page
~6% → ~8%
+31%
Demo requests
36 → ~47/month
+17.8%
Free Trials Started
Overview
Why'd you have to go and make compliance so complicated?
AudioEye is a web accessibility platform that helps companies identify and remediate digital barriers for users with disabilities. I led the design of a public-facing URL scanner — a free tool that scans any web page against 38 of 54 WCAG criteria and returns a plain-language breakdown of compliance status, issue severity, and how those issues affect real people using assistive technology. The scanner serves as a top-of-funnel touchpoint: a low-friction way for prospective customers to see the scope of their accessibility problem before engaging with AudioEye’s paid product.
Problem
Prototype screenshot
AudioEye’s previous scanner was positioned around demonstrating technical expertise, with output that was authoritative but largely opaque to the non-technical marketing managers and small business owners who made up a significant portion of inbound traffic. Internal data showed that many users who completed a scan did not take a meaningful next step — they couldn’t connect what they were seeing to an action they knew how to take.
The scanner attracted a wide range of users — from non-technical digital marketing managers encountering WCAG for the first time, to engineering leads who wanted technical depth, to small business owners primarily motivated by legal risk. The one trait almost all users shared was a low baseline understanding of web accessibility. This became the central design constraint: how do you build a tool that feels credible and useful to a developer, while remaining genuinely legible to someone encountering accessibility for the first time?
Research & Discovery
Research ran continuously across both phases, combining competitive analysis, heuristic evaluation, analytics review, usability testing, and user interviews. A key competitive audit finding shaped the project early: existing scanners were not explaining accessibility in human terms. Severity ratings existed, but the so what — who is affected, what does the experience feel like, what is the compliance risk — was almost universally absent.
Key Findings
Key Design Decisions
Five decisions that shaped the design.
01
Progressive disclosure for a split audience
Rather than designing separate experiences for technical and non-technical users, we used a tabbed progressive disclosure pattern within individual issue cards — three tabs covering issue description, fix options, and lived-experience impact. Users could engage at whatever depth suited them without the interface front-loading complexity.
Click through the tabs below
A list element is missing required child elements
A list element was found to be missing required nested list item elements. A list element, either HTML 'ul' (unordered list) or 'ol' (ordered list) or the ARIA role 'list' requires the 'list item' element to be nested within it. Without list items, assistive technologies such as screen readers cannot convey the purpose or structure of the list to users, leading to incomplete or incorrect interpretation. This can cause confusion and navigation issues for users relying on assistive technologies.
Fix it with AudioEye
The AudioEye Accessibility Script fixes these issues within minutes of installation.
AudioEye Experts can fix these issues for you through our platform experience.
We provide guidance for your developers to fix these issues in your source code.
Or, fix it yourself
All headings should follow an outline format. The page's first heading should be an <h1>. Sections under that should use an <h2>, subsections under each <h2> should use an <h3>, and so on. Don't skip heading levels, use them out of order, or use headings for text that isn't part of the page outline.
1<h1>Chapter 3</h1>
2...
3<h2>Section 1</h2>
4...
5<h3>Subsection A</h3>How this impacts your customers
This issue may cause some users with disabilities difficulty in taking an action or in using site navigation on this page. This issue primarily affects users with visual impairments. It can also affect users with motor disabilities.
Learn how your users are using Assistive Technology →(opens in a new tab)
02
Plain language as a design principle
We made a deliberate commitment to removing accessibility jargon from the interface — a decision that required sustained advocacy against pushback from stakeholders who felt technical language signalled credibility. Our position was that credibility built through clarity was more valuable than credibility built through terminology.
03
The ‘impact’ tab — showing lived experience
Users consistently asked what accessibility issues looked like in practice from the perspective of someone using assistive technology. Because our API didn’t allow us to render a user’s live site with issues in context, we designed an impact tab that surfaced short video examples of users encountering analogous issues with screen readers. This became one of the most valued features in post-launch interviews.
04
The fix chart and the pie chart debate
Our original phase 2 design used a bar chart to visualize issue types. Stakeholders favoured a pie chart as a more familiar format. After evaluating accessibility implications — pie charts can be challenging for colour-blind users and screen readers — we agreed to the pie chart conditional on implementing pattern fills and including a screen-reader accessible table alternative.
How to Fix Each Issue
AudioEye can address the majority of issues on your page with a combination of automation and custom accessibility fixes.
- 146 Automated Fixes
- 26 Expert Fixes
- 4 Source Fixes
| Issue Fix Options | Issue Count |
|---|---|
| Automated Fixes | 146 |
| Expert Fixes | 26 |
| Source Fixes | 4 |
05
Hero card layout — a debate I’d revisit
I advocated for a progressive or sidebar-based layout for the results hero. The digital marketing manager made a strong case for the dashboard-style three-card layout — compliance status, issue count, and issues by severity. In testing those three cards were identified as the most valuable part of the interface. I still believe there’s an untested case for the progressive approach, particularly for accessibility novices.
Outcomes
Beyond the quantitative results, qualitative feedback from post-launch interviews with users who had run a scan but not booked a demo revealed consistent themes: users felt more informed about their accessibility status than they had with previous tooling, and the fix advice — even when they chose not to act on it — built trust in AudioEye’s knowledge. The transparency and education goals at the core of the project appear to have landed.
+34%
Conversion Rate on Page
~6% → ~8%
+31%
Demo requests
36 → ~47/month
+17.8%
Free Trials Started
+28%
Return Visits from Users
Aug 4, 2025 – Feb 2026 vs. prior period, ~600 gated page views/month
What I would do differently
The most significant thing I would change is the timing of user research. We conducted user interviews after visual design and content were largely finalised — which meant the insights we gathered were retrofitted rather than formative. I would also invest more in early stakeholder alignment: the most contested decisions became more divisive than they needed to be because we hadn’t built shared understanding of the problems we were solving before moving into visual design. Finally, I would have pushed to test progressive disclosure approaches for accessibility novices — there’s a real hypothesis there about whether more scaffolding would increase comprehension and lower drop-off.
Upon Reflection
This project reinforced something I care about deeply: that good design in a technical domain isn’t about dumbing things down — it’s about finding the right entry point for each person. The accessibility industry has a real literacy gap, and tools that speak only to practitioners end up reinforcing the perception that accessibility is a specialist concern rather than a shared responsibility. Building something that works for a first-time small business owner and an engineering director at the same time, without making either feel underserved, was the central challenge — and the engagement data suggests we found a reasonable answer to it.