{
  "id": 1612987,
  "title": "10 Common ARIA Mistakes in React & Next.js (And How to Fix Them)",
  "url": "https://urgent.news/2026/08/18/10-common-aria-mistakes-in-react-next-js-and-how-to-fix-them",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-18T02:01:42.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/willsun/10-common-aria-mistakes-in-react-nextjs-and-how-to-fix-them-577n"
  },
  "original_language": "en",
  "account": "Web developers frequently turn to ARIA (Accessible Rich Internet Applications) attributes to enhance the accessibility of complex web components. However, employing ARIA improperly can actually degrade accessibility rather than improve it. Below are the ten most common ARIA pitfalls found in React and Next.js projects, along with guidance on rectifying these issues.\n\n1. Employing \"Fake Buttons\": Developers sometimes mistakenly use div elements with onClick handlers instead of native button elements. This approach fails to provide crucial keyboard interactions like Tab navigation, Enter/Space activation, and proper accessibility tree roles.\n\n❌ Incorrect:\n<div onClick={handleClick}>Submit</div>\n\n✅ Correct:\n<button type=\"button\" onClick={handleClick}>Submit</button>\n\n2. Superfluous ARIA Roles: Adding redundant ARIA roles to semantic HTML elements is unnecessary and can clutter the accessibility tree. Modern screen readers inherently recognize HTML5 semantic tags like nav, article, and section.\n\n❌ Redundant:\n<button role=\"button\">Click me</button>\n\n✅ Accurate:\n<button>Click me</button>\n\n3. Omitting aria-expanded: For collapsible accordions and dropdown menus, it's essential to communicate the current state (open or closed) to screen reader users. This attribute clarifies the panel's status.\n\n✅ Accessible:\n<button aria-expanded={isOpen} aria-controls=\"faq-content-1\" onClick={() => setIsOpen(!isOpen)}>\nWhat is WCAG 2.2?</button>\n<div id=\"faq-content-1\" hidden={!isOpen}>...</div>\n\n4. Unlabeled Icon Buttons: Icon-only buttons pose challenges for screen reader users, as they receive no textual context. Assigning an aria-label resolves this issue.\n\n❌ Unlabeled:\n<button onClick={handleSearch}>SearchIcon</button>\n\n✅ Labeled:\n<button onClick={handleSearch} aria-label=\"Search articles\">\nSearchIcon aria-hidden=\"true\"</button>\n\n5. Hiding Focusable Elements via aria-hidden=\"true\": If an element can be reached via keyboard, removing it from the accessibility tree leads to confusing keyboard traps known as \"ghost focus.\"\n\n❌ Ghost Focus Issue:\n<button aria-hidden=\"true\" onClick={openModal}>Open</button>\n\n❗️ Recommended Practice:\nUse aria-hidden=\"true\" only on non-focusable elements (e.g., decorative icons) to prevent accessibility issues.",
  "summary": "As web applications become more dynamic, developers increasingly reach for ARIA (Accessible Rich Internet Applications) attributes to make complex widgets accessible. However, the First Rule of ARIA is famously: \"Don't use ARIA if you can use native HTML.\" Misusing ARIA can actually make an interface less accessible than having no ARIA at all. Here are the 10 most frequent ARIA anti-patterns we…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}