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, If something looks structured visually, it must also be structured in the 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
Ask:
- Does the structure make sense without visual cues?
- Can I navigate logically using only assistive tools?
If yes, you’ve fixed it.
Why WCAG 1.3.1 Matters Beyond Compliance
Proper structure:
- 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.
Small markup changes.
Massive clarity improvement.
WCAG 1.3.1 Quick Fix Checklist
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 Frequently Asked Questions
What is WCAG 1.3.1 Info and Relationships?
WCAG 1.3.1 requires that information conveyed visually through layout or styling is also programmatically defined using proper HTML structure.
Why can’t I just use bold text as a heading?
Screen readers rely on semantic heading tags, not visual styling. Bold text does not create structural meaning.
Do layout tables fail WCAG?
Tables used purely for layout can cause accessibility issues. Data tables must use proper header markup.
Does this affect SEO?
Yes. Proper heading structure and semantic markup improve both accessibility and search engine understanding.