WCAG 1.3.1: Info and Relationships

Introduction to WCAG 1.3.1: Info and Relationships

WCAG 1.3.1, titled "Info and Relationships," is an A-level success criterion that requires information, structure, and relationships conveyed through presentation to be programmatically determinable or available in text. This means that if something is visually presented as a heading, a list, a table, or any other structured element, its underlying semantic meaning and relationship to other content must also be accessible to assistive technologies.

The goal is to ensure that users who cannot perceive the visual layout of a page (e.g., blind users, users with low vision) or who use assistive technologies that rely on programmatic understanding (e.g., screen readers, voice control software) can still comprehend the content and navigate effectively. It prevents developers from relying solely on visual styling (like font size, bold text, or indentation) to convey structure, without providing the underlying semantic markup that assistive technologies can interpret.

Why WCAG 1.3.1 Matters: Impact and Affected Users

Accessibility Impact

Meeting WCAG 1.3.1 is fundamental for a truly accessible web experience. Without proper semantic structure, web content can become a flat, undifferentiated stream of text for users of assistive technologies. For example:

• Navigation: Headings allow screen reader users to quickly navigate through a page, jumping from section to section. Without proper heading markup, they must listen to the entire page content to find specific sections.
• Understanding Context: Lists (ordered and unordered) provide context for groups of related items. Tables convey relationships between data points. Form labels associate input fields with their descriptive text. Without these programmatic relationships, users can lose context and struggle to understand the purpose or meaning of content.
• Customization: Users with cognitive disabilities or low vision often benefit from custom stylesheets to change fonts, colors, or spacing. If structure is only conveyed visually, these customizations can break the intended meaning of the page.
• Alternative Input: Users of voice control or other alternative input methods rely on programmatically identifiable elements to interact with the page.

User Groups Affected

A wide range of users benefits from WCAG 1.3.1 compliance:

• Blind users: Rely on screen readers to announce headings, lists, table structures, and form field labels.
• Users with low vision: Use screen magnifiers that show only a portion of the screen, making it difficult to perceive overall visual structure. Semantic markup helps them understand context. They may also use custom stylesheets.
• Users with cognitive or learning disabilities: Benefit from clear, consistent, and programmatically identifiable structure, which aids comprehension and navigation.
• Users with motor impairments: Often navigate using keyboards or alternative input devices and rely on logical focus order and identifiable interactive elements that stem from proper semantic markup.
• Users of alternative input devices: Including speech input or switch control, depend on predictable, programmatically exposed elements to interact with web content.

Understanding the Success Criterion 1.3.1 Requirements

The core requirement is: "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text."

• "Information, structure, and relationships": This refers to anything that gives meaning or organization to the content beyond just raw text. Examples include:
  • Headings (e.g., visually larger, bold text indicating a section title)
  • Lists (e.g., indented lines with bullet points)
  • Tables (e.g., data arranged in rows and columns)
  • Form controls (e.g., input fields, checkboxes, radio buttons, and their associated labels)
  • Emphasis or importance (e.g., bold or italic text conveying significance)
  • Major page regions (e.g., navigation, main content, footer)
  • Interactive elements (e.g., buttons, links, custom widgets)
• "Conveyed through presentation": This means if you style something visually to look like a heading, a list, or an important piece of information, that visual cue needs to have a corresponding programmatic meaning.
• "Can be programmatically determined": This is the primary method of compliance. It means that assistive technologies can access and understand the semantic meaning of the content through the Document Object Model (DOM) and accessibility APIs. This is primarily achieved by using appropriate HTML elements (e.g., <h1> for a heading, <ul> for an unordered list, <label> for a form input).
• "Or are available in text": This is a fallback option when programmatic determination isn’t possible, though it’s generally less desirable. It means the information or relationship is explicitly written out in plain text (e.g., "The following items are required:" followed by items, if they can’t be marked up as a list). This is rarely the optimal solution for structured content.

Practical Guidelines for Compliance

1. Use Semantic HTML Elements Appropriately

The most effective way to meet 1.3.1 is by using HTML elements for their intended semantic purpose.

• Headings: Use <h1> through <h6> to structure your content hierarchically. Do not skip heading levels (e.g., <h1> directly to <h3>).
• Lists: Use <ul> for unordered lists, <ol> for ordered lists, and <dl> for description lists.
• Tables: Use <table> for tabular data. Ensure column headers (<th scope="col">) and row headers (<th scope="row">) are correctly identified. Use <caption> for a table title and <summary> (though deprecated in HTML5, often suggested for complex tables for screen reader users) or aria-describedby for longer descriptions if needed.
• Forms: Always associate <label> elements with their form controls using the for attribute on the label and the id attribute on the input. Group related form controls (like radio buttons or checkboxes) using <fieldset> and <legend>.
• Emphasis: Use <strong> for strong importance and <em> for emphasis (stress), rather than purely visual styling with <b>, <i>, or CSS.
• Page Regions (Landmarks): Use HTML5 structural elements like <header>, <nav>, <main>, <aside>, and <footer>. For older HTML or if more specific roles are needed, use ARIA landmark roles (e.g., role="navigation").

2. Ensure Programmatic Association When Native HTML Isn’t Sufficient

For custom components or where native HTML doesn’t fully express a relationship, ARIA (Accessible Rich Internet Applications) can bridge the gap.

• Custom Widgets: If you build a custom tab interface, accordion, or dialog, you’ll need to use ARIA roles (e.g., role="tablist", role="tab", role="tabpanel"), states (e.g., aria-selected, aria-expanded), and properties (e.g., aria-labelledby, aria-controls) to convey their structure and relationships.
• Complex Relationships: Use aria-labelledby to associate an element with a label that is not a direct child or uses multiple labels. Use aria-describedby for providing additional descriptive text.

