WCAG 1.3.1 Info and Relationships: headings, lists, labels

Most of what a sighted visitor takes in at a glance, which text is a heading, which items form a list, which header belongs to which table column, which label goes with which field, is told by size, weight, spacing and position. Criterion 1.3.1 asks that the same facts exist in the markup. This page covers what the criterion requires, what W3C lists as failures and sufficient fixes for headings, lists, tables, form labels, field groups and landmarks, why a skipped heading level is not a failure on its own, real failing and passing code, a step-by-step test, and exactly what GotAlt's tools check and cannot check.

What WCAG 1.3.1 requires

Success criterion 1.3.1 asks that information, structure and relationships conveyed through presentation "can be programmatically determined or are available in text" (W3C, WCAG 2.2). It is Level A, has been in WCAG since WCAG 2.0, and is kept in 2.1 and 2.2.

W3C's Understanding 1.3.1 defines "programmatically determined" as "determined by software from author-supplied data" in a way that different user agents, including assistive technologies, can present. Its intent is that relationships implied by visual formatting are "preserved when the presentation format changes", for example when a screen reader reads the page or a user substitutes their own style sheet. One method W3C gives for checking is to "access the information serially in different modalities". Three clarifications from the same page:

• "Or are available in text" is the fallback for technologies that cannot express a relationship in code, such as a note that "all required fields are marked with an asterisk". W3C says that where the technology supports programmatic relationships, that is "strongly encouraged" over describing them in text.
• Color values are not covered here. "It is not required that color values be programmatically determined"; color is handled by 1.4.1 Use of Color.
• Reading order is a different criterion. Whether the sequence in the code makes sense is 1.3.2 Meaningful Sequence.

Because 1.3.1 is Level A, it is inside every target the laws in our register name: WCAG 2.0 AA for Section 508 and Ontario's AODA, and WCAG 2.1 AA for the ADA Title II web rule and, through EN 301 549, the European Accessibility Act. Our laws hub covers each. This page explains a technical standard and is not legal advice.

How often structure is missing

The 2026 WebAIM Million (data collected February 2026) is the standard reference for real-world failure rates. Its structure findings:

WebAIM states the reason headings matter: "headings are the primary mechanism used by screen reader users to navigate content". It also reports that 94.9% of home pages with at least one h6 had skipped heading levels, which "suggests that most of these headings probably do not reflect the actual document structure". That observation is the key to the skipped-level question below: the skip is usually a symptom of choosing a heading for its size. Missing labels, the first row, are covered under form labels and in our page on the most common accessibility errors.

What you see, and what the code has to say

The sufficient techniques are examples, not a closed list. W3C states that content can satisfy WCAG "even if it does not use any of the documented techniques". The failures are the reliable part: if your markup matches one, it fails. W3C's Understanding page for 1.3.1 also lists F42, emulating links, and, for plain text, F33, white space used to make columns and F34, white space used to format tables.

Headings

Heading markup does two jobs: it tells assistive technology that the text is a heading, and its level shows how sections nest. W3C's technique H42 has two checks: heading markup is used when content is a heading, and "heading markup is not used when content is not a heading." Both directions are failures. Text that looks like a heading but is a styled p is failure F2. A heading tag chosen only for its font size is F43, whose first example is an address set in an h4 to get large bold type: it "should not be marked as a heading".

Failing, per F2. The look says heading, the markup says paragraph:

<p class="big-bold">Shipping</p>
<p>Orders leave within two days.</p>

Failing, per F43. A heading level used to get smaller type, in a place that is not a section:

<h4>3333 Third Avenue, Suite 300</h4>

Passing. Real heading markup, with CSS controlling the size:

<h2>Shipping</h2>
<p>Orders leave within two days.</p>

Skipped heading levels: advice, not a 1.3.1 failure on its own

Many tools, including ours, report skipped heading levels, and many articles call them a WCAG failure. The WCAG sources say otherwise:

• W3C's technique G141, Organizing a page using headings, lists 1.3.1 as advisory, not sufficient, and phrases the nesting as guidance: "authors should use headings that are properly nested". The page adds that techniques "are not required to meet WCAG".
• W3C's WAI tutorial on headings says "skipping heading ranks can be confusing and should be avoided where possible". It also says it is fine to go from a deep heading back up to a higher one, such as an h2 that begins a new section after an h4, "as it closes the previous section".
• The WCAG 2.2 success criteria never say to keep heading levels in sequence, and none says a page needs exactly one h1. The list of failures W3C documents for 1.3.1 does not include either.

The HTML language rules are stricter than WCAG on this point. The HTML Standard says each heading's level must be less than, equal to or one greater than the heading before it, and it labels an h1 followed by an h3 non-conforming for authors. That is an HTML authoring rule, not a WCAG success criterion, and our heading structure guide covers both.

So a page that goes from h2 to h4 does not fail 1.3.1 for that alone. Why report it? Because it is a good detector of the real failure. A skip is usually a heading picked for its size (F43), and it disrupts the outline people navigate by, which W3C's tutorial calls confusing. GotAlt's free scan lists skipped levels under 1.3.1 as a minor finding for that reason. Read it as a prompt to look at the outline, not as a confirmed failure of the criterion. Whether headings describe their sections is a separate criterion, 2.4.6 Headings and Labels (Level AA).

