Web Accessibility: Keyboard, ARIA and Contrast Guide

Web accessibility means building an interface that people with visual, auditory, motor or cognitive differences can use without friction. Many developers treat it as a legal box to tick or an “extra” bolted on at the end. In reality, accessibility is a core practice that — when done right from the start — also improves your code quality, SEO and overall usability. This guide focuses on the three areas that make the biggest difference: keyboard navigation, correct ARIA use and colour contrast.

Why accessibility is a baseline, not a bonus

A significant share of people live with a permanent or temporary disability, but accessibility isn’t only for them. A screen glaring in the sun, a broken mouse, a muted video, tired eyes — everyone browses in a “disabled” context sometimes. An accessible site helps screen reader and keyboard users while also giving search engines a more meaningful structure.

• Semantic HTML handles about 80% of the work: the right tag does the right job.
• WCAG (Web Content Accessibility Guidelines) gives you a measurable target; most organisations use level AA as their reference.
• Accessible code tends to be more robust and easier to maintain.

Semantic HTML: the foundation of accessibility

The most common mistake is building everything from <div> and <span>. The browser doesn’t know a <div> is clickable, and a screen reader won’t announce it. Using the right element gives you keyboard behaviour, focus management and screen reader announcements for free.

<!-- Bad: accessibility must be added by hand -->
<div class="btn" onclick="save()">Save</div>

<!-- Good: keyboard, focus and role come built in -->
<button type="button" onclick="save()">Save</button>

The same logic applies to <nav>, <main>, <header>, <footer> and form controls. Every <input> should be tied to a <label>:

<label for="email">Email</label>
<input id="email" type="email" name="email">

Keyboard navigation: it must work without a mouse

Testing an interface with the keyboard is the fastest accessibility check there is. Move forward with Tab and back with Shift+Tab: can you reach every link, button and form field? Is the focus visible?

• Never remove the focus ring with outline: none. If it clashes with your design, style it nicely using :focus-visible.
• Use DOM order for a logical sequence and avoid positive tabindex values. Only tabindex="0" (add to tab order) and tabindex="-1" (programmatic focus) are needed.
• When a modal opens, trap focus inside it, and return focus to the triggering button when it closes.

/* A clear focus ring only for keyboard users */
:focus-visible {
  outline: 2px solid #4f46e5;
  outline-offset: 2px;
}

A skip link is also a big help for keyboard users:

<a class="skip-link" href="#main">Skip to content</a>
...
<main id="main"> ... </main>

ARIA: less is more

ARIA (Accessible Rich Internet Applications) exists to communicate states to screen readers that HTML alone can’t express. But the golden rule is clear: no ARIA is better than bad ARIA. A wrong role or a wrong state breaks otherwise correct semantic HTML.

• If a native HTML element does the job, don’t add ARIA: role="button" on a <button> is redundant.
• Give icon buttons without text an accessible name: aria-label="Open menu".
• Announce state: aria-expanded="true/false" on a dropdown, aria-selected on the active tab.
• Announce live updates with aria-live="polite" (a form error message, for example).

<button aria-label="Open menu" aria-expanded="false" aria-controls="menu">
  <svg aria-hidden="true"> ... </svg>
</button>
<ul id="menu" hidden> ... </ul>

For purely decorative images, leave alt="" or use aria-hidden="true" so screen readers skip them. For meaningful images, a descriptive alt text is essential.

Colour and contrast: readability for everyone

Low contrast is the most common and most easily fixed accessibility issue. WCAG level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18.66px bold or 24px). UI components and graphical elements should also aim for 3:1.

• Your browser DevTools show the contrast ratio and AA/AAA status when you select text.
• Never convey information by colour alone. Instead of “the red field is invalid,” add an icon, text or pattern — critical for colour-blind users.
• Distinguish links with a second cue, such as an underline or bold weight, not just colour.
• Reduce animations for motion-sensitive users with prefers-reduced-motion.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Testing: tools and humans together

Automated tools catch only a fraction of issues; the rest needs real experience.

• Run a quick scan with Lighthouse or axe DevTools.
• Navigate the whole page with the keyboard: are you ever trapped?
• Try a screen reader: VoiceOver on macOS and NVDA on Windows are both free.
• Zoom the page to 200%; does the content reflow without breaking?

Frequently Asked Questions

Should I target WCAG AA or AAA?

For most projects, level AA is the practical and widely accepted target, and many legal frameworks reference it too. AAA is very strict on some criteria and isn’t realistic for every piece of content, but it’s nice to apply where you can.

Can ARIA replace semantic HTML?

No. ARIA only enriches meaning where HTML falls short; it adds no behaviour. Even if you give a <div> a role="button", you still have to wire up keyboard events and focus yourself. The right element is always safer.

Does accessibility help SEO?

Yes. Semantic structure, alt text, a logical heading hierarchy and clearly readable content give the same clarity to screen readers and search engines alike; the two overlap heavily.

An accessible interface is simply a better interface. If you’d like to review your site for keyboard, ARIA and contrast issues, or build it accessibly from the start, get in touch with me.