Four years ago, I started my deep dive into digital accessibility as a designer. Recently, I've begun coding my own projects, and this dual perspective has shown me something crucial: the most impactful accessibility improvements aren't always the most obvious ones. They're often small, seemingly minor details that make the difference between a website that works for everyone and one that excludes millions.

If you're a designer who codes, a developer learning design, or anyone building for the web, these "small yet non-negotiable" practices will transform how your users experience your work.

Why "Small" details have massive impact

Here's what surprised me most about accessibility: a single missing focus state can make an entire website unusable for keyboard users. One poorly structured heading can leave screen reader users completely lost. A color choice that looks sophisticated can render critical information invisible to users with color vision differences.

The math is sobering: over 1 billion people worldwide live with some form of disability. That's not a niche market, that's a fundamental part of your audience.

But here's what really changed my perspective: accessible design isn't just better for users with disabilities. It's better for everyone.

The curb cut effect is real: when you design for accessibility, you create experiences that work better in bright sunlight, on slow connections, with broken mice, during multitasking, and in countless other everyday scenarios.

The Foundation: Understanding WCAG without the overwhelm

The Web Content Accessibility Guidelines (WCAG) can feel daunting at first: 168 success criteria across three conformance levels. But here's what four years of study taught me: focus on the patterns, not the individual rules.

WCAG is built on four principles, remembered by the acronym POUR:

• Perceivable: Information must be presentable in ways users can perceive

• Operable: Interface components must be operable

• Understandable: Information and UI operation must be understandable

• Robust: Content must be robust enough for various assistive technologies

Most accessibility wins come from mastering a handful of Level A and AA criteria that address these principles directly.

The non-negotiables: Design perspective

Color contrast isn't optional

WCAG 2.1 AA requires 4.5:1 contrast ratio for normal text, 3:1 for large text.

As designers, we love subtle grays and elegant low-contrast palettes. But here's the reality: insufficient contrast doesn't just fail automated tests, it makes content unreadable for users with visual impairments, color vision differences, and anyone using their device in bright sunlight.

Tools that changed my workflow:

• Figma plugins: Contrast, Stark - Color Contrast Checker

• Browser extensions, websites: WAVE, Accessibility Checker

• Design system integration: Build contrast checking into your component library. (I actually built a UI library for Flutter with built-in contrast checking, The Hux UI, if you want to check it out).

Pro tip: Don't just check your primary color palette. Test hover states, disabled buttons, and placeholder text. These often slip through the cracks.

Typography hierarchy that actually works

Good information hierarchy isn't just visually pleasing, it's assistive technology's roadmap through your content.

The non-negotiables:

• Use actual heading tags (H1, H2, H3) in logical order, not just styled divs

• Ensure headings describe the content that follows

• Maintain consistent heading hierarchy across pages

• Design with 16px minimum font size for body text

Focus States: The most overlooked UX element

Every interactive element needs a visible focus indicator. Yet I see beautiful designs ship with outline: none and no replacement focus state.

Design focus states that:

• Have sufficient contrast (3:1 minimum against adjacent colors)

• Are clearly distinguishable from hover states

• Work across all interactive elements consistently

• Don't rely solely on color changes

The non-negotiables: Development perspective

Semantic HTML is your superpower

Moving from design to code taught me that semantic HTML isn't just "best practice", it's the foundation of accessibility.

<!-- Instead of this -->
<div class="button" onclick="submitForm()">Submit</div>

<!-- Write this -->
<button type="submit">Submit</button>

Why this matters:

• Screen readers understand the purpose immediately

• Keyboard navigation works by default

• Mobile assistive technologies recognize interactive elements

• No JavaScript? The button still works.

Alt Text: Quality over compliance

Every image needs alt text, but not all alt text is helpful. Here's the difference between compliance and good UX:

<!-- Compliance but not helpful -->
<img src="chart.jpg" alt="chart">

<!-- Actually useful -->
<img src="chart.jpg" alt="Bar chart showing 40% increase in mobile users from 2022 to 2023">

