Skip to content
User Experience Accessibility

WCAG Accessibility 5: Keyboard Navigation & Focus Management

 
In this fifth post in our WCAG accessibility series, we focus on keyboard accessibility — a critical requirement for users who cannot use a mouse.

In the previous post, we focused on improving colour contrast to enhance readability and visual accessibility.

In this post, we look at keyboard navigation and how ensuring full keyboard access improves usability for all users.

Read WCAG Accessibility 4: Fixing Colour Contrast Issues

 

Ensuring that a website is fully usable via keyboard is a core part of WCAG 2.2 Level AA compliance. It benefits users who rely on assistive technologies, as well as power users who prefer keyboard navigation.

As part of our work on the Rainbows Ireland website, we reviewed and improved keyboard navigation across all key user journeys.

WCAG requires that all functionality is accessible using a keyboard alone, without requiring a mouse.
 

Why Keyboard Accessibility Matters

 
Many users rely on keyboards instead of a mouse, including:

  • Users with motor impairments
  • Screen reader users
  • Users with temporary injuries
  • Power users who navigate quickly using the keyboard

WCAG requires that all functionality is operable through a keyboard interface without requiring specific timings.
 

Issues Identified on the Rainbows Website

 
   During testing, we identified several keyboard accessibility issues that affected usability and navigation.

  • Missing or unclear focus indicators
  • Interactive elements not reachable via the keyboard
  • Inconsistent tab order across pages
  • Hidden elements receiving focus unexpectedly
  • Popup forms that trapped keyboard users

WCAG Rainbows 18

Figure 17: Final WAVE result showing a score of 9.9 out of 10 with the main homepage accessibility issues resolved.

How We Tested Keyboard Navigation

 
We carried out manual testing using only the keyboard, including:

  • Using the Tab key to move forward through interactive elements
  • Using Shift + Tab to move backwards
  • Using Enter and Space to activate buttons and links
  • Ensuring all menus, forms, and controls were accessible
     

How We Fixed the Issues

1. Restoring Visible Focus Indicators

 
Some focus outlines had been removed or overridden by the theme. We reinstated clear, visible focus styles to ensure users can always see where they are on the page.

:focus {
  outline: 3px solid #005ea5;
  outline-offset: 2px;
}


2. Fixing Tab Order


We ensured that the tab order follows a logical sequence that matches the visual layout of the page.

This involved removing incorrect tabindex values and relying on natural DOM structure wherever possible.
 

3. Making Interactive Elements Accessible

 
All buttons, links, and form controls were reviewed to ensure they could be accessed and activated using the keyboard.

  • Clickable divs were replaced with proper button elements
  • ARIA roles were used where appropriate
     

4. Fixing Focus Traps in Popups

 
Some popup forms prevented users from navigating away using the keyboard.

We ensured that:

  • Focus is correctly moved into modals when opened
  • Focus is returned to the triggering element when closed
  • Users can exit modals using the keyboard (e.g. Escape key)
     

5. Removing Hidden Focusable Elements

 
We identified elements that were visually hidden but still accessible via keyboard navigation, causing confusion for users.

These were corrected by properly managing visibility and focusability.
 

Key Takeaways

  • Keyboard accessibility is essential for inclusive design
  • Focus indicators must always be visible
  • Logical tab order improves usability for all users
  • Proper HTML structure reduces the need for complex fixes
     

Next Steps

 
In the next post, we’ll look at improving ARIA roles and semantic structure to enhance accessibility further.

Recent Posts