Screen Readers and Site Structure: What Ontario's AODA and WCAG Require So Blind Customers Can Navigate (2026)

A sighted visitor scans your page in a glance — they see the headline, the menu, the "Add to cart" button, and the footer all at once, and their eye jumps to what matters. A blind customer using a screen reader gets none of that at-a-glance map. They move through your page in a line, top to bottom, or they jump by structure: heading to heading, landmark to landmark, link to link. If that structure isn't really there — if your headings are just big bold text, if your buttons have no name, if every link says "click here" — the screen reader has nothing to jump to, and the customer is left crawling through your page word by word. Most of the time they leave. And because this is about meaning rather than a broken page, an automated scanner only sees part of it.

Key facts

• WCAG 1.3.1 Info and Relationships is Level A (Web Content Accessibility Guidelines): structure conveyed visually — headings, lists, labels, tables — must also be available to assistive technology in the code, not faked with styling (W3C).
• WCAG 4.1.2 Name, Role, Value is Level A: every interactive control (button, link, form field) must expose a name and role a screen reader can announce — an icon-only button with no label is silent (W3C).
• WCAG 2.4.6 Headings and Labels is Level AA, and 2.4.4 Link Purpose (In Context) is Level A: headings and link text must describe what they point to, which is why a page full of "click here" links fails (W3C).
• WCAG 2.4.2 Page Titled and 3.1.1 Language of Page are both Level A: each page needs a descriptive <title>, and the page's language must be set in code so the screen reader uses the right voice and pronunciation (W3C).
• Ontario's IASR (Integrated Accessibility Standards Regulation, O. Reg. 191/11) s.14 requires organizations with 50 or more employees to make public websites conform to WCAG 2.0 Level AA — every criterion above sits inside that floor (ontario.ca, O. Reg. 191/11).
• The next ACR (Accessibility Compliance Report) deadline for Ontario organizations with 20 or more employees is December 31, 2026 (ontario.ca). WebAIM's 2024 analysis of one million home pages found detectable WCAG failures on 95.9% of them, with the most common being structural — missing form labels, empty links and buttons, and missing document language (WebAIM, 2024 WebAIM Million).

What does Ontario's AODA require for screen-reader accessibility?

Ontario's AODA (Accessibility for Ontarians with Disabilities Act) sets the policy; the IASR sets the technical bar. Section 14 requires organizations with 50 or more employees to make public web content conform to WCAG 2.0 Level AA. There is no separate "screen reader rule" in the law — instead, screen-reader access is the result of meeting a cluster of WCAG criteria about structure: Info and Relationships, Name/Role/Value, Headings and Labels, Link Purpose, Page Titled, and Language of Page. Meet those, and a screen reader can navigate your site. Miss them, and it can't — regardless of how the page looks to a sighted user.

This is also why screen-reader access is a clearer test of real compliance than almost anything else. You can have an attractive, modern-looking site that a screen reader still can't get through, because the visual polish lives in CSS while the underlying structure is missing from the HTML. The two are separate, and the law cares about the structure.

How does a screen reader actually move through your page?

Screen-reader users rarely read straight down a page — that's slow. Instead they navigate by structure, and three structures do most of the work:

• Headings. Users pull up a list of all headings to skim the page like a table of contents and jump to a section. This only works if your headings are real <h1>–<h6> elements in a logical order, not text that's merely large and bold. Skipping from an <h1> straight to an <h4>, or wrapping a whole paragraph in a heading tag for styling, breaks the map.
• Landmarks. Regions like header, navigation, main, and footer let a user jump straight to the main content or back to the menu. Without them, there's no "skip to content" path and every visit starts by wading through the same nav.
• Links and controls. Users also pull up a list of just the links, read out of context. "Read more," "click here," and "learn more" are useless in that list — ten identical entries pointing nowhere obvious. Link text needs to make sense on its own (2.4.4), and every button and form field needs a real, announced name (4.1.2). This is the same gap behind accessible forms and checkout: an input with no programmatic label is just "edit text" to a screen reader.

This is precisely what an overlay widget can't fix. A script layered on top can't invent the heading hierarchy, landmarks, and labels your HTML never had — that structure has to exist in the source. It's the same reason a scan is not an audit: a crawler can flag an image with no alt text or a button with no name, but it can't tell whether your heading order actually makes sense or whether a link's text is meaningful to a human. That judgment needs a person with a screen reader.

How do you check whether a screen reader can use your site — and what's the risk if you don't?

You can run a useful first pass yourself in a few minutes. Every Mac ships with VoiceOver (Cmd-F5) and every Windows PC with Narrator (Ctrl-Win-Enter); the free NVDA screen reader is widely used on Windows. Turn one on and:

1. Pull up the headings list and read it like an outline. Does it describe the page in order, with one <h1>, no skipped levels, and no decorative text masquerading as a heading?
2. Tab through every control and listen. Does each button, link, and field announce a name and what it does (4.1.2)? Silent or "unlabelled" controls are failures — especially icon-only buttons.
3. Pull up the links list. Does each link make sense out of context, or is it a wall of "click here" (2.4.4)?
4. Walk a real task — find a product, add to cart, fill the form, reach checkout — using only the keyboard and the screen reader. This overlaps with keyboard accessibility: if you can't tab to it, a screen-reader user can't reach it either.

In Ontario, the AODA has no private right of action — individuals cannot sue under it. The enforcement path for a person is the HRTO (Human Rights Tribunal of Ontario), which hears discrimination complaints under the Ontario Human Rights Code. A blind customer who can't navigate your site to buy what a sighted customer can buy has a plausible claim of unequal access to goods and services. And if you sell to the US, structural failures that lock out screen readers are among the most-cited issues in ADA litigation — part of the 5,114 digital accessibility lawsuits filed across US courts in 2025 (UsableNet). As with any gap, the durable position is documented remediation: the structural issues you found, the fixes you shipped, and the dates — which is also what an honest ACR should reflect by December 31, 2026. Building to WCAG 2.2, the current standard, only strengthens that position.

See whether your site flags structural, labelling, or other accessibility issues — free Vayle Report, about 30 seconds: vayle.art. It detects overlays, surfaces real WCAG failures, and tells you exactly what legally applies to your organization in Ontario. No obligation.

Vayle is a remote-first accessibility-engineering studio serving Ontario. General information, not legal advice.