Most accessibility advice falls into two camps: legal checklists nobody reads, and earnest-but-impractical "design for everyone" platitudes. This is the pragmatic middle — what actually matters for real users, in priority order.

The principle

Accessibility is mostly about not being lazy. Most a11y bugs come from skipping basic semantic HTML, not from failing to implement complex ARIA patterns. Fix the basics and you've covered 80% of what matters.

Tier 1: Things you absolutely must do

These are non-negotiable. Skipping any of them produces a site that excludes real users.

Use semantic HTML

Buttons are <button>. Links are <a>. Headings are <h1> through <h6> in document order. Lists are <ul> or <ol>. Forms have <label> elements. This alone solves more a11y problems than every ARIA workaround combined.

Keyboard navigation

Every interactive element must be reachable and operable by keyboard. The Tab order should be logical. Visible focus indicators on every interactive element. Test with the keyboard yourself — actually use the site without a mouse for ten minutes.

Form labels and errors

Every form input has an associated <label>. Error messages are programmatically associated with their inputs via aria-describedby. Errors don't rely on colour alone.

Alt text

Every meaningful image has alt text. Decorative images have alt="". This is 30 seconds of work per image. Do it.

Colour contrast

Text on background needs 4.5:1 contrast ratio for body, 3:1 for large text. Use a tool to check. Don't eyeball it.

Tier 2: Things you should do

These take more effort but make the experience noticeably better for many users.

Skip links

A "Skip to main content" link as the first focusable element. Five lines of HTML and CSS, saves keyboard users from tabbing through the navigation on every page.

Landmark regions

Use <header>, <nav>, <main>, <footer>. Screen readers use these to navigate the page.

Heading hierarchy

One <h1> per page. No skipped levels (don't go from <h2> straight to <h4>). Screen reader users navigate by headings.

Motion preferences

Respect prefers-reduced-motion. Disable or reduce animations for users who request it. One CSS media query.

Tier 3: Things that matter for some users

These cover more specialised needs.

ARIA, used sparingly

ARIA is for components that semantic HTML can't express — custom tab panels, comboboxes, complex disclosures. Use it only when semantic HTML genuinely doesn't fit. Wrong ARIA is worse than no ARIA.

Live regions

For UI that updates asynchronously (notifications, real-time data, form validation results), use aria-live="polite" so screen readers announce the change.

Focus management for SPAs

When the route changes in a single-page app, move focus to the main content. Don't leave focus on the now-replaced link.

Testing

  • Manual keyboard testing. Tab through your site. Can you reach everything? Can you operate everything?
  • Screen reader testing. VoiceOver on Mac, NVDA on Windows. You don't need to be expert — just check that your site is navigable and your content is announced.
  • Automated tools. axe-core, Pa11y, Lighthouse. They catch a subset of issues — useful but not sufficient.
  • Real user testing. If your product matters to a wider audience, test with actual assistive technology users.

What doesn't matter as much as the checklist suggests

  • Obsessing over WCAG conformance levels (AAA is overkill for most sites; AA is the right target).
  • Adding ARIA roles to elements that already have the right semantic HTML.
  • Implementing every keyboard pattern in the ARIA Authoring Practices Guide.

The summary

If you ship semantic HTML, keyboard-operable interfaces, proper form labels, alt text, and adequate colour contrast, you've solved 80% of accessibility for 80% of users. Everything beyond that is incremental improvement on a solid base. The mistake is doing the incremental improvements before the foundation.