WCAG 1.3.1 Guide: Semantics for Accessible UIs

As a frontend developer, you've likely spent countless hours meticulously crafting a user interface. You've aligned pixels, perfected color schemes, and ensured the layout is responsive and visually stunning. But what happens when a user can't see it? If the underlying code doesn't communicate the structure and relationships you've so carefully designed, your beautiful UI becomes a frustrating maze for users relying on assistive technologies like screen readers.

This is where WCAG 1.3.1: Info and Relationships comes in. It’s the foundational principle that ensures the information conveyed visually is also available programmatically. In other words, it bridges the gap between what users see and what assistive technologies understand.

This guide will demystify WCAG 1.3.1, explaining why programmatic accessibility is crucial for modern web development. We'll explore the role of accessibility semantics and provide practical "do's and don'ts" for implementing headings, lists, tables, and forms correctly. Finally, we’ll look at how automated tools can streamline compliance and help you build more inclusive applications.

What is WCAG 1.3.1: Info and Relationships?

In simple terms, WCAG 1.3.1 states: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

The intent behind this rule is to ensure that users of assistive technologies receive the same contextual information that sighted users get from visual cues. Think about it—sighted users perceive structure through bold text, different font sizes, layout, and spacing. WCAG 1.3.1 makes sure this underlying meaning isn’t lost when someone uses a screen reader or a different browser stylesheet.

This success criterion has a Level A conformance level, which makes it one of the most fundamental and non-negotiable requirements for web accessibility. Because all versions of the Web Content Accessibility Guidelines are designed to be backward compatible, this criterion is a core part of WCAG 2.0, 2.1, and 2.2. If you want to build accessible products, you have to get this right.

The Role of Accessibility Semantics

At the heart of WCAG 1.3.1 is the concept of accessibility semantics. This refers to using code—primarily semantic HTML—to give meaning, structure, and context to your content. It’s the difference between building a UI with generic <div> and <span> tags versus using meaningful elements like <h1>, <ul>, <table>, and <nav>.

Imagine a document. A non-semantic approach is like a flat wall of text with no chapters, headings, or table of contents. You can read it, but navigating to a specific section is difficult. A semantic approach, on the other hand, is like a well-organized book. It has a clear structure that allows you to jump between chapters, scan headings, and understand the hierarchy of information.

Screen readers rely on this structure to help users navigate efficiently. When you use proper semantic HTML:

• Users can skip between sections using heading navigation.
• They understand that a group of items is a list and hear how many items it contains.
• They can correctly interpret complex data in tables because the headers are associated with the data cells.

Without semantics, your UI is just a sequence of un-related elements, forcing users to listen to everything linearly to find what they need.

Headings: Do's and Don'ts

Headings are the backbone of your content, creating a logical outline that benefits all users.

The Do's of Headings

• Use a logical heading order: Always start with an <h1> for the main page title and follow a nested, hierarchical structure (<h2> follows <h1>, <h3> follows <h2>, etc.). Don't skip levels, as this can confuse screen reader users who use heading lists to understand the page structure.

1<!-- GOOD: A logical and nested heading structure -->
2<h1>Page Title</h1>
3<p>Introduction to the page...</p>
4<h2>Section 1</h2>
5<p>Content for section 1...</p>
6  <h3>Subsection 1.1</h3>
7  <p>Content for subsection 1.1...</p>
8<h2>Section 2</h2>
9<p>Content for section 2...</p>

The Don'ts of Headings

• Don't use CSS to style text as a heading: Making text bold and large doesn't make it a heading. Assistive technologies will just read it as regular paragraph text, and the structural importance will be completely lost.

<!-- BAD: This looks like a heading but has no semantic meaning -->
<p style="font-size: 24px; font-weight: bold;">This is not a real heading</p>

Lists: Do's and Don'ts

Lists are perfect for grouping related items, like navigation links, steps in a process, or product features.

The Do's of Lists

