Essential web accessibility: WCAG in practice without dying trying

One in six people worldwide lives with a significant disability — and all of them browse websites designed by people who rarely kept them in mind. Accessibility isn't a feature "for later" nor a legal checkbox: it's the difference between your product working for everyone or silently excluding users with visual, motor, hearing or cognitive disabilities. The good news: 80% of the impact comes from a handful of habits.

Semantic HTML: free accessibility

The foundational mistake is using <div> and <span> for everything. Every semantic element ships built-in accessible behavior:

<!-- WRONG: a div dressed as button isn't keyboard-navigable nor announced -->
<div class="btn" onclick="send()">Send</div>

<!-- RIGHT: Tab focus, Enter/Space work, screen readers announce it -->
<button type="submit">Send</button>

The div-button must reimplement everything <button> gifts you: role, tabindex, key handling, screen reader announcement, states. Equivalent structure rules:

• <header>, <nav>, <main>, <footer> delimit navigable regions.
• Single <h1> and heading hierarchy without skips — screen reader users navigate jumping heading to heading.
• <label for> bound to every input: clicking focuses, readers announce the field name.
• Real <table> with <th> for tabular data; <ul>/<ol> lists for real lists.
• Descriptive alt on informative images; empty alt="" on decorative ones (being ignored is correct).

Keyboard first

Many motor-disability users go keyboard-only (or switch devices). The most cost-effective test ever: unplug the mouse and walk your site.

• Every interactive element reachable via Tab in logical order (DOM order rules: if visual order differs, something breaks).
• Visible focus indicator: never outline: none without replacement. If default outline looks ugly, design a better one (:focus-visible).
• Modals trapping focus while open, returning it on close.
• Skip link ("Skip to content") as first focusable element.
• Shortcuts not hijacking browser keys.

If a custom component (dropdown, tabs, accordion) doesn't work by keyboard, either use native (<select>, <details>) or implement WAI-ARIA Authoring Practices patterns — that's when reading them is warranted.

Contrast: the measurable metric

WCAG mandates minimum contrast ratios between text and background:

• 4.5:1 normal text (< 18pt)
• 3:1 large text (≥ 18pt or 14pt bold) and UI components (input borders, icons)
• 7:1 AAA for normal text

That light gray on white looking "elegant" usually sits around 2:1 — illegible for low vision, hard for everyone under sunlight. Convert your colors and check the ratio with our color tool before approving a palette; if generating combinations from scratch, pick harmonious contrasted palettes.

Two sibling rules: never convey information through color ALONE (the classic "red fields are wrong" fails for color-blind users — add icon/text), keep touch targets ≥ 44×44 px on mobile.

ARIA: seasoning, not the meal

ARIA (Accessible Rich Internet Applications) adds semantics where native HTML can't reach:

<div role="alert">Error saving the form</div>
<button aria-expanded="false" aria-controls="menu">Menu</button>
<nav aria-label="Main">

But its famous first rule: the first rule of ARIA is don't use ARIA when a native element exists. A <button role="button"> is redundant; a <div role="button" tabindex="0"> without Space/Enter handling is broken. The attributes earning honest use:

• aria-label / aria-labelledby: naming controls without visible text (icon buttons).
• aria-expanded, aria-current, aria-selected: dynamic states.
• aria-live="polite": announcing async updates (search results, toast notifications).
• role="alert": urgent messages interrupting reader flow.

And beware over-labeling: each wrong aria-label is worse than none.

Forms: where everything is won or lost

Most transactions die in inaccessible forms:

1. Always-visible labels (placeholder-as-only-label disappears while typing — working memory punished).
2. Errors next to the field, linked via aria-describedby and announced on submit.
3. Correct autocomplete (email, new-password, postal-code): less typing, happy password managers.
4. Tolerant validation: don't erase input on error; indicate where and what failed.
5. Warned and extendable timeouts in long flows.

Auditing without spending

Free stack sufficient to start:

• Lighthouse (DevTools): basic automated audit with concrete points.
• axe DevTools: extension detecting technical violations remarkably precisely.
• Manual keyboard navigation: irreplaceable — no tool catches "this modal traps focus wrong".
• Screen reader: NVDA (Windows, free) or VoiceOver (built into Mac/iOS). Listening to your site for 10 minutes changes how you build layouts forever.

Automated tools catch ~30-40% of issues; the rest requires human judgment. Use them as radar, not verdict.

FAQ

Does accessibility affect SEO? Positively: semantic HTML, heading hierarchy, alt texts and performance are shared signals. Google and screen readers reward similar structures.

Is it legally mandatory? Depends on jurisdiction and sector: in the EU, the European Accessibility Act (applicable since June 2025) binds e-commerce and key digital services; in the US, ADA has generated massive litigation. For European B2C it's no longer optional.

How much does accessibility cost in new projects? Marginal if done from design (semantics + contrast + labels nearly free). Retroactively it can mean rebuilding entire components — another reason to do it from minute one.

Check your palette's contrasts with our color converter, free and right in your browser.