Web Accessibility Guide: ARIA, Keyboard Navigation & Color

Here’s a truth bomb: most of us build for people like us—folks with decent vision, working mice, and fast internet. But the web isn’t just for us.

When I started taking accessibility seriously (and not just as a “nice-to-have” checkbox), my perspective shifted completely. It’s not about charity or compliance—it’s about building stuff that actually works for real humans in real situations.

This is part 1 of a multi-part series where I’ll break down what I’ve learned about web accessibility. We’ll cover the fundamentals: ARIA, keyboard navigation, and visual design. In part 2, we dive into forms specifically.

Let’s get into it.

Understanding Accessibility

Web accessibility means building sites that work for everyone—including people with visual, auditory, motor, or cognitive disabilities.

The WCAG (Web Content Accessibility Guidelines) breaks this down into four key principles:

The Four Principles (POUR)

Perceivable: Information must be presentable in ways users can perceive.

• Provide text alternatives for images
• Ensure sufficient color contrast
• Add captions for videos and audio

tip

Clear layouts aren’t just for screen readers—they help everyone, especially on mobile or in bright sunlight.

Operable: Users must be able to navigate and interact with the interface.

• Support keyboard navigation (Tab, Enter, Space)
• Allow various input methods (voice, touch, switch devices)
• Give users enough time to read and interact
• Avoid content that causes seizures (rapid flashing)

Understandable: Information and interface operation must be clear.

• Use simple, consistent language
• Make navigation predictable
• Provide clear error messages and instructions

Robust: Content must work with current and future technologies.

• Follow web standards
• Ensure compatibility with assistive technologies
• Use semantic HTML that works everywhere

Getting Started with ARIA

ARIA (Accessible Rich Internet Applications) is a set of attributes that adds semantic information to HTML, helping assistive technologies understand what your code does.

Think of ARIA as annotations for screen readers. You’re telling them “this div is actually a button” or “this section contains the main content.”

important

First rule of ARIA: Don’t use ARIA. Use semantic HTML first (<button>, <nav>, <main>), and only add ARIA when HTML alone isn’t enough.

Common ARIA Roles and Properties

Landmark Roles help users navigate by defining page regions:

<header role="banner">Site header</header>
<nav role="navigation">Main menu</nav>
<main role="main">Main content</main>
<aside role="complementary">Sidebar</aside>
<footer role="contentinfo">Site footer</footer>

tip

Modern semantic HTML elements like <nav> and <main> have implicit roles, so you often don’t need to add them explicitly.

Live Regions announce dynamic content changes:

<div aria-live="polite">Loading results...</div>
<div aria-live="assertive" role="alert">Error: Invalid email</div>

Use polite for non-urgent updates (they’ll wait until the user is idle) and assertive for urgent messages that need immediate attention.

States and Properties convey additional information:

<button aria-expanded="false" aria-controls="menu">Menu</button>
<input aria-invalid="true" aria-describedby="error-msg">
<span id="error-msg">Please enter a valid email</span>

ARIA Best Practices

• HTML first, ARIA second: Native HTML elements are battle-tested and work everywhere
• Don’t break native semantics: Adding role="button" to a <button> is redundant
• Test with real screen readers: NVDA (Windows), JAWS (Windows), VoiceOver (Mac/iOS)
• Keep it simple: More ARIA doesn’t mean better accessibility

Keyboard Navigation

If you can’t use your site with just a keyboard, it’s broken for a huge chunk of users.

Power users love keyboard shortcuts. People with motor disabilities need them. And honestly? Sometimes your trackpad dies and you’re stuck with just the keyboard anyway.

Essential Keyboard Patterns

Tab navigation is your bread and butter:

• Tab - Move forward through interactive elements
• Shift+Tab - Move backward
• Enter - Activate buttons and links
• Space - Activate buttons, toggle checkboxes
• Arrow keys - Navigate within components (dropdowns, sliders, tabs)
• Esc - Close modals and menus

Focus management is critical. Users need to know where they are:

/* Don't do this */
*:focus {
  outline: none; /* Please don't */
}

/* Do this instead */
*:focus-visible {
  outline: 2px solid #4A90E2;
  outline-offset: 2px;
}

important

The :focus-visible pseudo-class shows focus indicators only for keyboard users, not mouse clicks. Best of both worlds.

Skip links let users bypass repetitive content:

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

<main id="main-content">
  <!-- Your content -->
</main>

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px;
  text-decoration: none;
}

.skip-link:focus {
  top: 0;
}

The skip link is visually hidden until focused, then appears at the top of the page.

Testing Your Keyboard Navigation

Unplug your mouse (seriously) and try using your site. Can you:

• Navigate to every interactive element?
• See where focus is at all times?
• Activate all buttons, links, and form controls?
• Open and close modals and menus?
• Complete forms without frustration?

If any of these are painful, your keyboard users are having a bad time.

Color Contrast and Visual Design

One mistake I see all the time: beautiful designs with terrible contrast. That gorgeous light gray text on a white background? Your users are squinting.

Understanding Contrast Ratios

WCAG 2.2 defines minimum contrast ratios:

• Normal text (under 18pt): Minimum 4.5:1 (AA level), 7:1 for AAA
• Large text (18pt+ or 14pt+ bold): Minimum 3:1 (AA level), 4.5:1 for AAA
• UI components and graphics: Minimum 3:1

tip

AA is the standard most organizations aim for. AAA is great but can be challenging to achieve while maintaining brand aesthetics.

Check Your Contrast

Browser dev tools have built-in contrast checkers now. In Chrome DevTools:

1. Inspect an element
2. Look at the color picker
3. You’ll see AA and AAA indicators right there

For a quick check, use the WebAIM Contrast Checker.

Beyond Color: Don’t Rely on Color Alone

About 8% of men and 0.5% of women have some form of color blindness. If your error messages are just red text, some users won’t notice them.

Do this instead:

• Combine color with icons (red X icon + “Error”)
• Use text labels (“Required” not just a red asterisk)
• Add patterns or textures to charts and graphs
• Underline links instead of just changing their color

bonus

Designing for color blindness often improves the experience for everyone—like how curb cuts help people with strollers, not just wheelchairs.

The Bottom Line

Accessibility isn’t a feature you bolt on at the end. It’s a fundamental part of building for the web.

Start small: add proper ARIA labels, make sure your site works with just a keyboard, check your color contrast. Each improvement makes your site better for everyone, not just users with disabilities.

In part 2 of this series, we’ll dive deep into building accessible forms—probably the most important (and most commonly broken) part of web accessibility.

bonus

Additional Resources:

• WCAG Guidelines: The WCAG 2.2 Quick Reference is your comprehensive accessibility resource.
• Learning: WebAIM and The A11y Project offer excellent guides and checklists.
• Testing: Test with real screen readers (NVDA, JAWS, VoiceOver) and keyboard-only navigation.