ARIA, Anti-Patterns, and You - CourtneyR.dev's 2nd Brain

ARIA, Anti-Patterns, and You ![rw-book-cover](https://dbushell.com/images/articles/2026-06-26-aria-anti-patterns-and-you.png) 🔗 **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="tablist"`, or hand-rolled `tabindex`, ask whether a native `<button>`, `<details>`, or real form control would do the job with zero ARIA. Usually it would. - David Bushell's "ARIA, anti-patterns, and you" is a short, spicy reminder that the ARIA Authoring Practices Guide is a spec demo for vendors, not a copy-paste cookbook — and that letting an LLM agent generate accessibility code off the APG scales the wrong patterns fast. - The first rule of ARIA is don't use ARIA. Pair this with the WordPress Accessibility team's coding standards and the next time an AI assistant hands you a `<div role="button">`, swap it for the real thing. - Worth bookmarking: Eric Bailey's "What I Wish Someone Told Me When I Was Getting Into ARIA," the W3C *Using ARIA* first rule, and Declan Chidlow's overview of assistive technologies beyond screen readers (voice control, switch access, magnifiers, braille displays). ## ✅ Action Items #### WordPress - **Accessibility:** Add a lint/audit rule to the team's review cadence that flags `role="button"`, `role="link"`, `role="checkbox"`, and manual `tabindex` on non-native elements in themes and blocks, recommending the native element first. Map the rule to WCAG 4.1.2 Name, Role, Value and 2.1.1 Keyboard. - **Accessibility:** Publish a short "First Rule of ARIA" explainer for the make.wordpress.org/accessibility handbook, citing the W3C first rule and the ARIA-usage-to-error correlation; position the APG as a vendor conformance demo, not a pattern library. - **Accessibility:** Update the Accessibility Checker / automated-testing guidance so contributors don't read APG examples as endorsed patterns; add a "native HTML alternative" column to common-pattern docs (disclosure → `<details>`, button → `<button>`). - **Themes:** Bake an ARIA-misuse check into the theme review test matrix — reject `<div role="button">`-style controls when a native element exists. Add it to the theme-review lints and reviewer mentoring notes. - **Plugins:** Add a security-and-quality liaison check for block plugins that ship interactive controls; provenance-check any LLM-generated accessibility markup before approval, since APG-scraped output is a known failure mode. - **Core:** Audit core block output and dynamic blocks for redundant or conflicting ARIA roles on elements that already carry native semantics; set a release-criteria gate that new interactive blocks justify any ARIA against the first rule. - **Core AI:** When defining responsible-AI guardrails and evaluation sets for any WordPress AI authoring feature, include an accessibility eval that penalizes ARIA over native HTML and rejects `<div role="button">` patterns; treat "the LLM tested it" as unverified. - **Documentation:** Fix examples-first patterns in DevHub/HelpHub so interactive UI snippets use native elements; add a callout that the APG is a spec demonstration, with links to *Using ARIA* and Eric Bailey's article. - **Training:** Add a Learn WordPress lesson "ARIA: when not to use it," built around the first rule, the button anti-pattern, and the "name an assistive technology that isn't a screen reader" exercise. - **Playground:** Build a reproducible Playground demo comparing a native `<button>` against a `<div role="button">` across keyboard and assistive tech, so contributors feel the difference rather than read about it. #### DevRel - Developer experience: Ship a copy-pasteable "native first" snippet set (button, disclosure, tabs, dialog) as the canonical reference developers reach for instead of the APG. - Education: Run an office-hours or workshop on reading the APG correctly — why it exists, how to translate a demo into production, and when to drop ARIA entirely. - Developer marketing: Counter-message the "point an LLM at the APG, get a solid first draft" advice circulating in tutorials; publish the native-HTML alternative as the faster, safer path. - Community management: Add a code-review norm that "I tested it" must name the assistive technologies tested, not just imply a single screen reader. #### OSPO - Policy & Governance: Add an accessibility clause to contribution policies requiring native HTML semantics before ARIA, with the first rule cited as the standard. - Developer Support: Provide consultation hours / guardrails for teams integrating LLM code generation, flagging APG-scraped accessibility output as requiring human review. - Strategic Alignment: Track an accessibility KPI (ARIA-attribute density and detected-error rate) so leadership can see whether tooling changes reduce misuse. #### Community - Maintainers: Add release-hygiene checklist item — no new `<div role="button">`-class controls; native element or justification required. - Contributors: Create a "first issue" rotation to convert hand-rolled ARIA controls to native elements in component libraries. - Ecosystem: Coordinate a shared accessibility-lint ruleset across projects so the same anti-patterns get caught everywhere. #### The WPCC - Projects: Sponsor a documentation sprint to rewrite accessibility examples toward native-first patterns across the contributor handbook. ### FAIR - Technical independence: Not applicable to this source — the article doesn't address federated metadata, provenance, or distribution governance. ## 🧪 Hypotheses - Replacing `<div role="button">` controls with native `<button>` elements measurably reduces detected accessibility errors per page. - Pages with higher ARIA-attribute density show higher automated-checker error rates (Bushell's central empirical claim). - LLM-generated accessibility code that cites the APG produces more ARIA and more errors than human "native-first" code for the same component. - Developers who read the APG's "Read Me First" disclaimer use less ARIA than those who copy patterns directly. - A "native HTML alternative" column in pattern docs lowers ARIA usage in submitted themes/plugins over a release cycle. - Teams whose only accessibility test is one screen reader ship more keyboard and non-screen-reader failures than teams testing multiple assistive technologies. ### 📊 Methodology - Crawl a sample of WordPress theme/block output; correlate ARIA-attribute density with automated-checker error counts (regression against page size as a control). - A/B a component task: have one cohort generate UI by pointing an LLM at the APG and another build native-first; count WCAG failures and manual-test defects. - Before/after study: add the "native alternative" doc column, measure ARIA density in submitted plugins across two release windows. - Survey + log study on the meaning of "tested": instrument which assistive technologies developers actually use during accessibility QA. ### ❓ Questions - Where is the line between legitimate ARIA (live regions, `aria-expanded` on a native control) and ARIA that re-implements native semantics? - How should an AI authoring assistant be steered to prefer native HTML — system prompt, eval gate, or refusal to emit `<div role="button">`? - Can the APG add stronger, harder-to-skip "this is a spec demo, not best practice" framing to each pattern? - What's the right metric for "ARIA misuse" that a CI accessibility check can enforce without false positives? ### 🔮 Future Research - Build and publish an open eval set that scores LLM accessibility output on native-first preference. - Quantify the real-world assistive-tech distribution beyond screen readers to retire the "one screen reader = tested" habit. - Study whether component-library defaults (shipping native primitives) outperform documentation in reducing ARIA misuse. ### 💡 Implications - Practice: "Native first" becomes a hard review gate, not a suggestion; ARIA needs justification. - Policy: Accessibility contribution policies and AI guardrails should encode the first rule explicitly. - Security/quality: LLM-generated markup is a supply-chain-style risk for accessibility — needs human review and provenance. - Education: Curricula must teach what the APG is *for* before teaching ARIA patterns. - Funding: Worth funding native-first component libraries and shared lint rulesets over one-off audits. ### 🧠 Learning Styles Assessment - Reading level estimate: roughly grade 9–10 (Flesch–Kincaid Grade Level ~9–10); short sentences, conversational, some jargon (ARIA, APG, role, tabindex) assumed known. Profanity and rhetorical asides raise engagement, not difficulty. #### 👀 Visual learners - Present: one inline code snippet (`<div role="button">`). - Improve: add a side-by-side native `<button>` vs div-button diagram, a focus-order screenshot, and a chart of ARIA density vs error rate. #### 🔊 Aural learners - Present: none. - Improve: a 2–3 minute audio summary; narrate the button anti-pattern walkthrough. #### 🗣️ Verbal learners - Present: clear definitions in context (APG's purpose, the first rule quoted verbatim), strong analogies ("seeing what sticks"). - Improve: a short glossary (role, state, property, native semantics) and a plain-language callout box. #### 🧩 Kinesthetic learners - Present: copyable code; an implicit "go delete your codebase" call to act. - Improve: a hands-on lab swapping a div-button for a native button and testing both with a keyboard. #### 🧠 Logical learners - Present: a clean deductive chain (APG = spec demo → not best practice → don't automate it). - Improve: a decision tree ("is there a native element? → use it"), and the error-rate correlation as a small table. #### 🧑‍🤝‍🧑 Social learners - Present: links to peers (Bailey, Chidlow) and a party-game framing. - Improve: a discussion prompt and a shared review rubric for ARIA usage. #### 🧘‍♀️ Solitary learners - Present: a self-check challenge ("name an assistive technology that isn't a screen reader"). - Improve: a short self-quiz on when ARIA is and isn't warranted. #### 🌿 Naturalistic learners - Present: none directly. - Improve: frame accessibility debt as ecosystem health — anti-patterns propagate through copied code like an invasive species. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the article argues *for* native semantics and headings; its own thesis is screen-reader-aware. - Improve: ARIA roles only as needed; the article models this well. #### Keyboard navigation - Present: the core lesson is that native `<button>` gives keyboard activation for free; `<div role="button">` does not without manual handlers. - Improve: show correct focus order and Enter/Space handling for any unavoidable custom control. #### Contrast and readability - Present: not assessable from text; depends on dbushell.com's theme. - Improve: verify 4.5:1 on body and code blocks; ensure code snippet has sufficient contrast. #### Text resizing and reflow - Present: not assessable from text. - Improve: confirm the code block reflows and doesn't clip at 200% zoom. #### Media and captions - Present: text-only article; no media to caption. - Improve: if an audio version is added, ship a transcript. #### Forms and interactions - Present: discusses interactive controls (button, disclosure) and their correct native implementation. - Improve: cross-link a forgiving-input example for any custom widget. #### Standards reference - Maps to WCAG 2.2 AA: 4.1.2 Name, Role, Value; 2.1.1 Keyboard; 1.3.1 Info and Relationships; 4.1.3 Status Messages (for any live-region ARIA that remains legitimate). ### 🌍 DEIB Assessment #### Cultural breadth - Present: none — single-author, English-only, Western web-dev framing. - Improve: note that assistive-tech availability and norms vary by region and language. #### Inclusive language - Present: plainly written; jargon mostly defined in context. - Improve: the profanity and "delete your codebase" framing may alienate beginners; a calmer parallel summary would widen reach. #### Neurodiversity support - Present: short, chunked, consistent structure; one idea per paragraph. - Improve: add headings/subheads; the wall-of-paragraphs format taxes some readers. #### Representation - Present: cites multiple practitioners (Bailey, Chidlow), crediting their work. - Improve: include disabled users' direct perspectives, not only developer voices. #### Psychological safety - Present: respectful toward the cited experts. - Improve: the scolding tone toward developers ("take some pride in your expertise") could land as shaming; pair critique with a clear, blameless path forward. ### ✅ Logical Validity #### Strong reasoning - Deductive (¶5, ¶10–11): APG exists to demonstrate the spec → a demo isn't a best-practices guide → therefore copying it isn't best practice. Valid and well-supported by the APG's own "Read Me First." - Evidential (¶21): the ARIA-usage-to-error correlation grounds the "misuse made the web less accessible" claim in data rather than opinion. Strengthen by citing the specific dataset (e.g., WebAIM Million) with a year. - Analogical/by-example (¶13, ¶19): the `<div role="button">` snippet and the APG's own use of `<details>` are concrete, self-undermining evidence — the guide doesn't follow its own patterns. #### Fallacies - Appeal to ridicule / ad hominem flavor (¶18, ¶22): "delete your codebase," "Google's slop," "take some pride in your expertise" attack the practice and practitioner rhetorically rather than arguing the point. The underlying argument is sound, so these are stylistic, but they weaken persuasion for skeptical readers. Fix: keep the data and the first rule front and center, move the jabs to the margins. - Hasty generalization risk (¶18): "any circumstance where `<div role="button">` should ever be used" — near-absolute, but he hedges with "I'm unaware of," which keeps it honest. - Correlation-as-cause (¶20–21): "misuse has made the web less accessible" leans on a correlation; plausible and likely causal, but stated more strongly than the cited correlation alone proves. #### Tone of voice - Opinionated, exasperated, profane, and expert. Examples: "facepalm moment," "for crying out loud!," "Don't point a freaking LLM at the APG!," "Ahhh! I don't know anymore." It's a practitioner venting at bad advice, which reads as authentic but can alienate newcomers. ### 🛡️ DARVO Analysis - Deny: Not applicable — the author isn't denying wrongdoing; he's asserting a correction. No minimization of his own position beyond admitting "I've been confused myself," which is candor, not denial. - Attack: Mild rhetorical attacks on the practice and on actors ("Google's slop," "OpenAI is throwing ARIA at the web," "delete your codebase"), aimed at advice and vendors, not at a victim. Not DARVO in the abusive sense — closer to ordinary polemic. - Reverse victim/offender: Not present — no attempt to recast an accused party as the victim. - Net: DARVO framework doesn't apply; the piece is a direct critique with emotional rhetoric, not a defense against an accusation. ## 🎯 Conclusion - Bottom line: The APG demonstrates the ARIA spec for vendors; it is not a best-practices guide. Best practice is using native HTML and reaching for ARIA only when nothing native fits — the W3C first rule. Pointing an LLM at the APG industrializes the wrong patterns and, since ARIA density tracks with errors, makes the web less accessible. - Next steps for readers: default to native elements; treat `<div role="button">` as an anti-pattern; require human review of LLM-generated accessibility markup; and stop using "I tested it" (in one screen reader) as a free pass — learn the wider assistive-technology landscape, starting with Chidlow's overview. ## 🔄 Refactor Appendix — ARIA, anti-patterns, and you > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. ### 📚 Literature Atoms (H3) #### [H1] 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**: - ¶5, 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 **Highlight**: [view highlight](readwise://)  #### [H2] 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**: - ¶11, quoting W3C *Using ARIA* §2.1. - The actionable standard for review gates: native element before any role/state/property. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://)  #### [H3] 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**: - ¶21, the empirical backbone (consistent with WebAIM Million). - Justifies "avoid ARIA where possible" with data, not taste. **Tags**: #xref **Highlight**: [view highlight](readwise://)  ### 🧠 Permanent Candidates (H4) #### [P1] Native HTML semantics beat re-implemented ARIA **Claim** (one sentence, Courtney's voice): Reach for a native HTML element whose semantics and behavior already match the need, because re-purposing a generic element with ARIA roles tends to add errors rather than accessibility. **Evidence pointer**: [[#H2]] **Scope & conditions**: Holds for interactive controls with native equivalents (button, details, form fields, links). Breaks when no native element provides the needed pattern, where targeted ARIA (live regions, `aria-expanded` on a native control) remains legitimate. **Links**: - [[Accessibility-Checker-mu-plugin]] — because applies-in WordPress a11y review - [[WCAG-4.1.2-Name-Role-Value]] — because evidence-for - [[LLM-generated-code-needs-human-review]] — because extends  ### ✏️ Fleeting Queue - [F1] Add a "native HTML alternative" column to common a11y pattern docs (disclosure → `<details>`, button → `<button>`) — dbushell.com/2026/06/26/aria-anti-patterns-and-you #fleeting #inbox - [F2] Open question: which assistive technologies should "I tested it" require beyond a screen reader? (Chidlow overview) #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft an Accessibility Checker rule flagging `<div role="button">` / manual tabindex with native-element fix-its — #things - [ ] Add a "First Rule of ARIA" note to the theme/plugin review checklist — #things  📄 **Full text:** [[Full Document Contents/Articles/ARIA, Anti-Patterns, and You.md|ARIA, Anti-Patterns, and You by dbushell.com]] ## Highlights - 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). ([View Highlight](https://read.readwise.io/read/01kw2bras05je40skvtpyrjbq6)) - Note: The core correction: the APG demonstrates how the spec works in theory — it is NOT a best-practices guide for building accessible sites. - Tags: aria, atom/literature/h1 - If you can use a native HTML element or attribute with the semantics and behavior you require ([View Highlight](https://read.readwise.io/read/01kw2brqnycz7c1pshjrycbh1x)) - Note: The first rule of ARIA (W3C Using ARIA §2.1): prefer a native HTML element with built-in semantics over re-purposing an element and adding an ARIA role. - Tags: html-semantics, atom/literature/h2 - > 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. > > ([View Highlight](https://read.readwise.io/read/01kw2bre6fc27n79vah601vpe0)) - Note: The empirical backbone (WebAIM-style data): ARIA density correlates with MORE detected accessibility errors — more ARIA ≠ more accessible. - Tags: accessibility, atom/literature/h3