In Part 1 of this series, we explored how Next.js provides React developers a strong starting point for accessibility (A11Y), with built-in features such as semantic routing, head management, and linting. Here in Part 2, we’ll go beyond the framework to real-world development practices and demonstrate how tools like axe DevTools can help you validate real-world usability.

By “inclusive development practices,” we mean modern development techniques that ensure that applications are built accessible from the start—integrated into the design and code, rather than bolted on later or left for post-production fixes.

We’ll cover practical ways to implement accessibility at the code level, including proper use of semantic HTML, alt text, ARIA roles, and keyboard support. Below are some best practices and code examples to help you develop apps that are inclusive by design.

Create with semantic HTML

Swapping a generic <div> for a more meaningful element such as <header>, <nav>, <main>, or <section> is a simple way to improve accessibility without adding complexity. These tags help screen readers and other assistive technologies understand how your page is structured, making it easier for users to navigate.

Semantic markup increases accessibility and also makes your code cleaner and easier to maintain.

<nav>
  <ul>
    <li>
      <Link href="/">Home Page</Link>
    </li>
    <li>
      <Link href="/about">About Us</Link>
    </li>
  </ul>
</nav>

By choosing the right element for the job, you support better experiences for everyone without having to write extra code.

Ensure keyboard accessibility

Make sure every interactive element in your app functions properly for keyboard users, from navigating links to activating buttons. This means managing focus properly, maintaining a logical tab order, and using event handlers that support both mouse and keyboard input.

Native HTML elements such as <button> already support keyboard interactions out of the box. But if you’re building a custom interactive component (such as a <div> acting as a button), you need to manually support keyboard events like Enter, Space, or even arrow keys for navigation.

Here’s an example of how to make a custom component keyboard-accessible:

'use client'
import { useRef } from 'react';

export const MyComponent = () => {
  const divRef = useRef(null);

  const handleClick = () => {
    // Your click handler code here
  };

  const handleKeyDown = (event) => {
    if (event.key === 'Enter' || event.key === ' ') {
      event.preventDefault(); 
      divRef.current.click();
    } else if (event.key === 'ArrowLeft') {
      // Handle left arrow navigation
    } else if (event.key === 'ArrowRight') {
      // Handle right arrow navigation
    }
  };

  return (
    <div
      ref={divRef}
      role="button"
      tabIndex={0}
      onClick={handleClick}
      onKeyDown={handleKeyDown}
    >
      Learn More
    </div>
  );
};

This pattern ensures keyboard users get the same interactive experience as mouse users—especially when you’re building components from scratch.

Leverage ARIA roles and attributes

When semantic HTML doesn’t cover a specific use case, you can fill in the gaps with ARIA roles and attributes. Use them thoughtfully—they’re powerful tools but not substitutes for semantic markup. ARIA, when implemented poorly, can be a barrier rather than a path to accessibility.

<nav>
  <ul role="menu">
    <li role="menuitem">
      <Link href="/">Home Page</Link>
    </li>
    <li role="menuitem">
      <Link href="/about">About Us</Link>
    </li>
  </ul>
</nav>

By applying roles such as menu and menuitem, you give screen readers the context they need to interpret complex or custom navigation structures. Just remember: the best accessibility often starts with native HTML. Use ARIA when needed as a complement, not as a replacement.

Add alt text for media

You can make your content far more inclusive simply by adding descriptive text to your images and captions to your media. Every image should include an alt attribute that communicates its purpose. If the image is decorative, use alt=”” to let assistive technologies skip it.

<Image
  src="/wilson.jpg"
  width={450}
  height={450}
  alt="a wilson volleyball with a red handprint with a face on it"
/>

For videos or audio, you can include captions or subtitles to support users who are deaf or hard of hearing:

<video controls>
  <source src="/helloWorld.mp4" type="video/mp4" />
  <track kind="subtitles" src="/subtitles-en.vtt" label="English" />
</video>

By taking these simple steps, you’re actively making your content more accessible to everyone, regardless of how they experience the web.

Integrate localization

If your audience spans multiple languages or regions, Next.js makes localization easier with built-in support for automatic locale-based routing and language negotiation.

By integrating a localization library such as next-i18next or react-intl, you can deliver content that respects your users’ language preferences and make your app feel more human in the process.

Focus on performance and accessibility together

Performance and accessibility go hand in hand, and with features such as server-side rendering (SSR), automatic code splitting, and route-based prefetching, you can use Next.js to ensure your app loads faster and responds smoothly.

