WCAG 1.3.1 Info and Relationships (Level A) requires that any structure or relationship you show visually — a heading, a list, a data table, a field label, emphasized text — is also present in your code or in text. If it can’t be “programmatically determined,” a screen reader user never learns the relationship exists.

What 1.3.1 actually requires

The official wording from the W3C is short: “Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.”

Unpack it: every time you use visual design to communicate meaning, the same meaning has to exist somewhere a machine can read it. Make text big and bold to say “new section,” and the markup must say “heading.” Bullet and indent items to say “this is a list,” and the markup must be a real <ul>.

The key phrase is programmatically determined. Sighted users decode layout instantly — spacing, weight, color, position. A blind user relying on a screen reader (JAWS, NVDA, VoiceOver) receives none of that, only whatever your HTML actually declares. 1.3.1 forces the visual story and the coded story to match.

Who it affects

This criterion is overwhelmingly about screen reader users — people who are blind or have very low vision and listen to the page — and deaf-blind users reading a refreshable braille display. It also helps people using custom stylesheets or reader modes that strip the design to bare structure. When relationships live only in CSS, all of them get a flat, meaningless stream of words.

Two concrete ways it breaks for them:

  • A screen reader user navigates by pulling up a list of headings to jump around your page, exactly the way a sighted user skims. If your “headings” are styled <div>s, that list is empty and the page is one undifferentiated wall.
  • On a form, a screen reader announces the label when focus lands on a field. If the label isn’t programmatically tied to the input, the user hears “edit text, blank” and has no idea what to type.

Concrete failures and how to fix them

These are the 1.3.1 violations we find most often, mapped to the W3C failure techniques.

Fake headings (failure F2)

A common pattern — visually a heading, semantically nothing:

<!-- FAILS 1.3.1: looks like a heading, isn't one -->
<p class="big-bold">Shipping & Returns</p>
<!-- PASSES: real heading, announced as a heading, appears in the headings list -->
<h2>Shipping &amp; Returns</h2>

Keep your CSS — just hang it on the real element. The visual result is identical; the coded result is now correct.

Lists that aren’t lists (failure F2)

Bullets typed as text, or items separated by <br>, don’t tell a screen reader “5 items.” Use list markup so it announces “list, 5 items”:

<!-- FAILS -->
<div>• Free shipping<br>• 30-day returns<br>• 24/7 support</div>

<!-- PASSES -->
<ul>
  <li>Free shipping</li>
  <li>30-day returns</li>
  <li>24/7 support</li>
</ul>

Data tables without header associations (failures F46, F91)

The W3C uses a bus schedule as its canonical example: stops down the first column, buses across the first row. For a screen reader to tell you “Route 12, Main St, 8:15,” the header cells must be marked and scoped:

<!-- PASSES: scope ties each cell to its row/column header -->
<table>
  <caption>Weekday bus schedule</caption>
  <tr><th scope="col">Stop</th><th scope="col">Route 12</th></tr>
  <tr><th scope="row">Main St</th><td>8:15</td></tr>
</table>

Using <td> for header cells, or — the inverse, technique F46 — putting <th> inside a table you only used for visual layout, both fail. Layout tables should carry no header markup at all (and modern layout should use CSS, not tables).

Form labels not tied to fields (failure F2 / related to 4.1.2)

A visible label sitting near a field isn’t enough; the association has to be in the code:

<!-- FAILS: label is just text floating next to the input -->
<span>Email</span> <input type="email">

<!-- PASSES: for/id binds them; screen reader announces "Email, edit text" -->
<label for="email">Email</label>
<input type="email" id="email">

Placeholder text is not a substitute — it isn’t a label, and it vanishes on focus. See accessible forms for the full pattern, and note this overlaps with 4.1.2 Name, Role, Value.

Meaning carried only by visual style (failure F2)

If you bold a word to mean “important” or color a row to mean “sold out,” code that meaning too — <strong>/<em> for emphasis, plus a text or icon cue for status — so the relationship survives when the styling is gone. This pairs with 3.3.2 Labels or Instructions on forms.

How to test for 1.3.1

You can catch most violations in a few minutes:

  1. Turn off CSS (or use your browser’s reader mode). The page should still make sense as an outline — headings, lists, and labels intact. If it collapses into a blob, your structure lives in CSS, not markup.
  2. Pull up the headings list in a screen reader, or use a browser extension that lists headings. Are your visual headings there, in a sensible order, with no level skips?
  3. Tab through every form field. Each one should announce a clear label. “Edit, blank” is a failure.
  4. Inspect tables. Confirm header cells are <th> with scope, and that layout-only tables contain no header markup.
  5. Run an automated scanner for the obvious cases (missing labels, empty headings), then verify by hand — tools can’t judge whether bold text was meant as a heading. That judgment is why thorough work pairs scanners with a manual accessibility audit.

For the structural side specifically, our headings and landmarks guide and ARIA labels and roles guide go deeper. 1.3.1 lives under the Perceivable principle of the POUR framework.

Why 1.3.1 matters legally

1.3.1 is one of the most frequently cited criteria in ADA web claims, for a simple reason: it’s everywhere, and a plaintiff’s tester can document a failure in seconds with a screen reader. Missing form labels and broken heading structure are textbook items in ADA demand letters.

The volume is real. UsableNet’s 2024 Year-End Report counted more than 4,000 ADA digital-accessibility lawsuits filed in U.S. courts that year, roughly in line with 2023’s total. Notably, that same report found over 1,000 of those businesses were sued despite having an accessibility widget installed — overlays don’t repair the underlying markup that 1.3.1 requires. Courts and the DOJ treat WCAG 2.1 AA as the practical benchmark under ADA Title III, and 1.3.1 is a Level A criterion — the floor, not the ceiling.

This is general information, not legal advice. For your specific exposure, consult a qualified attorney.

Fixing it the right way

Because 1.3.1 is about intent encoded in markup, it can’t be patched from the outside. An overlay script can’t know that your “Shipping & Returns” paragraph was supposed to be a heading, or which table cells you meant as headers — that information only exists in your code. (More on why overlays don’t work and overlay vs. manual remediation.)

Curbcut fixes 1.3.1 the only durable way: by rewriting the actual HTML — promoting fake headings to real ones, converting visual lists to <ul>/<ol>, binding labels to fields, and scoping table headers. It’s hands-on code work by a person, deliberately anti-overlay, and we can document the result in a VPAT. Want to see where your structure breaks first? Start with a free scan and we’ll show you every heading, label, and table that fails 1.3.1 — then remediate it for you.