ARIA, Anti-Patterns, and You  🔗 **Source:** [ARIA, Anti-Patterns, and You](https://dbushell.com/2026/06/26/aria-anti-patterns-and-you/) > [!note]+ Document Notes > --- > tags: [accessibility, aria, wcag, web-standards, llm-generated-code, html-semantics] > author: David Bushell > source: dbushell.com > reference: https://dbushell.com/2026/06/26/aria-anti-patterns-and-you/ > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > --- > # 🏷️ Title: ARIA, anti-patterns, and you > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - [What I Wish Someone Told Me When I Was Getting Into ARIA — Eric Bailey](https://ericwbailey.website/) > - [Read Me First — ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/) > - [2.1 First Rule of ARIA Use — Using ARIA, W3C](https://www.w3.org/TR/using-aria/#firstrule) > - [WebAIM Million — annual accessibility analysis of top home pages](https://webaim.org/projects/million/) > ## 📝 Summary > - What happened: David Bushell corrects a common misreading of ARIA and the ARIA Authoring Practices Guide (APG), reacting to an article that told readers to point an LLM agent at an APG pattern and get a "solid first draft." > - Why it matters: Developers treat the APG as a best-practices cookbook. It isn't. It exists to demonstrate how the ARIA spec should work in theory so browser and assistive-tech vendors can test their ARIA support. Mistaking it for guidance produces worse accessibility, not better. > - Key stakeholders: Front-end developers, accessibility practitioners, component-library authors, and anyone shipping LLM-generated markup. For Courtney's work, theme/plugin authors and the WordPress Accessibility team. > - Risks and tradeoffs: ARIA overuse correlates with more detected errors. Automating it with LLMs that scrape the APG scales the misuse. The countervailing tradeoff is speed — LLM drafts feel fast, which is exactly the trap. > - Bottom line: The first rule of ARIA is don't use ARIA. Prefer native HTML. Don't point an LLM at the APG, and don't treat "I tested it" as a free pass when your only test is one screen reader. > ## 📖 Main Content > - Core argument: The APG is a demonstration artifact, not a how-to. Bushell quotes the APG's own "Read Me First" — its examples exist so vendors "can thus utilize code in this guide to help assess the quality of their support for ARIA 1.2." Eric Bailey makes the same point: the guide's examples "near-exclusively, overwhelmingly, and disproportionately favor ARIA" because it was authored to show off ARIA's capabilities. > - The "first rule of ARIA" principle (W3C, *Using ARIA*, §2.1): if a native HTML element or attribute already has the semantics and behavior you need, use it instead of re-purposing an element and bolting on an ARIA role, state, or property. Best practice is not using ARIA at all. > - The facepalm trigger: an article advised pointing an LLM agent at an APG pattern, describing your markup, and getting a refinable first draft. Bushell flags two problems — the APG is the wrong source, and an LLM is the wrong tool to copy it. > - The button example: the APG's button pattern ships `<div tabindex="0" role="button">` markup. Bushell can't think of any circumstance where `<div role="button">` should be used over a real `<button>`. A native button gives you focusability, keyboard activation, and the role for free; the div version re-implements all of it by hand and usually gets it wrong. > - The self-undermining tell: even the APG's button example uses a real `<details>` element for its "Read This First" disclosure rather than the APG's own disclosure pattern — proof the APG isn't best practice on its own terms. > - Evidence of harm: Bushell cites the finding that increased ARIA usage on a page correlates with more detected accessibility errors — the more ARIA attributes present, the more errors expected. This echoes the WebAIM Million's recurring result. > - The LLM critique: he names that "OpenAI is throwing ARIA at the web and seeing what sticks" and argues automating APG-copying spreads the misuse at scale. His blunt advice: avoid ARIA wherever possible, and don't point a freaking LLM at the APG. > - The "test" jab: he challenges readers to name an assistive technology that isn't a screen reader. The point is that "I tested it" usually means "I checked it in one screen reader," which is not a get-out-of-jail-free card. He points to Declan Chidlow's "Overview of Digital Accessibility Technologies" for the broader landscape (voice control, switch access, magnification, braille displays, and more). > - Uncertainty/nuance: Bushell concedes the APG is a useful resource if you understand why it exists, and admits he's been confused by it himself — so this is a framing correction, not a claim that the APG is worthless. > ### 🗒️ Notes > - The APG's purpose is conformance testing for ARIA, not building accessible production UI. Treat its code as reference implementations of the spec, not patterns to copy. > - "Best practice is not using ARIA at all" — the strongest line, and a direct corollary of the W3C first rule. > - `<div role="button">` is the canonical anti-pattern: it requires manually adding `tabindex`, keyboard handlers (Enter and Space), and the role, all of which a native `<button>` provides. > - "Before you tell me you can't edit your React component library, do the web a favour and delete your codebase." — rhetorical, aimed at teams who treat a locked component library as an excuse to ship inaccessible markup. > - The `<details>` tell is the cleverest evidence: the APG silently picks the native element for its own page chrome. > - ARIA-usage-to-error correlation is the empirical backbone (consistent with WebAIM Million year over year). > - The P.S. reframes "testing": one screen reader is not the assistive-tech universe. Voice control, switch devices, screen magnifiers, and braille displays all exist. > - Tone is opinionated and profane by design — a practitioner venting at a specific bad recommendation, not a neutral spec summary. > ## 📚 References > - [What I Wish Someone Told Me When I Was Getting Into ARIA — Eric Bailey](https://ericwbailey.website/) > - [Read Me First — ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/) > - [Using ARIA — First Rule of ARIA Use (W3C)](https://www.w3.org/TR/using-aria/#firstrule) > - [WebAIM Million](https://webaim.org/projects/million/) > - [ARIA Authoring Practices Guide — Button Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/button/) > - [Overview of Digital Accessibility Technologies — Declan Chidlow](https://vale.rocks/) > ## 🗣️ Paraphrase > - ARIA and the APG get misread constantly. The APG isn't a best-practices manual; it's a demonstration of how the ARIA spec is meant to behave, so browser and assistive-tech makers can test their ARIA support. Eric Bailey confirms the examples lean almost entirely on ARIA because that was the point. > - Even if ARIA were perfectly supported (it isn't), the APG still wouldn't be best practice, because the real best practice is reaching for native HTML first and adding ARIA only when nothing native fits — the W3C first rule. The APG's own button example uses `<div role="button">` and a native `<details>` for its disclosure, which gives the game away. > - Misusing ARIA has made the web less accessible: more ARIA on a page tracks with more detected errors. So pointing an LLM at the APG industrializes the mistake. Avoid ARIA where you can, don't outsource judgment to an LLM scraping the APG, and stop treating "I tested it" — usually in one screen reader — as proof your code is sound. > ## 📰 Newsletter > - Quick gut-check for theme and plugin builders: if your block markup leans on `role="button"`, `role="tabl Please take a minute to understand what [ARIA](https://www.w3.org/WAI/standards-guidelines/aria/) is and is not. ARIA and especially the [ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/) are commonly misunderstood. I read an article [the other day](https://dbushell.com/notes/2026-06-24T05:31Z/) that had this facepalm moment: > And with modern LLM agents, turning a spec into working code is surprisingly fast. Point the agent at the APG pattern, describe your component’s markup, and get a solid first draft you can refine and test. > > This is worrying, and the use of “LLM agents” isn’t the worst part! The APG is **not** a how-to guide of ‘best practices’ for building accessible websites. 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). As Eric Bailey notes — > The guide was originally authored to help demonstrate ARIA’s capabilities. As a result, its code examples near-exclusively, overwhelmingly, and disproportionately favor ARIA. > > [What I Wish Someone Told Me When I Was Getting Into ARIA](https://www.smashingmagazine.com/2025/06/what-i-wish-someone-told-me-aria/#the-downsides) - Eric Bailey > > — which makes sense, because: > Browser and assistive technology developers can thus utilize code in this guide to help assess the quality of their support for ARIA 1.2. > > [Read Me First](https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/#:~:text=Except%20in%20cases,for%20ARIA%201.2.) - ARIA Authoring Practices Guide (APG) > > Even if ARIA was fully supported ([it’s not](https://a11ysupport.io/)) the APG still wouldn’t be a ‘best practice’ guide. ‘Best practice’ is not using ARIA at all. > If you can use a native HTML element or attribute with the semantics and behavior you require **already built in**, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, **then do so**. > > [2.1 First Rule of ARIA Use](https://www.w3.org/TR/using-aria/#rule1) - Using ARIA, W3C > > APG exists in a vacuum to show off the ARIA spec. The [button example](https://www.w3.org/WAI/ARIA/apg/patterns/button/examples/button/) includes this code, for crying out loud! ``` <div tabindex="0" role="button" id="action"> Print Page ``` I’m unaware of any circumstance where `<div role="button">` should ever be used over a `<button>`. Before you tell me you can’t edit your [React](https://jsx.lol/) component library, do the web a favour and delete your codebase. In fairness, the button example has a [“Read This First”](https://www.w3.org/WAI/ARIA/apg/patterns/button/examples/button/#support-notice-header) disclosure — and guess what: they use a [`<details>` element](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details) and not the [disclosure pattern](https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/) because the APG isn’t best practice. It’s hard to blame developers for misusing ARIA and the APG. I’ve been confused myself. As W3C documentation goes, APG is rather sexy. It’s a useful resource if you understand why it exists. Misuse of ARIA has made the web less accessible. > Increased ARIA usage on pages was associated with higher detected errors. The more ARIA attributes that were present, the more detected accessibility errors could be expected. > > Avoid ARIA where ever possible. Don’t point a freaking LLM at the APG! I can’t believe I’m saying this but use [Google’s slop](https://dbushell.com/2026/05/20/google-just-spat-in-my-face/) if you absolutely refuse to learn/code yourself. Apparently [OpenAI is throwing ARIA](https://adrianroselli.com/2025/10/openai-aria-and-seo-making-the-web-worse.html) at the web and seeing what sticks. Ahhh! I don’t know anymore, take some pride in your expertise? P.S. name an assistive technology that isn’t a screen reader. Ain’t easy, is it? So don’t be casually punctuating with the word “test” like it’s some *get-out-of-jail-free* card for your dubious practice and advice. [“Overview of Digital Accessibility Technologies”](https://vale.rocks/posts/digital-accessibility-technologies) by Declan Chidlow is a great help if you want to win this game at parties., ARIA, Anti-Patterns, and You, dbushell.com, 01kw2bhzsw326syp8pvxdbda8e.