<!-- Decorative images -->
<img src="decorative-line.svg" alt="" role="presentation">

The test: Could someone understand your content if they couldn't see your images?

Form accessibility that actually works

Forms are where accessibility often breaks down. Here's your checklist:

<!-- Proper form structure -->
<div>
  <label for="email">Email Address *</label>
  <input 
    type="email" 
    id="email" 
    name="email" 
    required 
    aria-describedby="email-error"
    aria-invalid="false"
  >
  <div id="email-error" class="error-message" role="alert">
    <!-- Error message appears here -->
  </div>
</div>

Non-negotiable form practices:

• Every input has a proper label (not just placeholder text)

• Error messages are programmatically associated with inputs

• Required fields are clearly marked

• Success and error states are announced to screen readers

Tools that transformed my workflow

Design Phase

• Figma plugins: Contrast or Stark for contrast checking, Include for accessibility annotations

• Color tools: WebAIM Contrast Checker, Colour Contrast Analyser

• Typography: Check line spacing (1.5x minimum) and paragraph spacing

Development Phase

• Browser extensions: axe DevTools (the gold standard), WAVE

• Automated testing: Pa11y, axe-core for CI/CD integration

• Manual testing: Navigate your site using only the keyboard, test with screen readers

The Plugin reality check

Accessibility plugins are incredibly useful, but they catch maybe 30% of accessibility issues. The other 70%? That requires understanding your users and testing with real people.

Use plugins for:

• Color contrast validation

• Missing alt text detection

• Heading structure analysis

• Basic ARIA errors

Don't rely on plugins for:

• Alt text quality

• Logical reading order

• Content comprehensibility

• User experience flow

Beyond compliance: Building inclusive experiences

After four years studying accessibility and transitioning into code, I've learned that the goal isn't WCAG compliance, it's creating genuinely inclusive experiences.

This means:

• Testing with actual assistive technology users

• Considering cognitive accessibility, not just screen reader compatibility

• Building flexible interfaces that work across different abilities and contexts

• Making accessibility part of your design system, not an afterthought

Start small, impact big

You don't need to revolutionize your entire workflow overnight. Study those three things and implement them in your next project:

1. Check color contrast for all text elements

2. Add proper focus states to all interactive elements

3. Use semantic HTML instead of generic divs and spans

These small changes will improve the experience for millions of users while making your code more maintainable and your designs more robust.

The path forward

Accessibility isn't a checklist to complete but more a practice to cultivate. As designers and developers, we have the power to decide who gets to participate in the digital world we're creating.

The techniques I've shared aren't just nice-to-haves or legal requirements. They're the foundation of inclusive design and development. They're non-negotiable because the alternative (excluding users based on ability) simply isn't acceptable.

Your next project is an opportunity to get this right from the start. Your users (all of them) are counting on it.

What accessibility practices have transformed your design or development workflow? Share your experiences in the comments below.

Resources mentioned in this article:

• WCAG 2.1 Guidelines

• WebAIM Contrast Checker

• axe DevTools Browser Extension

• WAVE Web Accessibility Evaluation Tool

• Pa11y Command Line Accessibility Tester

• The Hux UI

Instead of manually checking contrast ratios every time, I decided to build a system that handles this automatically. Here's how I implemented WCAG-compliant contrast calculations in Flutter.

The Problem with Manual Contrast Checking

Most design systems punt on this problem. They give you preset color combinations that work, but the moment you use a custom brand color, you're on your own.

// This could be completely unreadable
Container(
  color: myBrandColor, // Could be any color
  child: Text('Button Text', style: TextStyle(color: Colors.white)),
)

The WCAG Algorithm

WCAG defines contrast ratio as the luminance difference between two colors. The formula is:

contrast = (lighter + 0.05) / (darker + 0.05)

Where luminance is calculated using the sRGB color space with gamma correction. For normal text, you need at least 4.5:1 contrast ratio for AA compliance.

Implementation in Flutter

Here's how I implemented the contrast calculation system:

