← All criteria

Perceivable · Level A · 1.3.1

Info and Relationships

Any structure that's visually obvious — this text is a heading, these lines are a list, this cell belongs under that column header, this label goes with that input — has to be encoded in the markup itself, not just implied by how it looks, so assistive technology can perceive the same structure a sighted user sees at a glance.

  • Blind

How to recognize it

Strip the CSS, or look at the DOM outline / a screen reader's rendering, and check whether the structure survives. A heading made to look like a heading with bold text and a larger font size, but wrapped in a plain <p> or <div> instead of <h2>/<h3>, is structurally invisible even though it's visually obvious. A list separated with line breaks and typed bullet characters (•) instead of <ul><li> reads to a screen reader as one undifferentiated paragraph, not a list of three items. A data table built from <div>s and CSS grid to get the visual layout right, but without <table>/<th>/<td>, has no row or column relationships at all — a screen reader can't announce 'column 3, header: Price' because there's no header to associate. A label positioned right next to a form field but never actually tied to it in markup (no <label for> pairing) looks associated but isn't — this overlaps with 4.1.2, but from the relationship side rather than the naming-mechanism side.

How to fix it

Match the semantic element to the actual structure, not just its appearance: real heading tags for headings, real <ul>/<ol>/<li> for lists, real <table> with <th scope="col"> or <th scope="row"> for tabular data, and <label for="id"> (or wrapping the input inside the label) for every form field. This doesn't mean every heading-sized piece of text has to be a heading tag — a card title inside a repeating component can legitimately just be styled text if it isn't part of the page's actual outline. The rule is to make the markup match the real structure, not to tag everything as structurally significant.

Example

Avoid

<div class="heading">Pricing</div>
Included:<br>
• Free shipping<br>
• 30-day returns<br>
• Warranty
<label>Email</label>
<input type="email">

Prefer

<h2>Pricing</h2>
<ul>
  <li>Free shipping</li>
  <li>30-day returns</li>
  <li>Warranty</li>
</ul>
<label for="email">Email</label>
<input type="email" id="email">

Resources

  • 4.1.2 Name, Role, Value

    A form label tied to its input with <label for> is both: it's the relationship 1.3.1 cares about, and it's also how the input gets the accessible name 4.1.2 requires. Same markup, two criteria satisfied at once.

  • 1.3.2 Meaningful Sequence

    1.3.1 asks whether structure and relationships (headings, lists, tables, labels) are encoded in the markup at all; 1.3.2 asks whether the order that markup appears in is the right one. A table can have perfect <th>/<td> relationships and still be in a confusing sequence on the page, or vice versa.

  • 3.3.2 Labels or Instructions

    A field can have a technically correct <label for> association (this criterion's territory) and still fail 3.3.2 if the label text itself is missing or unhelpful. This is the markup mechanism; 3.3.2 is the content that mechanism is supposed to carry.

  • 2.4.6 Headings and Labels

    This criterion asks whether a heading is marked up as a real heading at all; 2.4.6 asks whether it's worth reading once it is. A page can have perfect heading markup and still fail 2.4.6 on wording.