WCAG 1.3.1 Info and Relationships — Testing Guide for Mobile & Web Apps

WCAG 1.3.1, "Info and Relationships," is a foundational accessibility criterion. It mandates that information, structure, and relationships conveyed through presentation can be programmatically determ

Ensuring Information and Relationships: A Practical Guide to WCAG 1.3.1 Compliance

WCAG 1.3.1, "Info and Relationships," is a foundational accessibility criterion. It mandates that information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. This means the underlying code must clearly define the purpose and connections between elements, not just how they look.

What WCAG 1.3.1 Requires

In plain terms, this means:

• Meaningful Structure: Content should be organized logically using appropriate semantic HTML elements (e.g., headings for structure, lists for related items, tables for data).
• Clear Relationships: The connections between different pieces of information must be explicit. For instance, a form label must be programmatically associated with its input field.
• Programmatic Access: Assistive technologies (like screen readers) must be able to interpret this structure and these relationships to present information to users in an understandable way.
• Text Equivalents: Any information conveyed by non-text elements (like images or charts) must have a text alternative that serves the same purpose.

Why WCAG 1.3.1 Matters

This criterion is critical for users who rely on assistive technologies.

• Screen Reader Users: Without proper structure and relationships, screen readers can only announce elements sequentially, losing context. Imagine reading a document where headings are just bolded text, or a form where labels are separate and not linked to their inputs – it becomes a jumbled mess. This hinders navigation, comprehension, and task completion for users with visual impairments.
• Keyboard-Only Users: Clear relationships are essential for keyboard navigation. Users need to understand where they are in a form or document and how elements relate to each other to tab effectively.
• Users with Cognitive Disabilities: A well-structured interface with clear relationships can reduce cognitive load, making content easier to understand and navigate for individuals with learning disabilities or attention deficits.
• Search Engines: Programmatically defined content is also better understood by search engine crawlers, improving SEO.

Compliance with WCAG 1.3.1 is not just about adhering to standards; it's about creating inclusive digital experiences. In regions like the EU, directives like the European Accessibility Act (EAA) mandate compliance for many digital services. Similarly, the Americans with Disabilities Act (ADA) in the US requires digital accessibility, and WCAG is the de facto standard for meeting these obligations.

Common Violations and Examples

#### 1. Unassociated Form Labels (Web & Mobile)

• Violation: A form input field (e.g., a text box for an email address) does not have a programmatically associated label.
• Impact: Screen readers cannot announce the purpose of the input field when it receives focus, leaving the user guessing what information to enter.
• Example (Web):

    <input type="email" id="email">
    <label for="email">Email Address</label> <!-- Incorrect: Label is present but not associated -->

*Correction:*

    <label for="email">Email Address</label>
    <input type="email" id="email">

• Example (Mobile - Android): An EditText field without a contentDescription or an associated TextView with for="@+id/editTextId".

#### 2. Incorrect Heading Structure (Web)

• Violation: Headings are used for visual styling (e.g., bolding text) rather than indicating content structure, or they are used out of order (e.g., an h3 before an h2).
• Impact: Screen reader users cannot use headings to quickly navigate sections of content. They may get lost or miss important information.
• Example (Web):

    <h2>Section Title</h2>
    <h3>Subsection Title</h3> <!-- Incorrect: H3 used without a preceding H2 -->
    <p>Content...</p>
    <h2>Another Section</h2>

*Correction:*

    <h1>Main Title</h1>
    <h2>Section Title</h2>
    <h3>Subsection Title</h3>
    <p>Content...</p>
    <h2>Another Section</h2>

#### 3. Improper Table Markup (Web)

• Violation: Data tables are not marked up correctly, meaning table headers () are not associated with their corresponding data cells ().
• Impact: Screen readers announce table data without context, making it impossible for users to understand which data point belongs to which header.
• Example (Web):

    <table>
      <tr>
        <td>Name</td>
        <td>Age</td>
      </tr>
      <tr>
        <td>Alice</td>
        <td>30</td>
      </tr>
    </table> <!-- Incorrect: No <th> elements to define headers -->

*Correction:*

    <table>
      <thead>
        <tr>
          <th>Name</th>
          <th>Age</th>
        </tr>
      </thead>
      <tbody>
        <tr>
          <td>Alice</td>
          <td>30</td>
        </tr>
      </tbody>
    </table>

#### 4. Lack of Relationship Indicators in Lists (Web & Mobile)