/// Calculates the relative luminance of a color according to WCAG guidelines
double _getRelativeLuminance(Color color) {
  // Convert RGB values to 0-1 range
  final r = color.r / 255.0;
  final g = color.g / 255.0;
  final b = color.b / 255.0;

  // Apply gamma correction
  final rLinear = r <= 0.03928 ? r / 12.92 : pow((r + 0.055) / 1.055, 2.4);
  final gLinear = g <= 0.03928 ? g / 12.92 : pow((g + 0.055) / 1.055, 2.4);
  final bLinear = b <= 0.03928 ? b / 12.92 : pow((b + 0.055) / 1.055, 2.4);

  // Calculate relative luminance using ITU-R BT.709 coefficients
  return 0.2126 * rLinear + 0.7152 * gLinear + 0.0722 * bLinear;
}

/// Calculates contrast ratio between two colors
double _calculateContrastRatio(Color color1, Color color2) {
  final luminance1 = _getRelativeLuminance(color1);
  final luminance2 = _getRelativeLuminance(color2);

  final lighter = luminance1 > luminance2 ? luminance1 : luminance2;
  final darker = luminance1 > luminance2 ? luminance2 : luminance1;

  return (lighter + 0.05) / (darker + 0.05);
}

The tricky part is the gamma correction. sRGB colors aren't linear - they use a gamma curve to match how displays work. You have to convert to linear RGB before calculating luminance.

Automatic Text Color Selection

Now I can automatically pick the best text color:

Color _getContrastingTextColor(Color backgroundColor, BuildContext context) {
  final whiteContrast = _calculateContrastRatio(
    backgroundColor, 
    HuxTokens.textInvert(context)
  );
  final blackContrast = _calculateContrastRatio(
    backgroundColor, 
    HuxTokens.textPrimary(context)
  );

  // Choose the color with better contrast
  return whiteContrast > blackContrast
      ? HuxTokens.textInvert(context)
      : HuxTokens.textPrimary(context);
}

This runs every time a button renders, automatically ensuring WCAG AA compliance regardless of the background color.

Semantic Design Tokens

The other technical challenge was building a theme system that works in both light and dark mode. Instead of hardcoding colors, I built semantic tokens:

class HuxTokens {
  /// Primary text color that adapts to light/dark theme
  static Color textPrimary(BuildContext context) {
    final isDark = Theme.of(context).brightness == Brightness.dark;
    return isDark ? HuxColors.white : HuxColors.black;
  }

  /// Surface color for elevated components
  static Color surfaceElevated(BuildContext context) {
    final isDark = Theme.of(context).brightness == Brightness.dark;
    return isDark ? HuxColors.black70 : HuxColors.white;
  }
}

Every component uses these tokens instead of raw colors. When you switch themes, everything adapts automatically without any component-level changes.

Performance Considerations

You might worry about calculating contrast ratios on every render, but:

1. It's fast: The math is just basic arithmetic, no expensive operations

2. It's necessary: The alternative is manually checking every color combination

3. It's cached: Flutter's widget rebuilding is smart about when this actually runs

Real-World Usage

In the actual component, it looks like this:

ButtonStyle _getButtonStyle(BuildContext context) {
  final effectivePrimaryColor = primaryColor ?? HuxTokens.primary(context);
  final foregroundColor = _getContrastingTextColor(effectivePrimaryColor, context);

  return ButtonStyle(
    backgroundColor: WidgetStateProperty.all(effectivePrimaryColor),
    foregroundColor: WidgetStateProperty.all(foregroundColor),
    // ... other styles
  );
}

No matter what color you pass in, the text will be readable.

Testing the Algorithm

I tested this against the WebAIM contrast checker to make sure my implementation matches the WCAG spec. The results are identical.

You can test it yourself:

HuxButton(
  primaryColor: Color(0xFF6366F1), // Any color
  child: Text('Always Readable'),
  onPressed: () {},
)

Why This Matters

Accessibility shouldn't be an afterthought. By building it into the component layer, developers get WCAG compliance without having to think about it.

