# ARIA, Anti-Patterns, and You > [!question] Lingering Questions > - Where exactly is the line between legitimate ARIA (live regions, `aria-expanded` on a native control) and ARIA that just re-implements native semantics badly? > - How should an AI authoring assistant be steered to prefer native HTML — a system-prompt instruction, an eval gate, or an outright refusal to emit `<div role="button">`? > - What's a CI-enforceable "ARIA misuse" metric that doesn't throw false positives on legitimate ARIA use? > [!tip] Article Ideas > - A "native HTML alternative" column for common accessibility pattern docs (disclosure → `<details>`, button → `<button>`) — concrete enough to ship as a DevHub/Learn WordPress resource. #articleseed > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Native HTML Semantics Beat Re-Implemented ARIA]] — this note's own permanent candidate > - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — the LLM-scrapes-the-APG failure mode is a concrete instance of AI-generated output needing human review > [!quote] Vocabulary > - *APG* — the ARIA Authoring Practices Guide; a W3C reference implementation built so browser/assistive-tech vendors can test their ARIA spec support, not a best-practices cookbook > - *first rule of ARIA* — W3C's *Using ARIA* §2.1: if a native HTML element already has the semantics and behavior you need, use it instead of re-purposing a generic element with ARIA roles ## Bib capsule David Bushell, "ARIA, anti-patterns, and you," dbushell.com, 2026-06-26. ## Author's thesis The ARIA Authoring Practices Guide (APG) is a demonstration artifact for vendors testing their ARIA spec support, not a best-practices cookbook — and developers, especially ones pointing LLMs at it for "solid first drafts," keep misreading it as one. The actual best practice, per the W3C's own first rule, is to use native HTML wherever it already provides the needed semantics and behavior; ARIA is the fallback, not the default. Automating APG-copying with LLMs industrializes the misuse, and higher ARIA density measurably correlates with more detected accessibility errors. ## Key arguments 1. The APG exists to demonstrate the ARIA spec in theory, "regardless of whether more accessible, non-ARIA patterns exist (they do)" — it's for vendor conformance testing, not developer guidance. 2. The W3C's first rule of ARIA is explicit: prefer a native HTML element with the needed semantics over re-purposing a generic element and bolting on ARIA — even the APG's own page uses a native `<details>` for its disclosure rather than its own documented pattern. 3. ARIA misuse is empirically costly: pages with higher ARIA-attribute density show more detected accessibility errors (consistent with the WebAIM Million), so pointing an LLM at APG examples to generate markup scales the wrong pattern. ## Claim atoms ### APG demonstrates the ARIA spec, not best practice > [!quote] ID:rw_aria_apg_purpose > It exists to demonstrate how the ARIA specification should work in theory — regardless of support and regardless of whether more accessible, non-ARIA patterns exist (they do). **Context & use**: The framing correction at the heart of the piece. Reorients how to read every APG pattern: reference implementation for vendor testing, not a cookbook. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### First rule of ARIA is use native HTML > [!quote] ID:rw_aria_first_rule > If you can use a native HTML element or attribute with the semantics and behavior you require already built in **Context & use**: Quoting W3C *Using ARIA* §2.1. The actionable standard for any review gate: native element before any role/state/property. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> ### More ARIA correlates with more accessibility errors > [!quote] ID:rw_aria_error_correlation > The more ARIA attributes that were present, the more detected accessibility errors could be expected. **Context & use**: The empirical backbone of the piece (consistent with the WebAIM Million). Justifies "avoid ARIA where possible" with data, not just taste. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ## Permanent candidates - [[3. Resources/Permanent Notes/Native HTML Semantics Beat Re-Implemented ARIA]] — new this pass, combining atoms 2 and 3 (the first-rule standard plus the empirical evidence for it) into one claim. - Atom 1 (APG's actual purpose) stays as a Literature-note atom — it's context that reframes how to read a specific resource, not a portable claim on its own. ## Processing checklist - [x] Verbatim quotes preserved from the source deep-read - [x] Atomicity markers present on all three atoms - [x] Checked for existing Permanent notes before drafting — none found; created one - [x] Connect into the relevant MOC(s) ## Links - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — LLM-generated markup as a class of AI-output-needs-review problem - Source doc: [[3. Resources/Readwise/Articles/ARIA, anti-patterns, and you]] - [[3. Resources/MOCs/Accessibility & Disability Inclusion MOC]] — applies-in: Joins the cluster on accessible-by-default development and ARIA misuse.