Annex

WCAG 1.3.1 — Info and Relationships

Structure you can see — headings, lists, tables, form labels — must exist in the markup too, not be simulated with font size and colour alone.

What this means for a store

The expensive version of this failure is in the checkout form. A field whose label is not programmatically associated leaves a screen reader user guessing what to type, and they abandon at the payment step. That is a lost order, at the point in the funnel where the customer was most committed.

The failures we see most often

A visible label sits next to a field but is not connected to it with label/for.

Why it happens: The label is placed as a separate text element. It looks correct and is functionally disconnected.

Headings created by increasing font size instead of using h1 to h6.

Why it happens: In page builders, making text bigger is easier than choosing a heading element.

Heading levels skipped, for example h1 straight to h4.

Why it happens: The heading element is chosen for the style it carries rather than for its place in the document outline.

A product specification table built from aligned divs instead of a real table.

Why it happens: CSS grid makes a visual table easy. The row and column relationships never reach assistive technology.

How to check it yourself

  1. Click each form label. If the cursor jumps into the associated field, the association exists.
  2. List the page's headings in a browser accessibility inspector and check the order is sequential.
  3. Disable CSS and confirm the page still reads as a sensible document.

Fixing it, by platform

What this page covers

What follows is the practical meaning of a WCAG 2.2 success criterion. Automated tests catch only a portion of accessibility issues, so a clean scan result does not mean compliance. Platform paths vary by version and theme.

Source

The formal definition of this criterion: W3C — Understanding Info and Relationships