HTML & CSS Accessibility Best Practices

Complete HTML and CSS accessibility guide for WCAG 2.1 AA compliance. Semantic HTML5, ARIA patterns, focus management, and accessible CSS techniques.

8 min read

Introduction

Native HTML and CSS provide the strongest accessibility foundation available on the web. Semantic HTML5 elements communicate meaning to assistive technologies without requiring ARIA. When accessibility is built into HTML and CSS from the start, compliance is achievable with minimal additional effort.

Hand-coded HTML/CSS sites are held to the same WCAG 2.1 AA standard as any other website. The ADA covers all public-facing websites regardless of how they're built. Custom HTML gives you the most control to achieve and maintain full accessibility compliance.

Legal Risk: Websites built on HTML & CSS are subject to ADA Title III requirements. Over 400+ lawsuits target HTML & CSS sites annually. 55% of sites are non-compliant.

Common Accessibility Issues

Non-Semantic HTML StructureseriousWCAG 2.1 AA 1.3.1

Using div and span for all layout instead of article, section, nav, main, header, footer semantic elements.

Missing Focus StylescriticalWCAG 2.1 AA 2.4.7

CSS resets that remove :focus outline without providing a replacement focus indicator.

Inaccessible Custom WidgetscriticalWCAG 2.1 AA 4.1.2

Custom dropdown menus, accordions, and tabs built with div/span without ARIA roles and keyboard support.

Color Alone Communicates InformationseriousWCAG 2.1 AA 1.4.1

Error states, required fields, or data categories communicated by color only without text or icon.

How to Fix Common Issues

Semantic HTML Structure

Before (inaccessible)

<div id="header"><div id="nav">...</div></div>
<div id="main">...</div>
<div id="footer">...</div>

After (accessible)

<header>
  <nav aria-label="Main navigation">...</nav>
</header>
<main id="main-content">...</main>
<footer>...</footer>

Replace generic divs with semantic HTML5 elements. <main> is the primary content landmark. <nav> needs aria-label if multiple navs exist. Screen readers expose these as navigation landmarks.

Accessible Focus Styles

Before (inaccessible)

* { outline: none; } /* CSS reset */

After (accessible)

:focus-visible {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
  border-radius: 2px;
}

Never remove :focus outlines without providing a replacement. Use :focus-visible to show focus only for keyboard navigation (not mouse clicks). 2px minimum outline width, 3:1 contrast with adjacent colors.

HTML & CSS-Specific Notes

Native HTML has the best accessibility support of any approach. Use the ARIA Authoring Practices Guide (APG) at w3.org/WAI/ARIA/apg for widget patterns. Semantic HTML first, ARIA second. Don't use ARIA to fix bad HTML. Test with keyboard-only navigation and at least one screen reader (NVDA free, VoiceOver built-in).

Accessibility Statistics

400+

Lawsuits per year

55%

Sites non-compliant

30-60 hours

Avg fix time

Frequently Asked Questions

When should I use ARIA vs semantic HTML?

Use semantic HTML first. ARIA is for when no semantic HTML element exists. The first rule of ARIA: don't use ARIA if you can use semantic HTML. For example, use <button> not <div role='button'>.

What's the most important accessibility fix for HTML sites?

Proper heading hierarchy (H1>H2>H3), visible focus indicators, image alt text, and form labels. These four cover the majority of WCAG violations. Start with a SiteArmor scan to identify your specific issues.

Do I need to test with a real screen reader?

Yes. Automated tools catch ~35% of WCAG issues. Screen reader testing catches the rest. Use NVDA (free, Windows) with Firefox, or VoiceOver (built-in Mac/iOS) with Safari for testing.

Check your website for free

Get your ADA, WCAG, privacy & security score in 90 seconds.

No credit card

WCAG 2.1

ADA

Privacy