Building accessible websites: keyboard, semantics and ARIA

In short: Accessible pages can be used with keyboard, screen reader and low vision. Most of it is achieved by clean HTML, not extra code.

1. Semantic HTML

Real elements bring behaviour and meaning:

• <button> instead of <div onclick> (keyboard, focus and role are built in).
• <a href> for links, <nav>, <main>, <header>, <footer>, <h1> to <h6> in a sensible order.
• <label for="…"> for every input field.
• Lists as <ul>/<ol>, tables with <th>.

2. Keyboard

Everything must work without a mouse: Tab through, Enter/Space trigger, Esc closes dialogs. The focus must be visible (never outline: none without a replacement). Dialogs hold the focus until they close.

3. Alternative text and contrast

• Images: alt="…" describes the content, for pure decoration alt="".
• Colour contrast at least 4.5:1 for text, see WCAG and colour contrast. Never convey information only by colour.
• Text must be enlargeable (up to 200%) without losing anything.

4. ARIA, but sparingly

ARIA supplements where HTML is not enough (aria-label, aria-expanded, role="dialog", aria-live for status messages). The first rule: no ARIA is better than wrong ARIA. Where a suitable HTML element exists, use it.

5. Testing

Click through with the keyboard, zoom the page to 200%, try a screen reader (NVDA, VoiceOver); tools such as Lighthouse or axe add to it but find only part of the errors.

Law

Since 2025 the Accessibility Strengthening Act (BFSG) applies to many offers.

See also: UX