Barriers from Links with ARIA - CourtneyR.dev's 2nd Brain

Barriers from Links with ARIA 🔗 **Source:** [Barriers from Links with ARIA](https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html) > [!note]+ Document Notes > tags: [accessibility, aria, web-development] > author: Adrian Roselli > source: adrianroselli.com > reference: [https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html] > date created: 2026-01-26 14:00 > > # 🏷️ Title: Barriers from Links with ARIA >  ## 🧭 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 - Include links cited in or relevant to the article. --- ## 📝 Summary - What happened: Adrian Roselli evaluates visually stylized links that rely on `aria-label`, `aria-hidden`, and letter-by-letter spans, prompted by a CSS example from Temani Afif. - Why it matters: Many browser text-to-speech and reader features ignore `aria-label` and respect `aria-hidden`, creating hidden or mislabeled links. - Key stakeholders: Users of browser reader modes and text-to-speech, designers, front-end devs, accessibility specialists. - Risks and tradeoffs: Over-reliance on ARIA can break links for non-screen-reader assistive features and fails some WCAG criteria. - Bottom line: Don’t use `aria-label` on links, don’t use `aria-hidden` inside links, and don’t split link text across multiple elements. --- ## 📖 Main Content - Core argument: The article compares a simple anchor (`<a href>Link</a>`) to a decorative version using `aria-label`, `aria-hidden`, and per-letter spans. Roselli shows that while these patterns can look fancy, they introduce barriers for browser-based assistive features that are not full screen readers. - Context and terms: - ARIA: Attributes that help define accessible names/roles; only some assistive tech actually uses them. - `aria-label`: Overrides the accessible name; can conflict with visible text and WCAG 2.5.3 (Label in Name). - `aria-hidden`: Hides content from the accessibility tree; when used inside links, it can hide the only visible text. - Accessible name: The label exposed to assistive tech; often built from visible text unless overridden. - Evidence from tests: - Letter-by-letter spans do not auto-translate. - Edge “Read Aloud” ignores `aria-label` and does not announce links whose content is `aria-hidden`. - Chrome and Firefox reader modes: - Ignore `aria-label` on links. - Visually hide links whose content is `aria-hidden`. - Firefox also restyles span-split links oddly (white instead of standard link colors). - Safari’s Speech: - Skips large parts of the page once it hits span-split letters. - Uses incorrect link text (Korean labels for English links) and ignores both `aria-label` and span-separated letters. - WCAG context: - Links using only `aria-label` intentionally fail 2.5.3 (Label in Name) in the test, making it easy to spot when `aria-label` is (not) exposed. - Links using `aria-hidden` with no other text intentionally fail 4.1.2 (Name, Role, Value); this helps show where browser features depend on visible text instead of ARIA. - Key uncertainty/nuance: - The tests focus on browser features and not full screen readers or voice control. - Support patterns may change as browsers evolve; the article is a snapshot and an invitation for others to test. --- ### 🗒️ Notes - Prompt: Temani Afif asks whether two link patterns (plain vs. ARIA-decorated, letter-split, and `aria-hidden`) are equivalent “considering all aspects” like accessibility and semantics. - Roselli notes a canned response: `aria-label` auto-translation is inconsistent, but he also wants to examine “something else” — the behavior of non-screen-reader assistive features. - Only some assistive technologies read ARIA attributes: - Screen readers: Primary ARIA consumers. - Voice control: Uses accessible names assembled by browsers. - Many other tools (e.g., browser reader modes and TTS) do not fully process ARIA. - He builds demo pages and investigates: - How browser text-to-speech and reader modes handle: - Links whose visible letters are split across multiple spans. - Links whose text is hidden with `aria-hidden`. - Links whose label is overridden with `aria-label` (using Korean words like “sandwich” and “hammer”). - Observations: - Letter-splitting: - Does not auto-translate in some environments. - Can cause Safari Speech to skip most of the page, then misannounce subsequent links with the wrong text. - `aria-label`: - Ignored by Edge Read Aloud, Chrome reader TTS, and Safari Speech when announcing links. - `aria-hidden`: - Links whose content is `aria-hidden` are skipped or visually hidden in Chrome and Firefox reader modes. - Text-to-speech tends to respect `aria-hidden`, so link text can vanish entirely from the reading stream. - Amelia Bellamy-Royds’s insight: Browser text-to-speech features generally respect `aria-hidden` but ignore `aria-label` and, by extension, the accessible name from the accessibility tree. - Roselli’s three takeaways: - Do not use `aria-label` on links (use visible text instead). - Do not use `aria-hidden` within links (it can hide essential link content). - Do not split the letters of a word across multiple elements (spans) for visual styling. - Testing details: - Uses Korean words as `aria-label` values to quickly detect if label text is exposed. - Intentionally violates: - WCAG 2.5.3 (Label in Name) with differing `aria-label` values. - WCAG 4.1.2 (Name, Role, Value) with `aria-hidden` and no other text. - Encourages others to build variations, test on different systems, and report where patterns break rather than where they work. --- ## 📚 References - Adrian Roselli, “Barriers from Links with ARIA” — https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html - W3C WAI-ARIA Overview — https://www.w3.org/WAI/standards-guidelines/aria/ - WCAG 2.1 / 2.2 Success Criterion 2.5.3 Label in Name — https://www.w3.org/WAI/WCAG21/Understanding/label-in-name - WCAG 2.1 / 2.2 Success Criterion 4.1.2 Name, Role, Value — https://www.w3.org/WAI/WCAG21/Understanding/name-role-value/ --- ## 🗣️ Paraphrase - Paragraph A paraphrase: The article responds to a code example where a simple text link is replaced with an ARIA-labeled version whose characters are split across spans and hidden from accessibility APIs. Roselli argues that although this might look attractive visually, it behaves very differently for assistive technologies. - Paragraph B paraphrase: Roselli’s tests across multiple browsers show that text-to-speech and reader modes often ignore `aria-label` and fully honor `aria-hidden`, causing links to be skipped, mispronounced, or not translated. He concludes that designers should avoid ARIA tricks on links and instead keep link text visible, contiguous, and unhidden. --- ## 📰 Newsletter In this week’s WordPress dev digest, we’re zooming in on a subtle accessibility trap: “fancy” links built with ARIA and span-wrapped letters. Adrian Roselli’s latest article shows how `aria-label`, `aria-hidden`, and per-letter styling can break browser reader modes and text-to-speech. For WordPress builders, that means: theme typography tricks and animated links may silently disappear for users relying on built-in browser reading tools. Practical steps: - Audit your themes and plugins for links that: - Use `aria-label` instead of visible link text. - Wrap each letter of a link in separate spans. - Hide link text with `aria-hidden`. - Prefer simple, visible link text; enhance with CSS, not ARIA hacks. Helpful WordPress resources: - WP Accessibility Handbook: https://make.wordpress.org/accessibility/handbook/ - Theme accessibility guidelines: https://developer.wordpress.org/themes/functionality/accessibility/ - WP Accessibility plugin: https://wordpress.org/plugins/wp-accessibility/ --- ## ✅ Action Items #### DevRel - Clarify guidance in developer docs and talks: discourage `aria-label` on links and `aria-hidden` inside anchor tags; show safer alternatives. - Add accessibility-focused demos and workshops for CSS/JS-heavy link styling. - Update SDKs, starter themes, and code examples to use visible, contiguous link text. - Publish blog posts and videos explaining how browser reader modes differ from screen readers. - Run community surveys to collect real-world issues caused by ARIA on links. - Coordinate with product/docs/QA to align accessibility messaging and bug triage. #### OSPO - Add accessibility coding guidelines for ARIA usage to open source governance docs. - Ensure license-compliance scanning is complemented by accessibility linting where feasible. - Integrate vulnerability intake for accessibility-impacting patterns (e.g., hidden links, mislabeled controls). - Track key components and themes where ARIA misuse is likely; maintain an accurate inventory. - Offer office hours to help maintainers refactor problematic link patterns. - Support upstream accessibility projects and specs through funding or participation. - Include accessibility OKRs and reporting in open source program reviews. #### Community - Maintainers: Host roadmap clinics to prioritize removal of ARIA anti-patterns in links. - Contributors: Curate “good first issues” focused on cleaning up `aria-label` and `aria-hidden` misuse. - Sponsors: Fund audits and refactors of popular themes/plugins with known accessibility debt. - Ecosystem: Practice coordinated disclosure and shared playbooks for large cross-project accessibility issues. #### WordPress - Core: Enforce link accessibility principles in core UI patterns and coding standards. - Core Performance: Evaluate performance impact of complex DOM-heavy link styling and favor simpler patterns. - Core AI: Ensure generated content or code snippets don’t insert harmful ARIA patterns into links. - Core Program Team: Align teams on accessibility acceptance criteria for new components. - Mobile: Verify in-app readers and OS-level TTS announce links correctly; avoid ARIA-only labels. - Playground: Provide labs that demonstrate accessible vs. inaccessible link patterns. - Community: Encourage meetups/WordCamps to feature practical a11y talks based on these findings. - Training: Add lessons showing how ARIA misuse on links affects different assistive tools. - Marketing: Highlight accessibility-safe design as a differentiator for WordPress. - Support: Document common “fancy link” problems and offer step-by-step fixes. - Design: Perform UX audits specifically on link styling and readability. - Documentation: Update DevHub/HelpHub examples to embody correct ARIA practices. - Photos: Ensure link overlays in galleries retain simple, visible text. - TV: Provide captions/transcripts that mention code-level accessibility practices. - Polyglots: Watch for translation issues where visible text and `aria-label` diverge. - Accessibility: Maintain issue heatmaps around links and navigation components. - Meta: Ensure *.org sites don’t showcase problematic link behaviors. - CLI: Provide scaffolds that generate accessible link markup by default. - Hosting: Include basic accessibility checks (e.g., hidden link text) in hosting tools. - Tide: Incorporate ARIA misuse heuristics into quality scoring, with clear remediation guidance. - Openverse: Ensure attribution links remain visible and properly labeled. - Themes: Require accessible link patterns as part of review guidance. - Plugins: Strengthen reviews for ARIA misuse and hidden interactive content. #### The WPCC - Programs: Offer fellowships or stipends for accessibility maintainers focusing on navigation and links. - Projects: Run documentation and refactor sprints centered on accessible link design. - Funding experiments: Pilot grants for plugins that demonstrate exemplary ARIA usage and testing. ### FAIR - Technical independence: Encourage local tools to validate ARIA usage independent of vendor platforms. - Policies and covenants: Publish clear, public commitments about accessibility standards. - Productized governance artifacts: Distribute checklists and scorecards for ARIA practices and link design. --- ## 🧪 Hypotheses - H1: Links that rely solely on `aria-label` for their accessible name will be ignored or misannounced by mainstream browser reader modes and TTS features. - H2: Using `aria-hidden` on all visible link text will cause many browser reader modes to skip the link entirely. - H3: Splitting link text into multiple spans (one letter per span) reduces correct pronunciation and auto-translation rates compared to contiguous text. - H4: Developers overestimate how consistently ARIA attributes are consumed across different assistive technologies. --- ### 📊 Methodology - Study design: - Build a test page with multiple link variants: plain, `aria-label` only, `aria-hidden` content, span-split letters, and combinations. - Test across major browsers (Chrome, Edge, Firefox, Safari) on multiple OSes. - Data sources: - Browser native text-to-speech and reader modes. - Potential supplemental data from full screen readers and voice control tools. - Analyses: - Record whether each tool announces the link, what text it speaks, whether it auto-translates, and how it visually presents the link in reader mode. - Compare error rates and behaviors across patterns and platforms. --- ### ❓ Questions - How many users rely on browser TTS and reader modes versus full screen readers in real-world browsing? - Do mobile platforms (iOS/Android) exhibit the same ARIA behavior in their built-in readers? - Can browser vendors align on a more consistent interpretation of `aria-label` for links? - Which ARIA patterns are safe across most assistive technologies and which should be explicitly discouraged? --- ### 🔮 Future Research - Expanded testing matrix including mobile browsers, e-readers, and OS-level reading tools. - Quantitative studies on how often ARIA-based link tricks are used in popular sites and themes. - Investigating how other ARIA attributes (`aria-describedby`, `aria-labelledby`) fare in browser reader modes. - Examining impacts on non-visual cognitive tools (summarizers, auto-translation, automated note-takers). --- ### 💡 Implications - Practice: Front-end developers should favor simple link markup and avoid ARIA-only labeling or hidden link text. - Policy: Accessibility guidelines and design systems must address browser reader modes, not only screen readers. - Security: Hidden or misannounced links can be exploited for dark patterns or phishing-like experiences. - Education: Accessibility training should include demonstrations of how ARIA misuse harms non-screen-reader tools. - Funding: Support for accessibility testing infrastructure that includes browser-native assistive features. --- ### 🧠 Learning Styles Assessment - Reading level estimate: Around high-school to early college level; roughly Flesch–Kincaid Grade 11–12 based on sentence length and technical jargon. #### 👀 Visual learners - Present: Code patterns described conceptually; mental images of DOM structures. - Improve: Add annotated screenshots of browser reader modes, side-by-side “good vs. bad” link visuals, and simple diagrams of accessibility trees. #### 🔊 Aural learners - Present: Topic focuses on audio output behavior; easily mapped to spoken explanations. - Improve: Provide a short audio summary and recordings of how each browser TTS reads the different link patterns. #### 🗣️ Verbal learners - Present: Clear explanations, defined terms (ARIA, accessible name), concrete examples. - Improve: Add analogies (e.g., “labels on physical buttons”) and a mini glossary of ARIA-related terms. #### 🧩 Kinesthetic learners - Present: Encouragement to build and run one’s own tests. - Improve: Step-by-step labs (“create this HTML, then run Edge Read Aloud…”) and small hands-on challenges. #### 🧠 Logical learners - Present: Systematic test results and clear rules (“don’t use `aria-label` on links…”). - Improve: Tables summarizing behaviors by browser and link pattern; simple decision trees for link design. #### 🧑‍🤝‍🧑 Social learners - Present: Invitation to share test results and comment. - Improve: Structured discussion prompts, community testing sessions, and guided group audits. #### 🧘‍♀️ Solitary learners - Present: Self-paced reading and code experimentation. - Improve: Reflection prompts (“audit three pages you built; where did you use ARIA on links?”) and self-check quizzes. #### 🌿 Naturalistic learners - Present: Limited direct environmental framing. - Improve: Analogies to ecosystems (how different tools “feed” on the accessibility tree) and broader reflections on inclusive digital environments. --- ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Focus on ARIA semantics, accessible names, and how browsers build the accessibility tree. - Improve: Stress that native semantics and visible text are primary; ARIA is a supplement, not a replacement. #### Keyboard navigation - Present: Not directly tested, but link patterns could affect focus visibility if misused. - Improve: Recommend verifying focus order and visible focus indicators for all link variants. #### Contrast and readability - Present: Notes that Firefox restyles span-split links (e.g., white text), potentially harming contrast. - Improve: Explicit guidance on maintaining color contrast and consistent link styling. #### Text resizing and reflow - Present: Not central, but span-heavy link text could behave oddly with zoom and wrapping. - Improve: Encourage testing zoom and responsive layouts for readability and link integrity. #### Media and captions - Present: Article is text-based; focus is on TTS behavior. - Improve: Provide video or audio demos with captions and transcripts of how each browser behaves. #### Forms and interactions - Present: Focus on links (interactive elements) and their accessible names. - Improve: Extend lessons to buttons and other controls, reinforcing consistent naming and visibility. #### Standards reference - Present: References WCAG 2.5.3 and 4.1.2 through intentional failures in test cases. - Improve: Map each observed failure to WCAG 2.2 AA success criteria with explicit callouts. --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: Uses Korean words as `aria-label` examples, mainly as a technical signal. - Improve: Broader multilingual examples and explicit discussion of translation and localization impacts. #### Inclusive language - Present: Technical, respectful tone; minimal jargon without being exclusionary. - Improve: More plain-language summaries at key points to support non-expert readers. #### Neurodiversity support - Present: Clear structure and bullet-point summaries of results. - Improve: Increase use of headings, consistent patterns, and callout boxes for key rules. #### Representation - Present: Highlights contributions from another expert (Amelia Bellamy-Royds). - Improve: More explicit acknowledgement of diverse user needs and assistive technology use cases. #### Psychological safety - Present: Invites experimentation and corrections, acknowledges fallibility. - Improve: Provide clear guidance that mistakes are learning opportunities and encourage constructive feedback. --- ### ✅ Logical Validity #### Strong reasoning - Inductive strength: Systematically testing multiple link patterns across several browsers and summarizing consistent behaviors strengthens the general rule to avoid ARIA hacks on links. - Causal reasoning: Demonstrates that specific code patterns (e.g., `aria-hidden` on link text) cause links to disappear from reader modes, not just correlate with them. #### Fallacies - None obvious; the author does not claim universal coverage and explicitly invites more testing and corrections, which mitigates overgeneralization. #### Tone of voice - Tone: Pragmatic, slightly opinionated, and practitioner-focused. - Uses direct language (“Don’t use aria-label on links”) but grounds it in observed evidence and standards context. --- ### 🛡️ DARVO Analysis - Deny: No denial or minimization of accessibility problems; the article foregrounds them. - Attack: No personal attacks; critiques are aimed at patterns and tools, not people. - Reverse victim/offender: No attempt to present implementers of problematic patterns as victims; instead, the focus is on end users facing barriers. --- ## 🎯 Conclusion The article shows that visually fancy, ARIA-heavy link patterns can seriously undermine accessibility for users of browser-based reader and text-to-speech tools. Because these tools often ignore `aria-label` and respect `aria-hidden`, links can become invisible or mislabeled. Practical next steps: simplify link markup, keep link text visible and contiguous, avoid `aria-hidden` inside links, and test with multiple assistive technologies—not just screen readers. --- ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: H3. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] ARIA-heavy links often break browser readers > [!quote] [Barriers from Links with ARIA](https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html) by [[Adrian Roselli]] via [[adrianroselli.com]]. Published 2026-01-22. Accessed 2026-01-26. > “The text-to-speech features seem to respect the aria-hidden but ignore the aria-label.” Used to show that browser-native assistive tools differ from screen readers in ARIA handling. [view highlight](https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Avoid aria-label and aria-hidden on links > [!quote] [Barriers from Links with ARIA](https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html) > “Don’t use aria-label on links; Don’t use aria-hidden within links; Don’t split the letters of a word across elements.” Captures Roselli’s three core prescriptive rules for accessible link patterns. [view highlight](https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] ARIA-heavy link patterns harm accessibility - Links that depend on `aria-label` or `aria-hidden` for their text often fail in browser reader modes. - Pointer: Roselli (2026), “Barriers from Links with ARIA”. - Links: [[Accessible-Links]] [[Assistive-Technology-Variability]] #### [Z2] Browser TTS and screen readers use ARIA differently - Browser text-to-speech frequently ignores `aria-label` but respects `aria-hidden`, unlike many screen readers. - Pointer: Roselli (2026), multi-browser tests. - Links: [[Assistive-Technology-Variability]] [[ARIA-Limitations]] --- ### ✏️ Fleeting Queue (Extract by Selection) - [F1] Audit my projects for links using aria-label instead of visible text — context/https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html #fleeting #inbox - [F2] Build a small test page reproducing Roselli’s link patterns and run them through my browsers’ reader modes — context/https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html #fleeting #inbox - [F3] Update my accessibility guidelines to explicitly warn against aria-hidden inside links — context/https://adrianroselli.com/2026/01/barriers-from-links-with-aria.html #fleeting #inbox