The contrast calculation runs automatically, the semantic tokens handle theme switching, and your app stays accessible regardless of design changes.

The Trade-offs

Pros:

• Zero cognitive overhead for developers

• Guaranteed WCAG AA compliance

• Works with any color combination

• Adapts to theme changes automatically

Cons:

• Slight computation cost (negligible in practice)

• Less control over exact text colors (though you probably don't want that control)

Try It Out

The system is part of Hux UI, but the algorithms are standalone. You could implement this in any Flutter project:

flutter pub add hux

Have you implemented accessibility features in your component libraries? I'm curious about other approaches to this problem!

🔗 Links:

• Hux UI on pub.dev

• WCAG Contrast Guidelines

• WebAIM Contrast Checker

After spending way too much time recreating the same buttons, cards, and input fields across different projects (and watching them get implemented differently each time), I decided to build the component library I actually wanted to use.

What's Inside

Hux UI isn't trying to be everything to everyone. It's a focused set of components that cover the stuff you use every day, but done really well.

HuxButtons

I got tired of recreating the same button variations everywhere, so I built four that cover most use cases: primary, secondary, outline, and ghost. Three sizes that actually make sense together.

The thing I'm proudest of is the loading state handling. Instead of having to conditionally render spinners and disable buttons manually, you just flip the isLoading parameter and it handles everything. And when you use custom colors, the contrast calculation system I built automatically figures out whether to use white or black text so your buttons stay readable.

HuxCards

I built these because I was constantly rebuilding the same container pattern. Clean borders, consistent padding, optional headers and subtitles. If you need an action button in the corner, there's a spot for it. You can make them tappable or just use them as containers. The styling stays consistent whether you're in light or dark mode.

HuxTextField

I got tired of shipping text fields and then realizing during testing that we forgot to add hints or proper error states. Now they're built in by default, so you won't forget them. Labels, validation, icons, different sizes - all the stuff you end up needing anyway, but available from the start. The whole thing adapts to your theme automatically.

HuxLoading

Loading states are one of those things that seem simple until you have to implement them everywhere. I built a few different options: small spinners for inline use, and a full overlay component for when you need to block the whole screen. They all use the same design language and handle the edge cases properly.

HuxChart

Built on cristalyse for the heavy lifting, but wrapped in Hux styling. Line charts, bar charts, with titles and proper theming. Your data should look as good as the rest of your app.

HuxContextMenu

I added these because proper right-click interactions make apps feel more professional. The positioning is smart enough to avoid going off-screen, and I made sure they work properly on web (disabling the browser's default context menu). It's one of those details that users notice when it's missing.

The Theme System

This is where I got a bit obsessed. Every component uses semantic design tokens that adapt to light and dark mode. No hardcoded colors, no "oops this looks terrible in dark mode" surprises.

The color system follows design best practices: primitive colors separate from semantic tokens. Your primary brand color can be anything, and everything else adjusts accordingly.

Why I built it this way

I wanted components that are:

• Consistent: They all feel like they belong together

• Accessible: WCAG AA compliance isn't optional

• Themeable: Light and dark mode should just work

• Practical: Built for real projects, not just demos

Getting Started

flutter pub add hux

Then wrap your app with the theme:

MaterialApp(
  theme: HuxTheme.lightTheme,
  darkTheme: HuxTheme.darkTheme,
  // your app here
)

And start using components:

HuxButton(
  onPressed: () => print('Hello'),
  child: Text('Click me'),
)

The Real Talk

This isn't a massive design system with 47 different button variants and components for every edge case. It's the components you actually use, built really well.

I'm using it in my own projects, which means it has to work in the real world, not just in demos. Every component gets battle-tested, and accessibility isn't something I tacked on at the end.

If you're tired of rebuilding the same components over and over, or if you just want something that looks good out of the box, give it a shot.

It's open source, available on pub.dev, and hopefully saves you some time so you can focus on the stuff that actually makes your app unique.

Check out Hux UI on pub.dev or the GitHub repo to get started.