Accessibility-First Design: Building Beautiful Interfaces That Work for Everyone

How we achieved WCAG 2.1 AA compliance in VoiceCatcher while maintaining award-winning visual aesthetics

The False Dichotomy

For too long, the design community has treated accessibility and beautiful design as opposing forces. “We can make it accessible or we can make it beautiful,” teams often say, as if these goals are mutually exclusive.

Today, I want to share how we proved this wrong while building VoiceCatcher’s interface.

The Challenge: Close Buttons in Brand Contexts

It started with a simple problem: our close button was too prominent in the brand header. The 32x32px neumorphic button, while functionally perfect, was competing with our “VoiceCatcher” brand name for visual attention.

The obvious solution? Make it smaller, more transparent, less visually prominent.

But then came the critical question: “Would that meet accessibility standards?”

This question led us down a path that fundamentally changed how we approach interface design.

The Accessibility Reality Check

WCAG 2.1 Requirements Are Non-Negotiable

When we audited our “obvious” solution against WCAG 2.1 AA standards, the results were sobering:

Target Size (2.5.5): Minimum 44x44px for touch targets
Color Contrast (1.4.3): 3:1 ratio for UI components
Focus Indicators (2.4.7): Visible focus indication required
Semantic Markup (4.1.2): Proper ARIA labels essential

Our 24x24px transparent button failed on multiple counts.

The Mindset Shift

Instead of asking “How can we make this accessible?” we started asking “How can we design this to be accessible from the ground up?”

This shift changed everything.

The Solution: Contextual Design Variants

We developed a unified close button system with three variants, each optimized for its context while maintaining full accessibility:

1. Primary Variant (Settings Panels)

.neumorphic-close-button.primary {
  width: 32px;
  height: 32px;
  opacity: 1;
  /* Full neumorphic styling */
}

2. Minimal Variant (Brand Contexts)

.neumorphic-close-button.minimal {
  width: 28px; /* WCAG compliant size */
  height: 28px;
  opacity: 0.7; /* Maintains 3:1 contrast */
  background: var(--neu-bg);
  box-shadow: subtle-neumorphic-shadows;
}

3. Accessible Implementation

<button
  className="neumorphic-close-button minimal"
  aria-label="Close VoiceCatcher application"
  type="button"
>
  <X className="w-4 h-4" aria-hidden="true" />
</button>

The Design Psychology Behind It

Progressive Disclosure

The minimal variant starts subtle (70% opacity) but reveals full functionality on interaction:

Hover: Full opacity, enhanced shadows
Focus: High-contrast outline, full visibility
Active: Tactile feedback with inset shadows

Visual Hierarchy Respect

By starting with accessibility requirements, we were forced to find creative solutions:

Refined spacing: Optimized container padding and positioning
Subtle shadows: Neumorphic depth without compromising contrast
Smart opacity: Visible enough for accessibility, subtle enough for brand harmony

The Neumorphic Accessibility Challenge

Neumorphic design presents unique accessibility challenges:

Subtle shadows can reduce contrast
Depth effects may not translate to screen readers
Complex visual relationships need semantic backup

Our Approach

Shadows enhance, don’t replace: Visual depth supports but doesn’t substitute semantic structure
Progressive enhancement: Base accessibility with visual refinements layered on top
Dual indicators: Visual cues backed by proper ARIA labels and semantic markup

Dark Mode: Accessibility Amplified

Dark mode introduced additional complexity:

.dark .neumorphic-close-button.minimal {
  opacity: 0.8; /* Enhanced for dark backgrounds */
}

We discovered that accessibility requirements actually improved our dark mode implementation, forcing us to consider contrast ratios we might have otherwise overlooked.

Technical Polish: Eliminating the Dark Mode Flash

A common accessibility issue in dark mode implementations is the brief “flash” of light mode that occurs when the app loads. For users with photosensitivity or those using the app in low-light environments, this flash can be jarring and uncomfortable.

The Problem: In tray applications like VoiceCatcher, the theme is typically applied after React loads and settings are fetched asynchronously, causing a momentary light mode display.

Our Solution: We implemented a two-layer theme initialization system:

<!-- Pre-React theme initialization -->
<script>
  // Apply cached theme immediately, before React loads
  var cachedTheme = localStorage.getItem('voicecatcher-theme');
  if (cachedTheme === 'dark' || cachedTheme === 'light') {
    document.documentElement.className = cachedTheme;
  }
</script>

This approach ensures:

Instant theme application from localStorage cache
No visual flash when reopening the tray window
Seamless experience for users with photosensitivity
Maintained sync with actual settings through React

This level of technical polish demonstrates that accessibility isn’t just about meeting standards—it’s about creating genuinely comfortable experiences for all users.

The Broader Implications

For Designers

Start with constraints: Accessibility requirements spark creative solutions
Test early: Use contrast checkers and screen readers during design
Think systemically: Consistent accessibility patterns scale across interfaces

For Developers

Semantic first: Proper HTML structure before visual styling
ARIA labels are not optional: Every interactive element needs clear labeling
Keyboard navigation: Test without a mouse regularly

For Product Teams

Accessibility is not a feature: It’s a fundamental requirement
Budget for it: Accessibility work takes time but pays dividends
Measure it: Include accessibility metrics in your definition of done

The Results

Our accessibility-first approach delivered:

100% WCAG 2.1 AA compliance across all close button variants
Improved visual hierarchy that actually enhanced the brand presentation
Better user experience for everyone, not just users with disabilities
Scalable design patterns that work across our entire interface

Lessons Learned

1. Constraints Breed Creativity

WCAG requirements didn’t limit our design—they forced us to be more creative and thoughtful.

2. Accessibility Benefits Everyone

The spacing improvements and visual hierarchy refinements made the interface better for all users.

3. Start Early, Test Often

Retrofitting accessibility is expensive. Building it in from the start is efficient.

4. Tools Are Your Friends

Lighthouse: Automated accessibility auditing
axe-core: Detailed accessibility testing
WebAIM Contrast Checker: Real-time contrast validation
Screen readers: Essential for testing actual user experience

The Future of Accessible Design

We’re planning additional improvements:

High contrast mode: For users who prefer enhanced contrast
Reduced motion: Respecting prefers-reduced-motion preferences
Voice control optimization: Better support for voice navigation
WCAG 2.2 compliance: Staying ahead of evolving standards

Call to Action

The next time you’re designing an interface, ask yourself:

What would this look like if I started with accessibility requirements?
How can constraints spark creative solutions?
What would a screen reader user experience?

Try it. You might be surprised by how much better your designs become.

Technical Implementation

For developers interested in implementing similar patterns, our complete accessibility design system documentation is available in our repository. Key highlights:

Testing Checklist

Screen reader compatibility (NVDA, JAWS, VoiceOver)
Keyboard navigation flow
Color contrast validation
Touch target size verification
Focus indicator visibility
ARIA label accuracy

Browser Support

Chrome/Chromium ✅
Firefox ✅
Safari ✅
Edge ✅
Mobile browsers ✅

Conclusion

Beautiful design and accessibility are not opposing forces—they’re complementary aspects of excellent user experience design. By starting with accessibility requirements and enhancing with visual refinements, we create interfaces that work for everyone while maintaining award-winning aesthetics.

The close button system in VoiceCatcher proves that when we embrace accessibility as a design constraint rather than an afterthought, we create better solutions for everyone.

Accessibility isn’t about compliance—it’s about craftsmanship.

Jeremy is building VoiceCatcher, an AI-powered voice transcription tool focused on accessibility and beautiful design. Follow the development journey at harte.io.