By optimizing performance, you’re creating an app that is easier to navigate for users of assistive technology and those with slower network connections. Building with both speed and inclusivity in mind helps create a better experience for everyone.

Test with accessibility tools

You can catch many common accessibility issues early by using automated testing tools. Libraries such as React Testing Library with Jest make it easy to validate accessible patterns in your components:

import { render, screen } from '@testing-library/react';
import MyComponent from './MyComponent';

test('needs to be accessible', () => {
  render(<MyComponent />);
  expect(screen.getByRole('button')).toBeVisible();
});

Building accessibility into your test suite means it’s part of your everyday workflow, making it easier to catch issues early and deliver more inclusive features with confidence.

Write tests with axe DevTools for browser JavaScript

If you’re using axe DevTools for Web, you can go even further by programmatically testing for accessibility violations within your browser-based JavaScript tests.

Once you’ve installed and initialized the axe DevTools browser package, you can scan any rendered component for accessibility issues. Here’s a basic example:

test('Component has no accessibility violations', (done) => {
  const { container } = render(<Badcomp />);
  axeDevTools.run(container, (err, results) => {
    expect(results.violations.length).toBe(0);
    done();
  });
});

This test uses the run() method from @axe-devtools/browser to scan the rendered DOM and verify that there are no violations. It’s a fast, reliable way to enforce accessibility standards across your component library or app.

Need a full example? Here’s a full test file to get started:

import React from 'react';
import Badcomp from '../components/badcomp';
import { render } from '@testing-library/react';
import axeDevTools from '@axe-devtools/browser';
import "babel-polyfill";

describe('Bad Component', () => {
  beforeEach((done) => {
    axeDevTools.init('wcag2', () => done());
  });

  test('Component has no accessibility violations, w/ attest reporter', (done) => {
    const { container } = render(<Badcomp />);
    axeDevTools.run(container, (err, results) => {
      expect(results.violations.length).toBe(0);
      done();
    });
  });
});

Once you’ve got the basics in place, you can expand your tests with custom rules, integrate reporting, or work directly with the results object for deeper insights.

Use the axe DevTools Extension

Even with Next.js, some accessibility issues will slip through, especially the trickier, context-specific ones that frameworks can miss. That’s where the axe DevTools Extension can help.

By adding it to your browser, you can scan your pages, spot issues visually, and zero in on exactly what needs fixing—all powered by axe-core, the engine trusted by industry leaders.

You can catch most common accessibility issues right out of the box. And when you’re ready, you can upgrade to axe DevTools Pro and get AI-powered features including Intelligent Guided Tests, which further boost your coverage. You’ll also benefit from features such as component-level testing, exportable reports, Jira integration, and more.

Make digital accessibility part of your workflow from day one

When you design with accessibility in mind from the outset, you make your product usable for everyone, including people with disabilities. You also avoid the cost and complexity of retrofitting later, when fixes are harder and less effective.

This early, proactive approach is part of a broader development strategy known as shifting left, which means moving digital accessibility testing earlier in your workflow, right alongside your other quality checks. In our next article, we’ll delve into what shifting left means for digital accessibility and how it can transform your development process.

This is why Next.js offers such a solid start for React developers to build upon. It encourages developers to add accessibility to their repertoire. Whether it’s linting semantic HTML, announcing route changes, or managing metadata properly, the framework gives you guardrails to build more inclusively from the start.

Yet frameworks don’t build apps—developers do. As a developer, you have the ability and the opportunity to shape the experiences of your end-users. Next.js provides a solid foundation, and tools like the axe DevTools Extension enable you to build on that foundation, ensuring that you’re getting accessibility right, while backed by decades of proven best practices.

At Deque, our mission is to help create a digital world that works for everyone. If you’ve made it this far, you’re already part of that mission. So keep building, keep testing, and keep pushing to make the web more inclusive for all.

As a developer, you want to build fast, modern, progressive web applications (PWAs) that reach as many users as possible. That’s the goal—and it’s a good one. But if accessibility isn’t part of that process, you could be unintentionally leaving people behind. Accessibility (a11y) is essential to creating inclusive experiences and is a hallmark of thoughtful, user-centered development. In most cases, it’s also a legal requirement.

Let’s talk about how to build apps that are both fast and accessible—because you shouldn’t have to choose.

In this post, I’ll show you how combining the intelligent defaults from a framework like Next.js with specialized tools like Deque’s axe DevTools enables you to create a tech stack that not only sets you up for success—but also helps you prove that your application works for everyone.

