DEV Community

Cover image for 8 Accessibility Issues We Found During a Next.js Audit
Nana Okamoto
Nana Okamoto

Posted on

8 Accessibility Issues We Found During a Next.js Audit

#webdev #nextjs #frontend #a11y

Accessibility is often discussed as a checklist of WCAG requirements, but in real projects, the challenge is identifying issues that affect actual users and integrating fixes into an existing codebase.

Recently, I conducted an accessibility audit for a Next.js application and worked through a number of issues across multiple pages and reusable components. In this article, I'd like to share some of the most common problems we found and how we addressed them.

Why We Conducted an Accessibility Audit

Our goal was to improve the experience for keyboard users, screen reader users, and anyone who relies on assistive technologies.

To evaluate the application, we used:

  • Lighthouse
  • axe DevTools
  • Manual keyboard testing
  • Screen reader testing

While automated tools were useful, many of the most impactful issues were discovered through manual testing.

1. Incorrect Heading Structure

Problem
Some pages skipped heading levels.

<h1>Property Listings</h1>
<h3>Featured Properties</h3>
Enter fullscreen mode Exit fullscreen mode

This can make page navigation difficult for screen reader users.

Solution

<h1>Property Listings</h1>
<h2>Featured Properties</h2>
Enter fullscreen mode Exit fullscreen mode

Maintaining a logical heading hierarchy improves page structure and navigation.

2. Icon-Only Buttons Without Accessible Names

Problem
Some buttons relied entirely on icons.

<button>
  <SearchIcon />
</button>
Enter fullscreen mode Exit fullscreen mode

Screen readers announced these as simply "button."

Solution
We added accessible labels.

<button aria-label="Search">
  <SearchIcon />
</button>
Enter fullscreen mode Exit fullscreen mode

Now screen reader users understand the purpose of the control.

3. Duplicate Alternative Text

Problem
In several cards, an image and adjacent text conveyed the same information.

<img alt="English Bay Beach" />
<h2>English Bay Beach</h2>
Enter fullscreen mode Exit fullscreen mode

The screen reader would announce the location name twice.

Solution
When the image was decorative or redundant, we used an empty alt attribute.

<img alt="" />
Enter fullscreen mode Exit fullscreen mode

This reduced unnecessary repetition.

4. Generic "Read More" Links

Problem
Many article cards used generic link text such as:

<a href="/article/123">Read More</a>
Enter fullscreen mode Exit fullscreen mode

While visually understandable, screen reader users often navigate using a list of links. Hearing multiple "Read More" links provides little context about their destination.

Solution
We preserved the existing design and added screen-reader-only text:

<a href={href}>
  Read More
  <span className="sr-only">
    about Canadian study permits
  </span>
</a>
Enter fullscreen mode Exit fullscreen mode

Now screen readers announce a more descriptive link while the visual UI remains unchanged.

5. Missing Skip Navigation Link

Problem
Keyboard users had to tab through the entire header navigation on every page before reaching the main content.

Solution
We introduced a skip link.

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

This allows keyboard users to jump directly to the primary content.

6. Missing Language Information

Problem
Our application supported multiple languages, but some content contained text in a different language without specifying its language.

<p>English</p>
Enter fullscreen mode Exit fullscreen mode

When viewed on the Japanese version of the site, screen readers pronounced the word using Japanese pronunciation rules, making it difficult to understand.

We also found addresses and slogans written in English within otherwise Japanese pages.

Solution
We added the lang attribute to text that differed from the page's primary language.

<p lang="en">English</p>
Enter fullscreen mode Exit fullscreen mode

This allows screen readers to switch pronunciation rules automatically and improves comprehension for multilingual users.

7. Focus Management After SPA Navigation

Problem
Because the application used client-side routing, page transitions did not always provide a clear indication that the content had changed.
Keyboard and screen reader users could lose track of their current position.

Solution
After navigation, focus was moved to the page heading.

<h1 tabIndex={-1}>Property Listings</h1>
Enter fullscreen mode Exit fullscreen mode

The heading becomes focusable and can receive focus after route changes.
This is one of the most commonly overlooked accessibility issues in modern React applications.

8. Hover-Only Content

Problem
Additional information was displayed only on mouse hover.

<Tooltip>
  More information
</Tooltip>
Enter fullscreen mode Exit fullscreen mode

Keyboard and touch users could not access the content.

Solution
We ensured that the content became visible when the trigger element received keyboard focus, not just on hover.
This allowed keyboard users to access the same information as mouse users.

Lessons Learned

One of the biggest takeaways from this audit was that accessibility issues are rarely isolated.

A missing heading, unclear link text, or improper focus management may seem minor individually, but together they can significantly impact the user experience.

Perhaps the most surprising finding was that several issues were invisible to automated tools and only became apparent during keyboard and screen reader testing.

Another important lesson was that automated tools only catch part of the problem. Keyboard navigation and screen reader testing revealed issues that Lighthouse and axe could not identify on their own.

Accessibility is not just about compliance. It improves usability, structure, and overall product quality for everyone.

Final Thoughts

If you're working on a Next.js or React application, I recommend starting with a small audit of a few critical user flows.

Focus on:

  • Headings
  • Keyboard navigation
  • Link text
  • Form labels
  • Focus management
  • Modal behavior

You may be surprised by how many issues can be discovered in just a few hours.

Top comments (0)