WCAG 1.3.1 Info and Relationships: How to Structure Accessible Web Content

Introduction

WCAG 1.3.1 “Info and Relationships” requires that information, structure and relationships conveyed through presentation are also available programmatically. In practice this means headings, lists, tables, labels and other structural cues must use semantic markup or an accessible API so assistive tech can expose them.

What WCAG 1.3.1 requires

At Level A, 1.3.1 expects that users who rely on assistive technology can discover:

• Document structure: headings and heading order
• Grouping: lists, fieldsets, table headers and cells
• Relationships: form control labels, captioning and labels for controls
• Sequence: logical reading order matched to visual order

Practical ways to meet the criterion

• Use native elements first: <h1>–<h6> for headings, <ul>/<ol> for lists, <table> with <th> for tabular data.
• Label every control: use <label for=“id”> for inputs, or visible text inside the control when appropriate.
• Ensure table headers are marked with <th scope=“col”> or <th scope=“row”> for complex tables.
• Maintain a clear DOM order that matches visual order to preserve sequence.
• Only use ARIA when native markup cannot represent the relationship; prefer semantic HTML over ARIA roles.

Short HTML examples

Correct heading and list structure (visible text omitted):

<h2>Section title</h2> <ul><li>Item 1</li><li>Item 2</li></ul>

Labelled form control example:

<label for=“email”>Email</label> <input id=“email” name=“email” type=“email” />

Simple table with headers:

<table><caption>Monthly sales</caption><thead><tr><th scope=“col”>Month</th><th scope=“col”>Sales</th></tr></thead><tbody><tr><td>Jan</td><td>£1,200</td></tr></tbody></table>

How to test WCAG 1.3.1

Combine automated tools with manual checks. Automated checkers can flag missing labels and obvious heading issues, but manual review confirms relationships are meaningful.

• Use the browser accessibility tree (DevTools Accessibility pane) to confirm headings, lists and labels appear as expected.
• Navigate the page with a screen reader or focus mode to verify label announcements and table header associations.
• Keyboard-only navigation: tab through forms to ensure focus and labels are usable.
• Visual review: ensure DOM order mirrors visual flow and captions, legends or visible labels are present where needed.

When to use ARIA — a quick decision guide

• Prefer native HTML elements. They provide built-in semantics to assistive tech.
• Use ARIA only when native elements cannot model the required relationship (for example, a custom widget where no native role exists).
• If you add ARIA, expose the same relationships programmatically and test with real assistive tech. Avoid duplicate or conflicting semantics.

Common failures and fixes

• Missing labels: add <label for=“…”> or aria-label/aria-labelledby when an explicit label is required.
• Visual headings that are not semantic: replace styled <div> or <span> headings with <h1>–<h6>.
• Tables used for layout: convert to CSS layout and use semantic containers; keep <table> for tabular data only.
• Out-of-order DOM: reorder HTML or use CSS to maintain visual order that matches the DOM reading order.

Conclusion

WCAG 1.3.1 is about making structure and relationships explicit to assistive technologies. Fixes are usually straightforward: use semantic HTML, label controls, mark table headers and keep logical DOM order. Test with assistive tools and a short checklist to catch issues early.

FAQs

Does 1.3.1 require visible labels?

No. The requirement is that labels and relationships are programmatically determinable. Visible labels are best for usability, but hidden labels can be acceptable if exposed correctly via the accessibility API.

Are heading levels strictly sequential?

Heading levels should reflect document structure. Skip-level jumps are not ideal, but the key is that headings form a clear, programmatically determinable outline. Use semantic headings rather than styling alone.

Can ARIA fix missing semantics?

ARIA can add semantics when no native element fits, but it should not mask an underlying accessibility problem. Always try to use native elements first and test the result.

How do I check complex tables?

Ensure <th> elements are present with proper scope or id/headers attributes for complex layouts. Confirm with a screen reader and the accessibility tree that headers are announced for cells.