I’m choosing to focus on Next.js because of how it encourages accessible development by default. From semantic HTML to ARIA roles, it’s clear accessibility wasn’t an afterthought—it’s built into the framework. And because accessibility isn’t just about clean markup (it’s about real-world usability), we’ll go beyond the basics that a framework like Next.js provides to explore how integrating axe DevTools makes it possible to validate and prove your app is truly accessible—in practice.

Why build accessibly in the first place?

Before we dive deeper into frameworks and tools, let’s ground ourselves in why accessibility matters:

• Accessibility is essential to good UX. It ensures that your app works for everyone—including users with disabilities.
• It’s about function, not just form. That means your app should be navigable by keyboard, readable by screen readers, and free of blockers like broken flows or unclear interactions.
• It’s also the law. Depending on your industry or region, you may be required to meet accessibility standards and laws like WCAG, the ADA, or the European Accessibility Act. Inaccessible sites can (and do) lead to legal action.

But compliance isn’t the end goal. Building accessibly leads to better structure, improved performance, and more thoughtful user experiences. Semantic HTML, readable content, and smooth keyboard navigation benefit everyone—not just people using assistive technology.

Frameworks like Next.js help you start strong, but tools like axe DevTools help you validate that your app is truly accessible in practice. Because best practices are only the beginning—true accessibility requires testing, iteration, and visibility into how your app performs for real users.

Challenges developers face

Understanding that you need to build accessibly is one thing—knowing where to start is another. If you’re new to accessibility, the learning curve can feel steep. WCAG can be dense, and assistive technologies like screen readers may be unfamiliar. And when you’re trying to ship fast, accessibility can feel like yet another thing to tack on before a deadline.

But the earlier you build a11y into your workflow, the easier it is to manage—and the less it costs to fix.

That’s why frameworks like Next.js are so helpful: they surface accessibility issues as you code, reminding you when something needs attention. And with tools like the axe DevTools Browser Extension, you can run automated tests and follow guided workflows to identify and fix real accessibility barriers—early, and with confidence.

Want to check it out in action? Request a demo of axe DevTools Browser Extension today!

Four ways Next.js framework assists in accessible development

Next.js includes several built-in features that make it easier to create accessible applications—without adding complexity to your workflow. In this section, we’ll look at four practical ways the framework helps you build for everyone:

• Routing and announcements: Built-in support for screen reader announcements during page transitions improves navigation for assistive technology users.
• Head management: The next/head component lets you dynamically manage page titles and metadata, improving accessibility and SEO.
• Component accessibility: The component supports keyboard and screen reader interactions out of the box and boosts performance.
• Linting: Integrated accessibility linting flags issues like missing alt text and invalid markup early—so you can catch and fix problems before launch.

Let’s get started.

Routing and announcements

On the topic of screen readers and HTML markup, Next.js does an excellent job of announcing page changes during server-side rendering—and it carries that same accessibility consideration into client-side transitions. Screen readers and other assistive technology announce the page’s title each time a new page loads so users understand that the state of the webpage has changed.

Next.js includes a built-in route announcer that works by default, looking first at the document.title, then the page’s <h1> element, and finally, the URL path to determine what should be announced. Because of this hierarchy, each page must have a well-structured and descriptive title and heading. This feature is also fully supported when using the next/link component, which handles client-side navigation seamlessly. Routing in vanilla React can be clunky and unintuitive, but Next.js handles it well. That alone is a huge improvement on accessibility.

Head management

The <head> tag plays a critical role in both a11y and search engine optimization (SEO). It provides essential context for search engines and ATs, helping them understand a page’s purpose and content. Next.js makes managing this simpler with a built-in next/head component.

You can import it into any page and dynamically set things like the page <title>, meta descriptions, and more—keeping your app accessible and well-structured:

import Head from 'next/head';

export default function BlogPost({ title, description }) {
  return (
    <>
      <Head>
        <title>{title} | My Blog</title>
        <meta name="description" content={description} />
        <meta property="og:title" content={title} />
      </Head>
      <main>
        <h1>{title}</h1>
        <p>{description}</p>
        {/* blog content here */}
      </main>
    </>
  );
}

Another benefit of using next/head is that it automatically clears out previous head content when navigating between pages. This ensures your metadata is accurate per page and doesn’t carry over information from other routes. Whether you’re optimizing for screen readers or search engines, this kind of precision matters.

<Link> component accessibility

The Next.js component is more than a convenience for routing. Behind the scenes, it prefetches the destination page’s code (via the href) and data in the background, so the response is significantly faster when a user clicks or navigates via the keyboard. This kind of speed is more than a UX upgrade—it makes a tangible difference for users who may be on a slower network or those who use older devices.