3. Avoid Presentational Markup for Structure

Never rely solely on visual styling (CSS) or non-semantic tags (like <div> or <span>) to convey structure or relationships that should be programmatically discoverable.

Examples of Correct and Incorrect Implementations

Headings

<h1>Main Page Title</h1>
<p>Some introductory text.</p>
<h2>Section A</h2>
<p>Content for Section A.</p>
<h3>Subsection A.1</h3>
<p>Content for Subsection A.1.</p>

<p style="font-size: 2em; font-weight: bold;">Main Page Title</p>
<p>Some introductory text.</p>
<div style="font-size: 1.5em; font-weight: bold;">Section A</div>
<p>Content for Section A.</p>
<span style="font-size: 1.2em; font-weight: bold;">Subsection A.1</span>
<p>Content for Subsection A.1.</p>

Lists

<h2>Shopping List</h2>
<ul>
  <li>Milk</li>
  <li>Eggs</li>
  <li>Bread</li>
</ul>

<h2>Steps to Apply</h2>
<ol>
  <li>Fill out the application form.</li>
  <li>Attach required documents.</li>
  <li>Submit online.</li>
</ol>

<h2>Shopping List</h2>
<p>- Milk<br>
- Eggs<br>
- Bread</p>

<h2>Steps to Apply</h2>
<p>1. Fill out the application form.<br>
2. Attach required documents.<br>
3. Submit online.</p>

Form Labels

<label for="firstName">First Name:</label>
<input type="text" id="firstName">

<fieldset>
  <legend>Preferred Contact Method:</legend>
  <input type="radio" id="email" name="contact" value="email">
  <label for="email">Email</label><br>
  <input type="radio" id="phone" name="contact" value="phone">
  <label for="phone">Phone</label>
</fieldset>

<span>First Name:</span>
<input type="text">

<div>Preferred Contact Method:</div>
<input type="radio" name="contact" value="email"> Email<br>
<input type="radio" name="contact" value="phone"> Phone

Data Tables

<table>
  <caption>Quarterly Sales Figures by Region</caption>
  <thead>
    <tr>
      <th scope="col">Region</th>
      <th scope="col">Q1 Sales</th>
      <th scope="col">Q2 Sales</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">North</th>
      <td>$100,000</td>
      <td>$120,000</td>
    </tr>
    <tr>
      <th scope="row">South</th>
      <td>$90,000</td>
      <td>$110,000</td>
    </tr>
  </tbody>
</table>

<h2>Quarterly Sales Figures by Region</h2>
<div class="table-container">
  <div class="table-header-row">
    <span class="header-cell">Region</span>
    <span class="header-cell">Q1 Sales</span>
    <span class="header-cell">Q2 Sales</span>
  </div>
  <div class="table-row">
    <span class="row-label">North</span>
    <span class="data-cell">$100,000</span>
    <span class="data-cell">$120,000</span>
  </div>
  <div class="table-row">
    <span class="row-label">South</span>
    <span class="data-cell">$90,000</span>
    <span class="data-cell">$110,000</span>
  </div>
</div>
<style>
  .table-container { display: grid; grid-template-columns: repeat(3, 1fr); }
  .table-header-row, .table-row { display: contents; }
  .header-cell, .row-label, .data-cell { padding: 8px; border: 1px solid #ccc; }
  .header-cell { font-weight: bold; background-color: #f0f0f0; }
</style>

Best Practices and Common Pitfalls

Best Practices

• Prioritize Native HTML: Always use the most semantically appropriate HTML element for your content first. HTML provides a robust set of elements designed for specific purposes.
• Use ARIA Thoughtfully: Only use ARIA when native HTML cannot provide the necessary semantic information or for enhancing the accessibility of custom, complex UI components. Remember the first rule of ARIA: "If you can use a native HTML element or attribute with the semantics and behavior you require, do so."
• Maintain Heading Hierarchy: Ensure your headings follow a logical outline structure (<h1>, then <h2>, etc., without skipping levels).
• Validate Markup: Use HTML validation tools to catch syntax errors that might interfere with programmatic understanding.
• Test with Assistive Technologies: The best way to ensure compliance is to test your website using screen readers (e.g., NVDA, JAWS, VoiceOver) and keyboard-only navigation.
• Content is Key: Ensure the content itself is structured logically and consistently, making it easier to map to semantic markup.

Common Pitfalls

• Over-reliance on CSS for Structure: Using CSS to make non-semantic elements (like <div> or <span>) look like headings, lists, or tables without providing the underlying semantic HTML.
• Missing Form Labels: Not explicitly associating <label> elements with their form controls using for and id.
• Improper Table Markup: Using <table> for layout rather than data, or failing to use <th>, scope, and <caption> for data tables.
• Using <b> or <i> for Semantic Importance: These tags are purely presentational. Use <strong> for strong importance and <em> for emphasis.
• Inconsistent Use of ARIA: Applying ARIA roles, states, or properties incorrectly or redundantly where native HTML would suffice, potentially confusing assistive technologies.
• Hiding Content with display: none; or visibility: hidden; without alternative: If information or structure is essential, it must be programmatically available. If content is visually hidden but programmatically needed (e.g., for labels on icon-only buttons), use visually hidden CSS techniques that keep it in the accessibility tree (e.g., clipping, sr-only classes).

Related WCAG Guidelines

• WCAG 1.3.2 Meaningful Sequence: Ensures content that is presented in a meaningful sequence maintains that sequence programmatically.
• WCAG 2.4.1 Bypass Blocks: Requires a mechanism to bypass blocks of content that are repeated on multiple Web pages (e.g., navigation menus), often facilitated by semantic landmark roles.
• WCAG 4.1.2 Name, Role, Value: For all user interface components (including form elements, links, and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.
• WCAG 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input.