Accessible websites: ARIA, focus and keyboard use

In short: Accessible pages can be fully operated with keyboard and screen reader; the key rule is to use the right HTML elements first and add ARIA only where HTML is not enough.

In more detail: People use websites with screen readers, keyboard only, voice control or magnified. Accessibility also helps everyone else: in bright sunlight, with a broken arm or in noise.

In Depth

Semantic HTML first

• <button> for actions, <a href> for navigation, not <div onclick>.
• Headings <h1> to <h6> in logical order; regions with <nav>, <main>, <header>, <footer>.
• Forms with <label for>; images with a meaningful alt (decorative: alt="").
• Tables with <th> and scope. A real <button> brings keyboard handling, focus and role for free.

Keyboard and focus

• Everything operable must be reachable with Tab, Enter/Space and arrow keys.
• Visible focus ring (:focus-visible); never just set outline: none.
• Order follows the source; use tabindex="0" sparingly, avoid positive values.
• Dialogs: move focus in, keep it inside, close with Esc, then return to the trigger.
• Skip link (“Skip to content”) at the very top.

Using ARIA correctly

ARIA (Accessible Rich Internet Applications) adds roles and states: aria-label, aria-expanded, aria-live (status messages), role="dialog". Rules: No ARIA is better than bad ARIA. ARIA changes only what assistive technology announces, not behaviour; you must build keyboard handling yourself. Announce new content (error messages, toasts) in a live region.

Testing

• Click through with the keyboard only.
• Try a screen reader (NVDA, VoiceOver, TalkBack).
• Check contrast (WCAG: 4.5:1 for text).
• Tools: Lighthouse, axe; they find roughly 30–40% of problems, the rest needs people.
• Legally relevant: the German Barrierefreiheitsstärkungsgesetz (BFSG) for many digital offerings from 28 June 2025.

See also: WCAG and colour contrast, Screen readers and assistive technologies, Lighthouse and Core Web Vitals