• Use proper HTML list markup: Use <ul> for unordered lists (where order doesn't matter), <ol> for ordered lists (where sequence is important), and <li> for each list item. Screen readers will announce the list, state how many items it contains, and read each item's position.

1<!-- GOOD: Proper markup for an unordered list -->
2<ul>
3  <li>First item</li>
4  <li>Second item</li>
5  <li>Third item</li>
6</ul>

The Don'ts of Lists

• Don't fake lists with paragraphs and special characters: Creating "lists" with <p> tags and characters like asterisks or hyphens provides no structural context. A screen reader will just read it as a series of separate paragraphs, not as a cohesive group of related items.

1<!-- BAD: This looks like a list but is not programmatically a list -->
2<p>* First item</p>
3<p>* Second item</p>
4<p>* Third item</p>

Tables: Do's and Don'ts

Tables are meant for presenting tabular data, not for visual layout. When used correctly, they allow screen reader users to understand the relationship between data cells and their headers.

The Do's of Tables

• Use <th> for headers and associate them with data cells: Use <th> tags for header cells and <td> for data cells. Use the scope attribute (scope="col" for column headers, scope="row" for row headers) to programmatically link headers to their corresponding data.

 1<!-- GOOD: A properly structured data table -->
 2<table>
 3  <caption>Monthly Sales Figures</caption>
 4  <thead>
 5    <tr>
 6      <th scope="col">Month</th>
 7      <th scope="col">Sales</th>
 8      <th scope="col">Expenses</th>
 9    </tr>
10  </thead>
11  <tbody>
12    <tr>
13      <th scope="row">January</th>
14      <td>$10,000</td>
15      <td>$3,000</td>
16    </tr>
17    <tr>
18      <th scope="row">February</th>
19      <td>$12,000</td>
20      <td>$3,500</td>
21    </tr>
22  </tbody>
23</table>

The Don'ts of Tables

• Don't use tables for layout: Using <table> elements to control the visual positioning of content was a common practice two decades ago, but it's a major accessibility failure today. It creates a confusing navigation experience for screen reader users.
• Don't leave header cells blank or omit a <caption>: The <caption> element provides a title for the table, giving users context about its purpose before they dive into the data. Omitting it makes the table harder to understand without visual cues.

Forms: Do's and Don'ts

Forms are the gateway to interaction on the web. Ensuring they are programmatically accessible is essential for everything from logging in to checking out.

The Do's of Forms

• Explicitly label all form controls: Use the <label> element with the for attribute to associate a text label with its corresponding input. Clicking the label will then focus the input, a benefit for all users.

1<!-- GOOD: A properly labeled form input -->
2<label for="username">Username:</label>
3<input type="text" id="username" name="username">

• Group related controls with <fieldset> and <legend>: When you have a group of related controls, like radio buttons or checkboxes, wrap them in a <fieldset> and use a <legend> to provide a label for the entire group.

 1<!-- GOOD: Grouping related radio buttons -->
 2<fieldset>
 3  <legend>Choose your plan:</legend>
 4  <div>
 5    <input type="radio" id="free" name="plan" value="free">
 6    <label for="free">Free</label>
 7  </div>
 8  <div>
 9    <input type="radio" id="premium" name="plan" value="premium">
10    <label for="premium">Premium</label>
11  </div>
12</fieldset>

The Don'ts of Forms

• Don't rely on visual proximity for labels: Placing text next to a form field isn't enough. Without an explicit <label for="..."> association, a screen reader won't know which label belongs to which input.
• Don't indicate required fields with color alone: A red border or red text isn't sufficient to indicate a required field. This information is unavailable to screen reader users and people with color blindness. Instead, include a text-based indicator like an asterisk (*) and provide an explanation that it denotes a required field. You can also use the aria-required="true" attribute.

How Automated Tools Can Help

Manually checking every element for programmatic accessibility can be incredibly time-consuming, especially in large, complex applications. It's easy for issues to slip through the cracks during development sprints. This is where automated testing tools can transform your workflow.

Rock Smith uses AI agents to test web applications for accessibility issues, including many related to WCAG 1.3.1. While traditional automated tools can only detect a fraction of accessibility issues, Rock Smith’s AI-powered approach is far more comprehensive. AI detects 70-80% of Web Content Accessibility Guidelines (WCAG) issues compared to 20-30% for traditional tools.

The AI vision capabilities allow Rock Smith to analyze your UI contextually, identifying missing semantic relationships that simpler scanners might miss. It can understand that a styled <div> is intended to be a button or that a group of text nodes is meant to be a list. It then provides comprehensive, actionable reports that your team can use to fix issues quickly and efficiently.

Build More Meaningful User Interfaces

Conforming to WCAG 1.3.1 is about much more than just checking a compliance box. It’s about demonstrating professionalism and building robust, inclusive user interfaces that work for everyone. Mastering accessibility semantics is a core skill for any modern frontend developer, ensuring your applications are usable, navigable, and meaningful to all users, regardless of ability.

Don't guess if your UI is accessible. Put your web app to the test and see how AI-powered testing can transform your workflow. Try out Rock Smith today to get comprehensive and actionable accessibility reports in minutes.