Essential accessibility practices designers and developers must know

A designer's journey into code taught me that true accessibility isn't about grand gestures, it's about the details that matter most.

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:

Check color contrast for all text elements
Add proper focus states to all interactive elements
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:

Small yet non-negotiable: Essential accessibility practices every designer and developer must know

Table of contents