On the one-h1 convention, the same reasoning applies. WCAG does not require it. We recommend a single h1 that names the page, because W3C's tutorial shows exactly one rank 1 heading in both of its sample layouts and because a missing or doubled h1 is a common sign of a template problem. Our heading structure guide goes deeper.

Lists

Technique H48 asks for ol, ul and dl where content is a list. It notes the limit as well: "not all lists need markup", and a sentence that contains a comma-separated list may not need it. The failure to avoid is the one H48 itself describes, items made to look like a list with asterisks or br elements. H48 notes that some assistive technologies let users move from list to list or item to item, and that a list of links lets screen reader users jump past the whole group. A column of div elements with bullet characters offers neither.

Failing:

<p>* Free returns<br>
* Free shipping over $50<br>
* Two-year warranty</p>

Passing:

<ul>
  <li>Free returns</li>
  <li>Free shipping over $50</li>
  <li>Two-year warranty</li>
</ul>

The reverse also matters. A menu is a list of links, so ul inside nav is correct. Structural markup used for looks misstates the content. The examples in failure F43, structural markup that does not represent relationships, include a blockquote used to indent text that is not a quotation and a fieldset and legend used only to draw a border.

Tables

W3C's tutorial on tables puts the requirement in one line: header cells "must be marked up with <th>", and data cells with <td>. Screen readers use that to announce the row and column headers as a person moves from cell to cell. The rules in practice:

• Header cells are th. A table where the headers are td cells in bold is failure F91.
• scope where direction is unclear. H63 says that for simple tables with the headers in the first row or column, "it is sufficient to simply use the th elements without scope". When a table has both row and column headers, set scope="col" and scope="row". This site's own tables do.
• id and headers for complex tables, with headers that span groups or multiple levels (technique H43). Wrong values are failure F90. W3C also suggests that some users find several simple tables easier to work with than one complex table.
• A caption is good practice, not a requirement. W3C's caption tutorial says captions and summaries are "not required in every case to meet WCAG". It also says a caption "functions like a heading for a table" and, in a screen reader's tables mode, is the primary way to identify one.
• Layout tables stay free of data-table markup. Putting th, caption or a summary in a layout table is failure F46, because it states relationships that do not exist. W3C notes WCAG 2 does not prohibit layout tables but recommends CSS layout. Marking a real data table role="presentation" is the opposite error, F92.

Failing. Headers are ordinary cells (F91):

<table>
  <tr><td><b>Plan</b></td><td><b>Pages</b></td></tr>
  <tr><td>Basic</td><td>10</td></tr>
</table>

Passing. Header cells with a direction, and a caption:

<table>
  <caption>Sample plans</caption>
  <tr>
    <th scope="col">Plan</th>
    <th scope="col">Pages</th>
  </tr>
  <tr>
    <th scope="row">Basic</th>
    <td>10</td>
  </tr>
</table>

A grid of div elements styled to look like a table has the same problem as the first example, with no table semantics at all. Either use a real table or give the grid the table roles.

Form labels and groups

A label that sits beside a field is a visual relationship, and 1.3.1 asks for it in code. W3C's technique H44 is sufficient for 1.3.1, 3.3.2 and 4.1.2 alike, which is why one missing label is usually reported against several criteria. In W3C's forms tutorial, the options are:

• A label with for, where "the for attribute of the label must exactly match the id of the form control". This is the first choice, and the label becomes a larger click target.
• A label that wraps the control. Fine when the control has no usable id. The tutorial says explicit labels are generally better supported.
• aria-labelledby or aria-label when there is no visible label text. The tutorial says to use them "only when the label of the control is clear from the surrounding content", such as a search field beside a button that says Search.
• The title attribute (H65). The tutorial calls it "generally less reliable and not recommended", because some assistive technologies do not treat it as a replacement for a label.

A visible label can also be hidden visually. The tutorial says the label "still needs to be provided within the code" and shows how to clip it off screen, for a search box whose purpose is obvious from the button beside it. A hidden label satisfies 1.3.1 and 4.1.2, but W3C's technique H44 says that for 3.3.2 Labels or Instructions "the label element must be visible". A placeholder is not on the tutorial's list. GotAlt's tools do not count one as a label.

Failing. The word "Email" is next to the field but not connected to it. This is the situation W3C documents as F111, a visible label with no accessible name, and speech input users cannot say the label to reach the field:

<span>Email</span>
<input type="email" name="email">

Failing. A label exists, but its for does not match the field's id:

<label for="mail">Email</label>
<input type="email" id="email">

Passing:

<label for="email">Email</label>
<input type="email" id="email">

Groups of controls

