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

WCAG 1.3.1 Success Criteria requires that information, structure and relationships conveyed through presentation are also provided in the page’s underlying markup or text. Put simply, headings, lists, table headers, labels and groupings must be coded so assistive technologies can expose them.

What WCAG 1.3.1 requires

WCAG 1.3.1 is a Level A success criterion in WCAG 2.0 and later. It covers cases where meaning depends on visual formatting only. If users rely on assistive technology, the same information and relationships must be available in the content’s semantics or text.

Typical elements it covers

• Headings and section structure
• Lists and list items
• Table headers and relationships between cells and headers
• Form labels, groups and instructions
• Images or captions used to show relationships

Why it matters for users

Many assistive technologies rely on the document structure and accessibility tree to present content. If relationships are only conveyed with styling, users who cannot see the layout will miss meaning. That causes confusion, errors on forms and lost context in long pages.

Common ways sites fail 1.3.1

• Using bold or larger text to look like headings without <h1>–<h6> markup.
• Using visual lists with CSS but no <ul> or <ol> markup.
• Putting column headings in the first row visually but not marking them with <th> or scope.
• Form controls placed near labels visually, but the label is not associated with the control via for and id.
• Grouping controls visually inside a box but not using <fieldset> with <legend>.

How to fix failures — practical techniques

Always prefer native HTML elements first. They create relationships automatically in the accessibility tree.

Headings and document structure

• Use <h1> to <h6> for headings. Keep a logical order and do not skip levels.
• If you cannot use real headings, use WAI-ARIA sparingly: role=“heading” plus aria-level to indicate level.

Lists

• Use <ul> or <ol> with <li>. Screen readers expose list counts and positions.
• For custom controls that look like lists, ensure the accessibility tree exposes list semantics or add ARIA roles that match.

Tables

Mark header cells with <th>. Use the scope attribute for simple header relationships. For complex tables, use id and headers attributes or programmatic associations so each data cell maps to its header.

Product	Price
Notebook	£7.50

Forms and labels

• Use <label for=“id”> to bind labels to inputs. That association is exposed to assistive tech.
• Group related controls using <fieldset> and <legend> when a set of controls share a caption or purpose.
• For complex label needs, use aria-labelledby or aria-describedby to reference existing text nodes.

Images, captions and visual relationships

If an image conveys a relationship, provide accompanying text or a visible caption. Use the image alt attribute for alternative text and add a nearby caption element in markup so screen reader users receive the same context.

When to use ARIA (and when not to)

Prefer native HTML semantics. Use WAI-ARIA only when native elements cannot express the relationship. Incorrect ARIA can break semantics. Test ARIA with assistive technologies and accessibility inspectors before release.

Manual testing checklist for 1.3.1

1. Turn off CSS or reduce styles. Content should still show headings, lists and groups in a logical order.
2. Load the page with a screen reader and browse headings and lists to confirm they match the visual layout.
3. Tab through form controls. Labels and groupings must be announced in a meaningful order.
4. Inspect tables to ensure each data cell has an accessible header mapping.
5. Use a browser accessibility inspector to view the accessibility tree and confirm roles and names.

Real-world example: card grid with missing headings

Problem: a product grid uses <div> and styled <span> to show product names. Visually it looks fine. Screen reader users get no heading and cannot navigate by section.

Quick fix steps

1. Replace the visual title element with a semantic heading tag appropriate to the page structure. For example use <h3> inside each card if cards are subsections.
2. Ensure the heading order is consistent and does not skip levels across the page.
3. Retest with a screen reader and keyboard navigation.

Before: <div class=“card-title”><span>Scented Candle</span></div>

After: <h3>Scented Candle</h3>

Fast compliance checklist to ship

• Convert styled headings, lists and labels to semantic HTML.
• Add <th> and scope or appropriate header mapping for tables.
• Use <label>, <fieldset> and <legend> for forms.
• Only add WAI-ARIA where native HTML cannot express the relationship. Test ARIA with assistive tech.
• Run manual tests: CSS off, keyboard only, and a screen reader pass.

Further reading

Consult the WCAG documentation for exact wording and examples. Also check WAI-ARIA Authoring Practices when native markup cannot be used.