> Markdown version of [/videos/1674-semantic-html-means-it-s-semantic-right-right](https://www.wearedevelopers.com/videos/1674-semantic-html-means-it-s-semantic-right-right). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Semantic HTML means it's semantic, right? Right?

Semantic HTML doesn't guarantee an accessible experience. Discover why screen readers silently ignore your perfectly nested tags, and how to properly audit your accessibility tree.

- **Speakers:** [Emma Dawson](https://www.wearedevelopers.com/@emma-dawson)
- **Event:** World Congress 2025
- **Published:** August 20, 2025
- **Duration:** 23:13
- **URL:** https://www.wearedevelopers.com/videos/1674-semantic-html-means-it-s-semantic-right-right

## Summary

While developers are often taught to use semantic HTML to improve code quality and user experience, visually semantic tags do not automatically translate to an accessible experience for assistive technologies. The browser parsing process turns HTML into a standard DOM tree for visual rendering, but simultaneously constructs a parallel accessibility tree for screen readers like NVDA, JAWS, and VoiceOver. This secondary tree selectively filters out decorative elements like standard divs while assigning specific navigation roles to interactive or structural nodes.

Navigating the gap between HTML intent and screen reader output reveals several surprising behaviors heavily dependent on context. For instance, header and footer tags only operate as recognizable structural landmarks when acting as direct descendants of the body element; nesting them inside an article tag abruptly strips their semantic value. Similarly, section elements are completely ignored by default to prevent audio clutter, requiring developers to explicitly promote them to recognized regions using an aria-label. Another frequent development pitfall involves muddying the explicit distinction between interactive elements. Styling anchor tags to trigger JavaScript actions confuses users relying on screen reader form controls, as links inherently imply page navigation while button tags imply local UI state changes.

Beyond structural containers, basic text styling tags utilized for emphasis or strong text are structurally valid in the DOM but are almost universally ignored by default screen reader voice intonation, demanding alternative coding pathways if the visual styling conveys critical meaning. Even specialized tags for deletion or insertion, which are conceptually ideal for displaying discounted e-commerce pricing, suffer from inconsistent cross-browser support and often read both the old and new prices sequentially without distinction. Ultimately, shipping truly accessible code requires auditing the semantic output directly within the browser's developer tools to guarantee that the functional audio experience accurately reflects the visual interface.

**Keywords:** semantic html limitations, accessibility tree rendering, screen reader output, dom tree conversion, assistive technology compliance, aria landmark promotion, html element a11y roles, anchor link vs button, header block scoping, text formatting accessibility, ecommerce pricing elements, cross-browser screen readers, voiceover and nvda, developer tools a11y panel, accessible front-end development

## Chapters

1. **The case for semantic HTML in accessibility** (01:02) — Using correct elements improves code quality and creates consistent user experiences across different abilities.
1. **Browser rendering process and the accessibility tree** (02:04) — How the DOM translates interactive and meaningful elements into an accessibility tree for screen readers.
1. **Translating code elements into accessible tree roles** (03:42) — Mapping standard anchor and button tags to specific accessibility roles while ignoring meaningless structural elements.
1. **Testing screen readers and practical tooling combinations** (05:16) — Using specific pairings of screen readers and browsers yields accurate testing results for accessible features.
1. **Defining good bad and ugly semantic HTML elements** (07:41) — Categorizing structural elements by their genuine utility and how they interact with the accessibility tree.
1. **Managing noisy section elements in assistive technologies** (09:41) — Upgrading standard HTML sections with an accessible name establishes beneficial landmark regions.
1. **Contextual behavior of header and footer elements** (12:27) — Header and footer elements only act as landmarks when implemented as direct descendants of the body.
1. **Differentiating anchor links from interactive button elements** (14:05) — Assigning precise interactions via correct elements prevents confusing behavior for screen reader users expecting navigation.
1. **Limitations of semantic text styling for screen readers** (16:06) — Relying on elements like bold or emphasis for meaning fails because the accessibility tree ignores them.
1. **Handling inconsistent deletion and insertion element rendering** (17:45) — Managing cross-browser inconsistencies in announcing modified strings requires understanding current limited element support.
1. **Navigating unreliable separator and abbreviation tag compatibility** (20:36) — Understanding how screen readers inconsistently execute horizontal rules, line breaks, and abbreviations prevents poor accessibility defaults.

## Related Moments

- [Navigating accessibility standards and screen reader support limitations](https://www.wearedevelopers.com/videos/1806-nolojs-avoiding-javascript-cruft-with-html-and-css-aaron-t-grogg) (from "NoLoJS - Avoiding JavaScript Cruft with HTML and CSS - Aaron T. Grogg")
- [Leveraging semantic HTML output tags and aria live regions](https://www.wearedevelopers.com/videos/1730-wearedevelopers-live-accessibility-isn-t-magic-longevity-devrel-in-times-of-ai-and-more) (from "WeAreDevelopers LIVE - Accessibility isn't magic, Longevity, Devrel in times of AI and more")
- [Leveraging semantic HTML instead of custom JavaScript elements](https://www.wearedevelopers.com/videos/403-the-what-why-who-and-how-of-accessibility-on-the-web) (from "The What, Why, Who and How of accessibility on the web")
- [W3C accessibility guidelines and essential practices](https://www.wearedevelopers.com/videos/1289-wad-live-22-01-2025-exploring-ai-web-development-and-accessibility-in-tech-with-stefan-judis) (from "WAD Live 22/01/2025: Exploring AI, Web Development, and Accessibility in Tech with Stefan Judis")
- [Building interactive accessibility learning resources for web developers](https://www.wearedevelopers.com/videos/1742-wearedevelopers-live-inclusion-accessibility-automation) (from "WeAreDevelopers LIVE – Inclusion, Accessibility & Automation")
- [Evaluating user experience through screen readers and landmarks](https://www.wearedevelopers.com/videos/507-decoding-web-accessibility-through-audit) (from "Decoding web accessibility through audit")

## Related Articles

- [Semantic HTML Elements You’re (Probably) Not Using But Should](https://www.wearedevelopers.com/magazine/667-semantic-html-elements-you-re-probably-not-using-but-should)
- [The State of HTML 2024: What can we learn from it?](https://www.wearedevelopers.com/magazine/506-the-state-of-html-2024-what-can-we-learn-from-it)
- [Why We Should Be Using the <search> Element More](https://www.wearedevelopers.com/magazine/711-why-we-should-be-using-the-search-element-more)
- [The Web We Broke (And Why AI Agents Are Paying the Price) - AgentCon Berlin](https://www.wearedevelopers.com/magazine/735-the-web-we-broke-and-why-ai-agents-are-paying-the-price-agentcon-berlin)

## Related Jobs

- [Senior Web Designer, Growth](https://www.wearedevelopers.com/jobs/ext/102722-senior-web-designer-growth) at **Intercom, Inc.**
- [Senior Product UI Designer](https://www.wearedevelopers.com/jobs/ext/1998621-senior-product-ui-designer) at **Almedia**
- [Working Student Frontend Development](https://www.wearedevelopers.com/jobs/ext/1185791-working-student-frontend-development) at **ZEISS Group**
- [Remote Senior Full-Stack Engineer](https://www.wearedevelopers.com/jobs/ext/679408-remote-senior-full-stack-engineer) at **Edge Impulse**
- [Remote Senior Full-Stack Engineer](https://www.wearedevelopers.com/jobs/ext/645320-remote-senior-full-stack-engineer) at **Edge Impulse**
- [Remote Senior Full-Stack Engineer](https://www.wearedevelopers.com/jobs/ext/643342-remote-senior-full-stack-engineer) at **Edge Impulse**