• Violation: Related items are presented visually as a list (e.g., bullet points) but are not semantically marked up as a list (
  ,
  ).
  1. Impact: Screen readers may not announce these items as a distinct group, making it harder for users to understand that they are related.
  2. Example (Web):

  
      <div>Product 1</div>
      <div>Product 2</div>
      <div>Product 3</div> <!-- Visually looks like a list, but semantically it's just divs -->
  

  *Correction:*

  
      <ul>
        <li>Product 1</li>
        <li>Product 2</li>
        <li>Product 3</li>
      </ul>
  

  • Example (Mobile - Android): Using a series of TextViews without wrapping them in a RecyclerView with appropriate adapters that convey list structure, or without contentDescription indicating their relationship.

  #### 5. Missing Alt Text for Informative Images (Web)

  • Violation: Images that convey important information do not have descriptive alt attributes.
  • Impact: Users who cannot see the image miss out on crucial information.
  • Example (Web):

  
      <img src="sales-chart.png"> <!-- Missing alt text -->
  

  *Correction:*

  
      <img src="sales-chart.png" alt="Bar chart showing a 20% increase in sales from Q1 to Q2.">
  

  How to Test for WCAG 1.3.1 Compliance

  #### Manual Testing Steps

  1. Keyboard Navigation: Tab through your application.
  • Do form fields have associated labels announced by screen readers or focus indicators?
  • Can you navigate through headings and lists logically?
  • Do interactive elements behave as expected when navigated by keyboard?
  1. Screen Reader Testing: Use a screen reader (NVDA on Windows, VoiceOver on macOS/iOS, TalkBack on Android).
  • Listen to how headings are announced. Is the hierarchy clear?
  • Interact with forms. Are labels read out correctly before you type?
  • Navigate tables. Can you understand the data and its headers?
  • Are list items announced as part of a list?
  1. Inspect Code: Use browser developer tools (Chrome DevTools, Firefox Developer Tools) to inspect the HTML structure.
  • Verify that elements are used for table headers and are correctly associated with elements.
  • Check that label elements are correctly associated with their form controls using the for attribute.
  • Ensure headings (

    through

    ) are used in a logical, hierarchical order.

  • Confirm that lists are marked up with
    or
    and list items with
    1. .
    2. Examine tags for meaningful alt attributes for informative images.

    #### Automated Tools

    • Browser Extensions: axe DevTools, WAVE (Web Accessibility Evaluation Tool). These tools can identify many issues related to semantic structure and missing alt text.
    • Linters: ESLint with accessibility plugins (e.g., eslint-plugin-jsx-a11y for React) can catch errors during development.
    • CI/CD Integrated Tools: Many CI/CD pipelines can integrate with accessibility testing tools to provide automated checks.

    #### Mobile-Specific Considerations

    • Android: Use the Accessibility Scanner app from Google or Android Studio's Layout Inspector to check for missing contentDescription attributes on interactive elements and images. Verify that TextView labels are correctly associated with EditText fields.
    • iOS: Use Xcode's Accessibility Inspector to check element properties, ensure proper labeling, and verify heading structures in your UI.

    How to Fix Violations

    • Form Labels: Always use the pattern in HTML. In native mobile development, ensure contentDescription is set for images and interactive elements, and use labelFor="@+id/controlId" in TextView when associating it with an input.
    • Headings: Use HTML heading tags (

      to

      ) strictly for content structure. Avoid using them for purely visual styling.

    • Tables: Use for table headers and associate them with cells. Use scope="col" or scope="row" for clarity. For complex tables, use and id/headers attributes.
    • Lists: Use
      ,
      , and
      1. for all lists, even if they appear simple.
      2. Images: Provide descriptive alt text for all informative images. If an image is purely decorative, use an empty alt="".

      How SUSA Checks WCAG 1.3.1

      SUSA autonomously explores your application, performing dynamic testing across various user personas.

      • Persona-Based Exploration: SUSA's personas, including the curious, novice, and power user, interact with your app in ways that naturally uncover structural issues. For example, a curious persona might explore different navigation paths, indirectly testing heading hierarchy.
      • Flow Tracking: For critical user flows like registration or checkout, SUSA analyzes the structure and relationships of elements within each step. It identifies if form inputs are properly labeled or if data tables in order summaries are semantically correct.
      • Accessibility Persona: SUSA includes an accessibility persona specifically designed to probe for WCAG violations. This persona interacts with the application in a manner similar to a screen reader user, detecting unassociated labels, incorrect heading orders, and improper list markup.
      • WCAG 2.1 AA Testing: S

      Test Your App Autonomously

      Upload your APK or URL. SUSA explores like 10 real users — finds bugs, accessibility violations, and security issues. No scripts.

      Try SUSA Free

      Related Articles

      WCAG 1.3.5 Identify Input Purpose — Testing Guide for Mobile & Web Apps

      Read more →

      WCAG 1.2.5 Audio Description — Testing Guide for Mobile & Web Apps

      Read more →

      WCAG 1.3.3 Sensory Characteristics — Testing Guide for Mobile & Web Apps

      Read more →

      WCAG 1.4.2 Audio Control — Testing Guide for Mobile & Web Apps

      Read more →