Web Development

8 min read • December 9, 2025

Accessibility Isn't Optional: The Basics That Actually Matter

Accessibility isn't about compliance checkboxes or perfect audit scores. It's about not excluding people from using your website. Here are the basics that actually make a difference.

Accessibility Isn’t Optional: The Basics That Actually Matter

I used to think accessibility was something you added at the end if there was time and budget. A nice-to-have. A compliance checkbox.

I was completely wrong.

Accessibility isn’t a feature. It’s a baseline requirement. If someone can’t use your website because you didn’t add alt text to images or because they can’t navigate with a keyboard, you’ve excluded them. You’ve built something that doesn’t work.

The good news? Most accessibility issues are easy to fix. You don’t need to be an expert. You just need to care enough to do the basics.

Why Accessibility Actually Matters

15% of the world’s population has some form of disability. That includes people who are blind or have low vision, deaf or hard of hearing, have motor difficulties, or cognitive disabilities.

If your site isn’t accessible, you’re potentially excluding 15% of your audience. That’s customers you’re losing. Users you’re frustrating. People you’re telling “this isn’t for you.”

Beyond the moral argument, there are practical ones:

Legal risk - In many countries, inaccessible websites can result in lawsuits. The ADA in the US, the Equality Act in the UK, the European Accessibility Act—these are real legal requirements.

SEO benefits - Many accessibility practices (semantic HTML, descriptive headings, alt text) also improve SEO. Search engines and screen readers need similar things.

Better UX for everyone - Accessible sites are often more usable for everyone. Captions help people watching videos in quiet spaces. Clear navigation helps all users. Good color contrast helps everyone.

The Basics That Make the Biggest Difference

You don’t need to become a WCAG expert overnight. Start with these fundamentals:

1. Semantic HTML

Use the right HTML elements for their intended purpose:

<!-- Bad -->
<div onclick="submit()">Submit</div>

<!-- Good -->
<button type="submit">Submit</button>

Use <nav> for navigation, <main> for main content, <article> for articles, <button> for buttons, <a> for links.

Screen readers rely on semantic HTML to understand page structure and functionality.

2. Alt Text for Images

Every meaningful image needs descriptive alt text:

<img src="product.jpg" alt="Blue ceramic coffee mug with handle" />

Decorative images should have empty alt text:

<img src="decorative-line.png" alt="" />

Don’t write “image of” or “picture of”—screen readers already announce it’s an image.

3. Keyboard Navigation

Everything interactive needs to be keyboard accessible. Users should be able to:

  • Tab through all interactive elements
  • Activate buttons/links with Enter or Space
  • Close modals with Escape
  • Navigate forms without a mouse

Test this yourself: unplug your mouse and try to use your site with just Tab, Enter, Space, and arrow keys.

4. Focus Indicators

Never remove focus outlines without replacing them with something visible:

/* Bad */
button:focus {
  outline: none;
}

/* Good */
button:focus {
  outline: 2px solid blue;
  outline-offset: 2px;
}

Keyboard users need to see where focus is. If you don’t like the default browser outline, style it—but don’t remove it.

5. Color Contrast

Text needs sufficient contrast against its background:

  • Normal text: 4.5:1 ratio minimum
  • Large text (18pt+ or 14pt+ bold): 3:1 ratio minimum

Use tools like WebAIM’s Contrast Checker to verify your colors meet these ratios.

Light gray text on white backgrounds looks “clean” but is often unreadable for people with low vision.

6. Form Labels

Every form input needs a proper label:

<!-- Bad -->
<input type="text" placeholder="Email" />

<!-- Good -->
<label for="email">Email address</label>
<input type="text" id="email" name="email" />

Placeholders aren’t labels. Screen readers need explicit labels to tell users what each field is for.

7. Heading Structure

Use headings in order (h1, then h2, then h3—don’t skip levels):

<h1>Page Title</h1>
<h2>Section Title</h2>
<h3>Subsection</h3>
<h2>Another Section</h2>

Screen reader users often navigate by headings. Proper structure helps them understand the page organization.

8. Link Text

Links should make sense out of context:

<!-- Bad -->
<a href="/services">Click here</a> to see our services

<!-- Good -->
<a href="/services">View our services</a>

Screen reader users often tab through links. “Click here” doesn’t tell them where the link goes.

Common Mistakes That Break Accessibility