From an accessibility standpoint, the component supports keyboard navigation out of the box. It can receive focus and be triggered by Enter or Space, and it works seamlessly with screen readers. Each is also fully compatible with tabIndex, making it easier to manage keyboard focus in custom layouts or navigation menus.

If you’re building out custom navigation or want to be confident your keyboard accessibility actually works in practice, tools like the axe DevTools browser extension include Intelligent Guided Tests (IGTs) that walk you through common patterns—like link navigation—to help validate focus order, interaction, and screen reader behavior.

Here’s an example of rendering navigation links dynamically—while keeping everything accessible:

import Link from 'next/link';

const menuItems = [
  { label: 'Home', href: '/' },
  { label: 'Blog', href: '/blog' },
  { label: 'Contact', href: '/contact' },
];

export function NavigationMenu() {
  return (
    <nav aria-label="Main Navigation">
      <ul>
        {menuItems.map(({ label, href }) => (
          <li key={href}>
            <Link href={href}>{label}</Link>
          </li>
        ))}
      </ul>
    </nav>
  );
}

This setup improves page load time and ensures that your navigation is focusable, readable, and screen reader–friendly without adding extra overhead. The goal here isn’t to reinvent how links work but to ensure they behave reliably for all users, regardless of how they interact with your application.

Linting

One of the most practical accessibility features Next.js offers out of the box is integrated linting with eslint-plugin-jsx-a11y. For those unfamiliar, a linter is a static code analysis tool that scans your source code for issues ranging from stylistic errors to broken patterns. In this case, it’s scanning for a11y issues before you even run your app.

Because Next.js includes this plugin by default, it starts flagging things like missing alt attributes (see images below), misused ARIA roles, unsupported elements, and incorrect semantic markup from the jump. You don’t have to think about configuring it, and since you’re being flagged during development, it’s already helping you write better code.

If you add two <h1> elements to a single page (see the following image) and run the application in a browser, Next.js will throw a full-screen build error that blocks you from continuing and nudges you toward better semantic structure, which is especially important for users navigating with ATs.

This kind of immediate feedback changes the way you think about markup. You’re not writing code that looks good. You’re writing semantic code that communicates meaning—clearly and consistently. For users relying on screen readers or keyboard nav, that distinction is everything and clearly impacts how that information is displayed to those users.

But what if you need more than just the basics?

While Next.js helps catch common issues in the IDE, Deque’s axe DevTools Linter takes it further—with professional-grade coverage, customization, and CI/CD integration designed for real-world dev teams.

Here’s what axe DevTools Linter adds beyond framework defaults:

• Custom component linting: Map your design system or component library to enforce accessibility usage patterns automatically.
• Pre-commit hooks: Catch issues before code gets shared with your team.
• Pull request checks: Block inaccessible code from being merged and give reviewers actionable fix guidance.
• CI/CD integration: Scan and enforce standards across GitHub, Jenkins, SonarQube, and more.
• IDE support: Use it directly in VS Code, IntelliJ, or WebStorm with visual issue reporting and in-line feedback.
• Broad framework support: React, Vue, Angular, HTML, React Native—and beyond.

Whether you’re writing code in your IDE, reviewing a pull request, or shipping to production, axe DevTools Linter meets you where you work and enforces the standards your team agrees on. Combining the built-in help of frameworks like Next.js with tools like axe DevTools Linter means accessibility isn’t just encouraged—it’s enforced, from first commit to final deployment.

Build accessibility into every phase of development

If you’re building with Next.js, you’re already off to a good start—its built-in features help guide developers toward more accessible outcomes by default. However, accessible development doesn’t stop with semantic HTML or helpful linting. To truly deliver experiences that work for everyone, you need the ability to test, validate, and enforce accessibility throughout your team’s workflow.

That’s where the tools in the axe DevTools suite come in. Together, they give you the visibility and control to catch what frameworks can’t, ensuring your app isn’t just fast and modern, but also usable by everyone.

• Use the axe DevTools Browser Extension to test live pages in your browser and catch accessibility issues in real time.
• Add the axe DevTools Linter to your IDE or CI pipeline to catch issues earlier in development—even in custom components.
• Encourage your team to treat a11y as a shared responsibility.

Up next:

Stay tuned for Part Two of this post, where we’ll dive deeper into inclusive development practices, including how to structure your components, manage focus, and support real-world usability across a range of devices and assistive technologies.

Because building accessibly isn’t just about tools—it’s about building for everyone, by design.