Web Accessibility (A11y): Semantic HTML, ARIA & WCAG

Accessibility (A11y)

Accessibility means building applications that everyone can use, including people who rely on screen readers, keyboard navigation, captions, or high contrast. It's a requirement in many jurisdictions — and it improves SEO and usability for all users along the way.

The good news: most accessibility comes free from writing semantic HTML and supporting the keyboard. ARIA and contrast tuning handle the rest. You don't need to memorize the spec to do 90% of the job well.

TL;DR

Start from semantic HTML — it carries accessibility for free.
Everything must work by keyboard, with a visible focus indicator.
Meet WCAG 2.1 AA: 4.5:1 text contrast, and never rely on color alone.
Use ARIA only when native elements can't express the semantics.
Test with automated tools and a keyboard and screen reader.

Quick Example

An accessible modal — the role, aria-modal, and a labelled title tell assistive tech what it is:

Core Concepts

Semantic HTML first

<button> for actions, <a> for navigation, real headings, lists, and landmark regions (<main>, <nav>). These bring keyboard behavior and screen-reader semantics automatically. See HTML Fundamentals.

WCAG and POUR

WCAG organizes accessibility into four principles — content must be Perceivable, Operable, Understandable, Robust — with conformance levels A, AA, AAA. AA is the standard target for most sites.

Focus management

Provide a visible focus ring, a logical tab order, focus trapping inside modals, and a "skip to content" link. Keyboard users navigate entirely by focus.

ARIA

ARIA adds semantics native HTML can't express (aria-label, aria-expanded, aria-live for dynamic announcements). The first rule of ARIA: don't use it if a native element does the job.

Best Practices

Build on semantic elements; reach for div/span last.
Ensure every interaction works without a mouse, with a clear focus state.
Hit 4.5:1 contrast for body text; pair color with text/icons so meaning isn't color-only.
Give images meaningful alt (or alt="" if decorative).
Announce dynamic changes with aria-live regions.

Testing

Automated tools catch ~30–40% of issues; the rest needs manual keyboard and screen-reader testing.

Common Mistakes

Fake buttons

Conveying meaning with color alone

FAQ

What WCAG level should I target?

AA. Level A is the bare minimum and AAA is often impractical for whole sites, so AA is the widely accepted legal and practical standard (it covers 4.5:1 text contrast, keyboard operability, and more).

Do I need ARIA if I use semantic HTML?

Mostly no. Native elements provide the roles and states ARIA would add. Use ARIA only for custom widgets or dynamic announcements that have no native equivalent — and never let ARIA contradict the underlying element.

How do I actually test accessibility?

Combine automated scanners (axe, Lighthouse) with manual testing: navigate the whole flow using only the keyboard, then with a screen reader. Automated tools miss things like logical focus order and meaningful labels.

Isn't accessibility just for a small group of users?

No — accessible design helps everyone: captions in noisy rooms, keyboard power users, voice control, aging eyes, and search engines. It overlaps heavily with good UX and SEO.