Custom dropdowns/selects - If you replace native form controls with divs and JavaScript, you need to add full ARIA support and keyboard handling. Native controls are accessible by default.

Click-only interactions - If something only works on click, it probably doesn’t work with keyboard or assistive tech. Use proper buttons, not clickable divs.

Auto-playing media - Videos/audio that auto-play are disorienting for screen reader users and problematic for people with cognitive disabilities.

Time-limited interactions - Forms that time out, carousels that auto-advance—these create pressure and difficulty for users who need more time.

Modals that trap focus - If you open a modal, focus should move into it, stay within it, and return to the trigger when closed.

Hiding content with display: none - This hides it from screen readers too. If you want visual hiding but screen reader access, use visually-hidden patterns.

The Tools I Use to Check Accessibility

Browser extensions:

  • axe DevTools (free, catches common issues)
  • WAVE (visual feedback on problems)
  • Lighthouse (built into Chrome, includes accessibility audit)

Manual testing:

  • Keyboard navigation (Tab, Enter, Space, Escape, arrows)
  • Screen readers (NVDA on Windows, VoiceOver on Mac—both free)
  • Zoom to 200% (some users need magnification)

Color contrast checkers:

  • WebAIM Contrast Checker
  • Colorblind Web Page Filter (see what colorblind users see)

You Don’t Need to Be Perfect

WCAG has three levels: A, AA, and AAA. AAA is incredibly difficult to achieve and often unnecessary.

Most organizations aim for WCAG 2.1 Level AA. That’s the sweet spot between good accessibility and practical implementation.

But even if you’re not fully AA compliant, every improvement helps. Don’t let perfectionism stop you from doing the basics.

When to Use ARIA (And When Not To)

ARIA (Accessible Rich Internet Applications) lets you add accessibility information to HTML.

First rule of ARIA: Don’t use ARIA if you can use semantic HTML instead.

<!-- Bad -->
<div role="button" tabindex="0" onclick="submit()">Submit</div>

<!-- Good -->
<button type="submit">Submit</button>

When to use ARIA:

  • Adding labels to icon-only buttons: aria-label="Close"
  • Describing relationships: aria-describedby="error-message"
  • Announcing dynamic content: aria-live="polite"
  • Building complex widgets where HTML lacks semantics

But seriously: semantic HTML first, ARIA second.

What About Dynamic Content?

Single-page apps and dynamic content have additional accessibility challenges:

Route changes - When navigating between views, focus should move to the new content and screen readers should announce the change

Loading states - Use aria-live regions or loading messages so users know content is loading

Error handling - Errors should be announced to screen readers and associated with the relevant form fields

Infinite scroll - Provide a way to access footer content (or move the footer outside the scrolling area)

This stuff is harder, but still manageable if you think about it from the start.

Accessibility on a Budget

“We don’t have budget for accessibility” is not an excuse.

Most accessibility work is:

  • Using correct HTML elements (free)
  • Adding alt text (free, takes 30 seconds per image)
  • Testing with keyboard (free)
  • Running automated audits (free)

The expensive stuff is retrofitting inaccessible sites. Building it right from the start costs almost nothing extra.

How I Approach Accessibility in Projects

Design phase:

  • Ensure color contrast meets standards
  • Don’t rely on color alone to convey information
  • Design visible focus states

Development phase:

  • Use semantic HTML
  • Add alt text as you go
  • Test keyboard navigation for each component
  • Run automated audits regularly

Before launch:

  • Full keyboard navigation test
  • Screen reader spot check of key user flows
  • Automated audit with axe or Lighthouse
  • Fix critical issues, document and plan fixes for the rest

Post-launch:

  • Monitor for issues
  • Fix reported problems
  • Improve incrementally

The Bottom Line

Accessibility isn’t an advanced topic. It’s fundamental web development.

If you’re building websites without considering accessibility, you’re building broken websites. They might look fine, but they don’t work for everyone.

The basics aren’t hard:

  • Use semantic HTML
  • Add alt text to images
  • Support keyboard navigation
  • Ensure sufficient color contrast
  • Label forms properly
  • Structure headings logically

Do these things and you’ll avoid the majority of accessibility issues. You’ll build websites that work for more people. And you’ll sleep better knowing you haven’t excluded anyone from accessing your content.

What accessibility practices do you follow? What’s been challenging to implement?

← Back to Blog