Accessibility Toolbar

WCAG-compliant UI built for flexibility, branding, and inclusive design.

In 2020, I led the redesign of the AudioEye Toolbar—one of the company’s core accessibility products used by millions. The project aimed to modernize the interface, introduce admin customization, and improve mobile usability while staying fully WCAG-compliant.

Despite working with limited resources and engineering turnover, I built a lightweight design system, resolved contrast issues tied to user-selected colors, and reimagined the experience for mobile. These updates led to a 20% increase in user engagement, a 10% lift in mobile conversion rates, and a drop in support tickets related to toolbar visibility and functionality.

This project was a turning point in my accessibility design career, proving how thoughtful, inclusive design can drive both usability and business impact.

0 1

Introduction

Three months into my role at AudioEye, I was asked to lead the UI redesign of one of its most visible products: the AudioEye Toolbar. The toolbar is what most people associate with AudioEye’s brand and is the most direct touchpoint for end-users. Despite that, it had an outdated UI, lacked mobile support, and didn’t accommodate the incoming admin features stakeholders were eager to launch.

On paper, the ask was straightforward: modernize the interface and prepare it for the new features. But underneath the surface, I had to solve for invisible constraints—accessibility requirements, limited resources, and gaps in our design system.

0 2

Problem Space

Product Context & Strategic Alignment

AudioEye is a SaaS platform that automatically remediates digital accessibility issues. Once installed, it integrates a toolbar into a client's website, allowing end-users to personalize their experience for better access and comfort.

This redesign was part of a broader product initiative to improve:

  • Adoption of admin features (customization = more value)

  • Mobile support (increasing mobile traffic among clients)

  • Brand trust (modern design as a signal of product maturity)

My PM framed the goals around one clear statement: "We want to give clients more ownership of their site experience without compromising accessibility."

Business Goals & Success Metrics

🎯 Business Goals:

  • Make the toolbar customizable to match client brands (admin panel)

  • Improve accessibility compliance (WCAG 2.1 AA)

  • Extend the design to mobile experiences

📈 Success Metrics:

  • Redesigned the web accessibility toolbar to enhance usability for millions of users

  • Increased user engagement by 20% through a more intuitive interface

  • Improved mobile usability, resulting in a 10% rise in conversion rates

  • Reduction in support tickets related to toolbar visibility/usability

  • QA pass rate for accessibility on both desktop and mobile

Initial Research & Limitations

I inherited a starting point: the previous designer had begun a visual refresh and defined a neutral color palette for white-labeling.

From there, I:

  • Conducted a quick audit of the existing design system

  • Met with Engineering to understand technical limitations

  • Reviewed support tickets and past client requests

Constraints:

  • No direct access to end-users for early testing

  • Engineering turnover meant changing dev priorities

  • Accessibility compliance needed to be baked into every interaction

0 3

Solution Space

To keep this human and honest, I’m breaking this into problem-solution pairs that capture the key issues we tackled.

Problem 1: The Toolbar Lacked Brand Customization

Context: Clients wanted the toolbar to match their site’s branding, but we couldn’t just let them pick any color—we had to maintain accessibility.

💡 Solution (Figure 1): We introduced a custom accent color feature, but quickly ran into a WCAG contrast issue. Bright brand colors like yellow or light blue failed accessibility.

Iterations:

  • V1: Applied chosen color to toolbar background → failed contrast

  • V2: Applied chosen color to icon only → better control

  • Added auto-contrast logic to adjust icon elements (black or white overlay) based on client color choice

  • Added a reset button to return to the default blue

A quick meeting with engineering confirmed we could calculate and enforce a 3:1 contrast ratio in code—a small fix with a huge payoff.

Figure 1: Solution 1

Problem 2: Light Theme Was A Contrast Nightmare

Context: Light themes are visually appealing, but tricky. Stark black-on-white strains the eyes; soft greys often fail WCAG.

💡 Solution (Figure 2): I introduced a cool-toned grey palette that passed contrast requirements but felt softer than pure black. I added:

  • Layered shadows for visual depth

  • Focus states using outlines instead of color alone

  • Button opacity locked at 100% for end-user clarity

Figure 2: Solution 2

Problem 3: The Toolbar Wasn’t Mobile-Friendly

Context: The existing toolbar hadn’t been designed for mobile at all. Mobile users were growing, and it was unacceptable that the experience broke on small screens.

💡 Solution (Figure 3): We rebuilt the mobile experience:

  • Adjusted breakpoints (345x720 viewport)

  • Increased tap target sizes from 24x24 to 44x44

  • Removed non-mobile features (e.g., cursor highlight)

  • Redesigned icon placement flow for admin users on mobile

We also simplified the mobile UI to ensure it loaded fast and stayed unobtrusive.

Figure 3: Solution 3

Problem 4: Engineering Needed Better Guidance

Context: With engineers frequently transitioning in and out due to turnover, I couldn’t rely on long-term shared knowledge, which put visual consistency at risk.

💡 Solution (Figure 4): I built a mini design system in Figma:

  • Reusable components for icons, typography, and focus states

  • Documented accessibility decisions in Confluence

  • Held weekly check-ins with engineering to scope edge cases

Figure 4: Solution 4

0 4

Outcome & Impact

🚀 Successful Launch: Rolled out to production on schedule in April 2021.

🏢 Enterprise Adoption: Customization features gained traction with multiple large clients.

🛡️ Accessibility Compliance: Accessibility QA passed across all supported browsers and devices.

📈 Higher Engagement: Increased user engagement by 20%.

📲 Mobile Conversion Boost: Improved mobile usability led to a 10% rise in conversion rates.

📉 Fewer Support Issues: Noticed a decline in reported problems related to toolbar visibility and functionality.

0 5

Long-Term Vision

While the V2 toolbar was well received, it was only the beginning. Next phases included:

🧑‍🔬 Planned User Testing: Post-launch testing scheduled with Fable to gather accessibility feedback from users with disabilities.

✨ Feature Expansion: Roadmap includes additional admin capabilities like custom text and usage analytics.

🔧 Developer Enablement: Preparing an embeddable SDK (Software Development Kit) to give developers more flexibility in integrating the toolbar.

0 6

Reflections & Learnings

This project taught me what it means to balance polish with practicality. I discovered that accessibility constraints don’t hinder creativity—they spark it. Building even a small design system helped bring consistency and efficiency to the team, saving us time and confusion. I also learned that transparency builds trust; I didn’t have perfect data or polished insights, but sharing what we had and iterating openly moved the project forward. Most importantly, I saw firsthand how powerful cross-functional collaboration can be. And above all, I came away with a deeper understanding that designing for inclusion isn’t a limitation—it’s a catalyst for better, more thoughtful design.

Want to see it live? Check out the toolbar on AudioEye’s client sites