Radio buttons and checkboxes that answer one question are related, and the question is the relationship. W3C's technique H71 uses fieldset and legend, and W3C's grouping tutorial says "radio button groups should always be grouped using <fieldset>". Groups also tell apart repeated labels, such as the same "Street" field in a shipping and a billing address. The tutorial's caution: some screen readers read the legend with every control, once, or rarely not at all, so keep the legend short and make each label clear without it. role="group" with aria-labelledby (technique ARIA17) is the alternative when a fieldset does not suit the layout.

Failing. A caption in a paragraph, not tied to the radio buttons:

<p>Output format</p>
<input type="radio" name="f" id="csv">
<label for="csv">CSV file</label>

Passing:

<fieldset>
  <legend>Output format</legend>
  <input type="radio" name="f" id="csv">
  <label for="csv">CSV file</label>
</fieldset>

Required fields and other cues carried by looks

W3C's own examples of 1.3.1 include required fields. Labels in red with an asterisk are fine when the instructions say so in text and the information also reaches software; red alone would fall under 1.4.1 as well. Writing "(required)" in the label text and adding the required attribute covers both people and software:

<label for="email">
  Email (required)</label>
<input type="email" id="email" required>

The same logic applies to a menu that marks the current page only with bold type. Add aria-current="page" to that link (technique ARIA26).

Landmarks

Header, navigation, main content and footer are visual regions, and landmarks are how they reach software. The ARIA Authoring Practices Guide lists the HTML elements that create them:

• Context matters. A header inside article, aside, main, nav or section is not a banner, and a section without an accessible name is not a landmark.
• Label repeats. If a role is used more than once, "provide each instance of that landmark with a unique label", for example <nav aria-label="Main"> and a second nav labeled "Breadcrumb". Leave the role word out of the label: "Site Navigation" would be announced as "Site Navigation Navigation".
• Put the content inside them. The guide describes putting all perceivable content in a landmark as one of the most effective ways to make sure assistive technology users do not overlook it.
• What the criterion requires. Landmarks are listed as sufficient techniques (H101, ARIA11, ARIA20), but none of the failures W3C names for 1.3.1 is about missing landmarks. They are the usual way to expose page regions and also support 2.4.1 Bypass Blocks; whether a particular page without them fails is a judgment about what its layout conveys.

How to test WCAG 1.3.1, step by step

1. List the visual structure. Scan the page and write down every heading, list, table, form field and group, and every region, plus anything marked only by a style: a bold lead-in, bullets, a colored or starred label, a highlighted menu item.
2. Read the accessibility tree. In Chrome's developer tools, the Accessibility tab has a "Show accessibility tree" toggle that replaces the DOM tree with the tree exposed to assistive technology, and Firefox's Accessibility Inspector shows the same. Check each item from step 1 appears with the right role.
3. Print the heading outline. This shows levels and text in order:

document.querySelectorAll(
  "h1,h2,h3,h4,h5,h6,[role=heading]")
  .forEach(h => console.log(
    h.getAttribute("aria-level") || h.tagName,
    h.textContent.trim().slice(0, 60)));

4. Find fields with no label element. Each result still needs a look for an aria-label or aria-labelledby. The labels property lists the label elements associated with a control:

const sel = "input:not([type=hidden])"
  + ":not([type=submit]):not([type=button])"
  + ":not([type=reset]):not([type=image])"
  + ", select, textarea";
for (const f of document.querySelectorAll(sel)) {
  if (!f.labels.length) {
    console.log(f.outerHTML.slice(0, 80));
  }
}

5. Try the quick keys. Screen reader users move through these structures by element type. The table below uses NVDA's keys, from WebAIM's NVDA guide. If a key finds nothing where you can see the structure, the code does not say it.
6. Walk a table cell by cell and listen for the row and column headers changing. In a form, tab through and listen for each label; with grouped controls, listen for the group name.
7. Check cues that rely on look. For each color, icon, bold style or position that carries meaning, find the text or markup that carries it too.
8. Run the automated checks listed in the next sections to catch the mechanical cases, then repeat after the page changes state, because menus, tabs and scripts add structure that a one-time check never saw.

Our guide to testing website accessibility fits this into a full manual pass.

Common false positives and false negatives

What GotAlt's tools check, and what they cannot see

Headings and form labels are two of the structures a program can read from the HTML, and our tools cover those two. Nothing in GotAlt checks list markup, table header markup, field groups or landmarks in a web page.

Related criteria and further reading

• 1.3.2 Meaningful Sequence (A): the reading order in the code makes sense.
• 1.4.1 Use of Color (A): color is not the only way to convey information.
• 2.4.6 Headings and Labels (AA): headings and labels describe topic or purpose.
• 2.4.10 Section Headings (AAA): section headings organize the content.
• 3.3.2 Labels or Instructions (A): labels or instructions are provided when content requires input.
• 4.1.2 Name, Role, Value (A): controls expose a name and role to software.
• 2.4.1 Bypass Blocks (A): repeated blocks can be skipped, which landmarks and headings support.

For every criterion in one place, see WCAG 2.2 criteria explained and the WCAG 2.2 checklist. For the Level A and AA picture on each platform, see our guides for Shopify, WordPress, Wix, Squarespace and Webflow.