1.3.1 Info and Relationships

1. What is the goal of this criterion?

Imagine walking into an unfamiliar office building where every door sign, direction sign and floor number is invisible – but still there. That’s exactly how it feels for people using screen readers or other assistive technologies when a website’s structure is purely visual.

Sighted people instantly recognise on a website: that’s a heading (bigger, bold), that’s a list (with bullet points), that’s a form (fields with labels). But what if those visual cues aren’t available to you?

The goal of Success Criterion 1.3.1 is that all information and relationships conveyed through presentation are also available in the code. That way assistive technologies can recognise the structure and pass it on to their users – regardless of how the page looks.

2. What exactly does it require?

In concrete terms, WCAG 1.3.1 requires: all information, structure and relationships conveyed through presentation must either be programmatically determinable or available in text.

That means:

Headings must be marked up as real HTML headings (h1 to h6) – not just styled bigger and bolder.

Lists need proper list markup (ul, ol, dl) – not just hyphens or bullet characters.

Data tables must be built semantically, with header cells (th) clearly associated with their data cells (td).

Form fields need programmatically associated labels that explain what to enter.

Key regions of a page (navigation, main content, footer) can be identified with semantic HTML elements or landmark roles.

Relationships between elements – such as grouped form fields or hints that belong to a field – must be recognisable in the code.

If the technology you’re using doesn’t support programmatic markup, the information has to be provided as text – for example: “Required fields are marked with an asterisk (*).”

3. Why does it matter for accessibility?

Imagine listening to a radio piece about a complex table – but the presenter never explains which numbers belong to which categories. That’s exactly the confusion that arises when structural information is only available visually.

Semantic markup creates accessibility because it:

• lets screen reader users navigate by headings, lists and regions and skip content
• helps people with cognitive disabilities understand the structure of a page – for example when tools simplify the display
• supports users with motor impairments in navigating efficiently (for example via skip links and region navigation)
• allows people with low vision to use their own style sheets or reading modes without losing meaning
• enables braille displays to output structural elements correctly

And finally: clean semantic structure makes content more robust across different outputs – from speech output to the browser’s reader mode.

4. How to meet the criterion

The good news: semantic HTML isn’t rocket science – but it takes consistent, content-first thinking. The key ground rules:

For headings:

• Use h1 to h6 for real headings, not for large text.
• Reflect the outline logically: h1 → h2 → h3. Skipped levels aren’t an automatic failure, but they’re confusing – avoid them.
• One h1 per page is a well-established recommendation, but not an explicit WCAG requirement.

For lists:

• Use <ul> for unordered lists and <ol> for numbered lists.
• Use <dl> for description lists (term–description pairs).
• Don’t fake lists with hyphens and line breaks – handle the look with CSS.

For tables:

• Mark column and row headers with <th>.
• Use the scope attribute, and id plus headers for complex tables.
• Give the table a <caption> as its title.
• Only use tables for tabular data, not for layout.

For forms:

• Associate labels explicitly with <label for="field-id">.
• Group related fields with <fieldset> and <legend>, for example radio buttons.
• Connect hints and error messages to the field with aria-describedby.
• Mark required fields programmatically as well, with required or aria-required="true".

<fieldset>
  <legend>Shipping method</legend>
  <input type="radio" id="standard" name="shipping">
  <label for="standard">Standard</label>
  <input type="radio" id="express" name="shipping">
  <label for="express">Express</label>
</fieldset>

For page regions:

• Use HTML elements such as <header>, <nav>, <main>, <aside> and <footer>.
• You only need ARIA landmark roles like role="navigation" if you can’t use those elements.
• Offer skip links to important regions.

Testing:

• Check your page with a screen reader (for example NVDA, which is free).
• Use the accessibility tree in your browser’s developer tools.
• Switch off CSS as a test: is the structure still recognisable?

Closely related criteria are Meaningful Sequence, Headings and Labels and Name, Role, Value.

5. Why this criterion matters for businesses

Clean semantic structure isn’t just a requirement – it pays off commercially too. Three reasons:

1. Reach more people

A semantically correct website doesn’t exclude anyone. You reach people with disabilities – according to the WHO, around 1.3 billion people worldwide live with a significant disability – as well as older users and people with temporary impairments. And users can apply their own style sheets or reading modes without breaking your content.

2. A better foundation for search engines

Accessibility isn’t a direct ranking factor. But clean headings, real lists and structured tables help search engines understand your content – an indirect but noticeable side effect.

3. Lower development costs

Clean, semantic code is easier to maintain and more robust. Fewer div-and-script rebuilds mean fewer bugs, easier adaptation to different screen sizes and clearer responsibilities in the team.

And then there’s the law: since 28 June 2025, the European Accessibility Act has applied to many consumer products and services, such as online shops; Germany implements it through the Barrierefreiheitsstärkungsgesetz (BFSG). The benchmark is EN 301 549, which refers to WCAG 2.1 Level AA – 1.3.1, as a Level A criterion, is part of it. Public sector bodies have their own obligations. (General information, not legal advice.)

6. The success criterion in the W3C’s words

Success Criterion 1.3.1 Info and Relationships (Level A)

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

In short: any structure and relationships the design shows must also be recognisable in the code or available as text.