Screen readers need semantic HTML—proper heading tags, list structures, and button elements—to navigate pages logically and announce what things do; without it, a page becomes a confusing list of unrelated text and links. A visually beautiful page can be completely unusable to someone who can't see the layout.
Semantic HTML is the practice of using HTML tags that describe the meaning of content, not just its appearance. For screen reader users, semantic markup is the difference between navigating a website intuitively and struggling through a maze of undifferentiated text.
When you use proper semantic tags—like <nav>, <main>, <article>, and <aside>—screen readers understand the page structure and announce landmarks. A screen reader user can then jump directly to main content, skip navigation, or find a specific article without hearing every element on the page. This is critical for cognitive load and navigation efficiency.
Heading tags (<h1> through <h6>) serve dual purposes: they structure visual content and create an outline that screen reader users can traverse. Skipping heading levels—jumping from h1 to h3—confuses screen readers and breaks the conceptual hierarchy. Think of it like an outline: you wouldn't jump from a main point to a sub-sub-point without the intermediate section.
Screen reader users often navigate by headings first to understand page content. If your headings are semantically accurate and properly hierarchized, they gain a mental map before diving into details. AI tools can audit heading structure and flag violations, but understanding the principle helps you write semantic HTML intentionally.
When semantic HTML isn't sufficient—particularly in complex interactive interfaces—ARIA (Accessible Rich Internet Applications) attributes bridge the gap. ARIA roles like role="button", role="navigation", and role="region" tell assistive technology what a non-semantic element does.
However, ARIA is a supplement, not a replacement. A common mistake: applying role="button" to a <div> instead of using <button>. The semantic element includes keyboard interactions, focus management, and proper announcement by default. ARIA requires careful implementation of keyboard behavior, focus management, and state announcements—which is why AI-powered accessibility checkers flag over-reliance on ARIA without proper keyboard support.
For content that updates dynamically—like notifications, search results, or form feedback—the ARIA property aria-live="polite" or aria-live="assertive" tells screen readers to announce changes. The distinction matters: polite waits for a pause in speech, while assertive interrupts. Choosing the right setting depends on urgency. An authentication error is assertive; a chat message arriving is polite.
AI tools can detect missing live regions in dynamic interfaces and recommend placement, but they can't always determine intent. If a region updates but users don't need to know immediately, a live region creates unnecessary noise.
The most reliable test is actual screen reader testing. NVDA (free, open-source) and JAWS are industry standards. But AI accessibility checkers can automatically scan for common semantic violations: missing alt text, improper heading hierarchy, unlabeled form fields, and insufficient color contrast.
Try this: Open a website you use regularly with a screen reader (try NVDA if you haven't already). Turn off your monitor or close your eyes, and navigate by headings and landmarks only. Notice which pages feel organized and which feel chaotic. That distinction correlates directly to semantic HTML quality. Then use an AI accessibility checker to audit the page and see if it catches what you experienced.
Peri can explain this concept, give practical examples, help you decide whether it applies to your situation, or recommend a journey if appropriate.
Explore related journeys or tell Peri what you're working through.