How screen readers actually navigate a website (and why it changes how you should think about fixes)

A lot of accessibility findings on an audit report ("missing alt text," "heading levels skip from h2 to h4," "button has no accessible name") read like arbitrary rule-following until you understand what a screen reader is actually doing with your page. Once you do, most findings stop feeling arbitrary.

The page isn't read top to bottom like a document

A sighted visitor scans a page visually — eyes jump straight to a big headline, a prominent button, a familiar navigation bar, guided by layout and visual hierarchy. A screen reader user doesn't have that visual shortcut. Instead, screen readers expose the page as a structured tree built from the underlying HTML: headings, landmarks (like "navigation," "main content," "footer"), links, form fields, and buttons, each with a name and a role. Screen reader users navigate that tree directly — jumping heading to heading, landmark to landmark, or link to link — using dedicated keyboard shortcuts, rather than scrolling and scanning the way a sighted visitor would.

This is why heading structure matters so much more than it looks like it should. A sighted user glances at a page and instantly understands "this is the important title, that's a subsection." A screen reader user jumping between headings to get an overview of a page is depending entirely on your h1 through h6 tags being used in a logical order — skip from an h2 straight to an h4 and you haven't broken anything visually, but you've broken the map a screen reader user relies on to understand the page's structure.

"Accessible name" is doing a lot of work

Every interactive element — a button, a link, a form field — needs what's called an accessible name: the text a screen reader actually announces for that element. Sometimes that's obvious (a button that says "Submit" has "Submit" as its accessible name). But an icon-only button (a magnifying glass for search, a trash can for delete) has no visible text at all — if it doesn't have an aria-label or similar attribute, a screen reader announces it as just "button," with no indication of what it does. This is one of the single most common findings on real audits, and it's completely invisible if you're only looking at the page, because visually the icon "obviously" means search or delete.

Why alt text isn't just "describe the image"

Alt text exists specifically because a screen reader can't interpret an image the way a sighted person does — it can only announce whatever text you've provided as a substitute. Good alt text describes the image's function or content in context, not a generic caption: an image that's purely decorative should have empty alt text (alt="") so a screen reader skips it entirely rather than announcing something unhelpful like "image1234.jpg"; a product photo that's the only source of information about a product's color or design needs real, specific alt text; an image used as a button (a social-media icon linking to your Twitter/X page, say) needs alt text describing the action, not the icon ("Follow us on X," not "bird logo").

The practical takeaway

None of this requires memorizing WCAG's full technical language. It requires one mental shift: before fixing a finding, ask "what would a screen reader user actually experience here, using the structural information in the code, not the visual layout?" Most of what shows up on an audit report — heading order, accessible names, alt text, form labels — traces back to that same underlying question. See a real breakdown of WCAG's criteria organized by principle, or check your website for free to see what a scan actually finds on your own site.