If your website uses headings, lists, tables, or forms, WCAG 1.3.1 applies to you. In this WCAG Fix It guide, we’re breaking down one of the most important structural accessibility requirements: ensuring that information, structure, and relationships are programmatically defined.
It sounds technical, but it’s really about ensuring things are structured both visually and in code because assistive technologies don’t “see” layout. They rely on proper markup, and when the website’s structure isn’t coded correctly, meaning is lost.
What Is WCAG 1.3.1?
WCAG 1.3.1 – Info and Relationships requires that information conveyed through visual presentation can also be programmatically determined or is available in text.
In simple terms: If you use visual styling to show relationships (like headings, grouped form fields, or table headers), that structure must be reflected in the HTML.
This applies to:
- Headings
- Lists
- Tables
- Form groups
- Instructions
- Layout-based relationships
If something looks like a heading, it must be coded as a heading. If something looks like a list, it must be coded as a list. If something looks grouped, it must be programmatically grouped.
Why Structure Matters
Screen readers don’t interpret bold text as a heading. They don’t understand indentation as hierarchy. They don’t detect visual spacing as grouping. They rely on semantic HTML.
Proper structure allows users to:
- Navigate by headings
- Jump between sections
- Understand list relationships
- Interpret table data correctly
- Understand grouped form options
Without structure, content becomes flat and confusing.
The Human Impact of Missing Structure
Imagine navigating a long page using a screen reader.
You press a key to jump between headings.
Nothing happens.
Because headings were styled with <div> and bold text instead of <h1>, <h2>, etc.
Or imagine encountering a table where header cells aren’t marked.
You hear:
“Row 1, Column 1, data.”
But you don’t know what that data refers to.
Or a group of radio buttons without a defined group label.
You don’t know what question you’re answering.
When structure isn’t defined, context disappears and without context, content loses meaning.
Common WCAG 1.3.1 Failures
Here’s what we typically see when scanning websites:
- Headings styled visually but not using <h1>–<h6>
- Lists created using line breaks instead of <ul> or <ol>
- Tables used for layout instead of data
- Data tables without <th> header cells
- Form fields grouped visually but not using <fieldset> and <legend>
- Instructions conveyed only through position or styling
All of these can fail WCAG 1.3.1.
How to Fix Info and Relationship Errors
Use Proper Heading Structure
Bad: <div class=”heading”>Our Services</div>
Correct: <h2>Our Services</h2>
Headings must follow logical hierarchy:
- One <h1> per page (typically)
- <h2> for main sections
- <h3> for subsections
Don’t skip levels for styling.
Use Proper List Markup
Bad:
• Service One
• Service Two
• Service Three
Correct:
<ul>
<li>Service One</li>
<li>Service Two</li>
<li>Service Three</li>
</ul>
This ensures assistive technologies announce list length and structure.
Use Proper Table Headers
For data tables:
<table>
<thead>
<tr>
<th>Product</th>
<th>Price</th>
</tr>
</thead>
<tbody>
<tr>
<td>Accessibility Audit</td>
<td>£500</td>
</tr>
</tbody>
</table>
Header cells (<th>) define relationships between data.
Without them, table content becomes meaningless.
Group Form Fields Correctly
For grouped radio buttons or checkboxes:
<fieldset>
<legend>Preferred Contact Method</legend>
<input type=”radio” id=”email” name=”contact”>
<label for=”email”>Email</label>
</fieldset>
This ensures users understand what the options relate to.
If You’re Using a CMS
Most CMS platforms allow you to:
- Select heading levels correctly
- Use built-in list tools
- Insert proper table structures
- Use structured form builders
Avoid:
- Styling text manually instead of using heading tools
- Creating layout tables
- Overusing generic containers
After publishing, always test.
How to Test WCAG 1.3.1
After fixing the structure of website page:
- Re-run your accessibility scan
- Use a screen reader to navigate by headings
- Check that lists are announced correctly
- Confirm table headers are read properly
- Verify grouped form fields have context
Why WCAG 1.3.1 Matters Beyond Compliance
Accessibility isn’t the only reason for WCAG 1.3.1 compliance. Here are some of the other benefits available:
- Improves navigation
- Improves SEO (search engines rely on structure)
- Improves readability
- Supports screen reader users
- Improves content hierarchy
- Reduces legal risk
Structure is not just design, it’s meaning.
If your content has hierarchy visually, it must have hierarchy technically.
WCAG 1.3.1 Quick Fix Checklist
If you’re looking to make real change toward WCAG 1.3.1 compliance, here’s a checklist you can follow:
- Headings use proper <h1>–<h6> tags
- Heading hierarchy is logical
- Lists use <ul> or <ol>
- Tables use <th> for headers
- Tables not used for layout
- Form groups use <fieldset> and <legend>
- Structure re-tested after updates
WCAG 1.3.1 Info and Relationships FAQs
Looking for a quick recap? Here are answers to some of the most frequently asked questions on this topic:
WCAG 1.3.1 requires that information conveyed visually through layout or styling is also programmatically defined using proper HTML structure.
Screen readers rely on semantic heading tags, not visual styling. Bold text does not create structural meaning.
Tables used purely for layout can cause accessibility issues. Data tables must use proper header markup.
Yes. Proper heading structure and semantic markup improve both accessibility and search engine understanding.