This post is part of a series where we explain Web Content Accessibility Guidelines (WCAG), an internationally recognized standard for measuring website accessibility. For more posts in this series, visit our Web Accessibility WCAG 2 Knowledge Base.
Continuing our WordPress accessibility series on WCAG conformance, we now turn our attention to one of the most fundamental principles of accessible web design: ensuring that the structure and relationships within your content are properly communicated to all users.
When people browse a website, they rely on visual cues to understand how information is organized. Headings create hierarchy, form labels identify input fields, lists group related items, and tables establish relationships between data. However, users of assistive technologies such as screen readers cannot always perceive these visual cues unless they are programmatically defined in the underlying code.
That’s where WCAG Success Criterion 1.3.1: Info and Relationships comes in.
This criterion requires that information, structure, and relationships conveyed visually can also be determined programmatically or are available in text. In other words, if content relies on visual formatting alone to communicate meaning, that meaning must also be exposed through proper semantic markup.
Whether you’re publishing blog posts, building forms, creating tables, or designing page layouts in WordPress, following this criterion helps ensure that all users can understand how content is organized and how different pieces of information relate to one another.
In this article, we’ll explain what WCAG 1.3.1 requires, why semantic structure matters, common implementation challenges, and practical ways to improve accessibility on your WordPress website.
What is WCAG 1.3.1 Info and Relationships?
WCAG Success Criterion 1.3.1 Info and Relationships (Level A) states:
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Web Content Accessibility Guidelines 1.3.1
In plain terms:
If visual formatting communicates meaning, that meaning must also be available through semantic markup or text.
This includes elements such as:
- Headings and heading hierarchy
- Lists and grouped content
- Form labels and instructions
- Table headers and data relationships
- Fieldsets and legends
- Content sections and landmarks
The goal is to ensure that assistive technologies can identify and communicate the same relationships that sighted users perceive visually.
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Why WCAG 1.3.1 Matters
Imagine a WordPress page that uses bold text and larger font sizes to create what appear to be section headings. Sighted users can easily scan the page and understand its organization.
However, if those headings are simply styled paragraphs instead of actual heading elements, screen reader users lose the ability to:
- Navigate quickly between sections
- Understand the page hierarchy
- Find information efficiently
Similarly, if form fields lack proper labels or tables are missing header associations, users of assistive technology may struggle to understand the purpose of the content.
WCAG 1.3.1 helps ensure that information and relationships are communicated consistently across different devices, browsers, and assistive technologies.
Proper implementation benefits users who:
- Use screen readers
- Navigate with voice control software
- Rely on screen magnification
- Use alternative input methods
- Access content on mobile devices or simplified interfaces
How to Meet This Success Criterion in WordPress
Meeting WCAG 1.3.1 largely involves using proper semantic HTML and ensuring that visual structure is supported by meaningful markup.
Use Proper Heading Structure
Headings should be created using heading elements (<h1> through <h6>) rather than styled text.
A well-structured page:
- Uses a single primary heading where appropriate.
- Follows a logical hierarchy.
- Avoids skipping heading levels unnecessarily.
WordPress block editors and page builders typically provide heading blocks that generate the correct markup.
Use Real Lists
When presenting related items, use:
- Ordered lists (
<ol>) - Unordered lists (
<ul>)
Avoid manually creating lists with dashes, bullets, or line breaks.
Label Form Fields Correctly
Every form field should have an associated label.
Users of assistive technology need labels to understand:
- What information is being requested
- Which field currently has focus
- Whether a field is required
Many WordPress form plugins provide built-in support for accessible labels when configured properly.
Create Accessible Tables
When displaying tabular data:
- Use table headers (<th>)
- Associate headers with data cells
- Avoid using tables purely for layout
This allows screen readers to communicate relationships between rows and columns.
Group Related Form Controls
Use fieldsets and legends when multiple controls belong to a single question or category.
For example: A survey question with multiple radio button options should use a fieldset and legend to identify the group.
Example of an Accessibility Issue
A WordPress page displays pricing information using visually styled text:
Basic Plan
Price: $10/month
Professional Plan
Price: $25/month
Visually, users understand that each plan name acts as a heading.
However, if the plan names are simply bold paragraphs rather than heading elements, screen reader users may not recognize the content structure.
A more accessible implementation would use proper heading markup to identify each plan section.
Common WCAG 1.3.1 Issues in WordPress
Some frequent accessibility problems include:
- Skipped heading levels.
- Text styled to look like headings without semantic markup.
- Missing form labels.
- Tables without header cells.
- Lists created with line breaks instead of list elements.
- Groups of controls lacking fieldsets and legends.
- Visual instructions not conveyed programmatically.
These issues often occur unintentionally when content creators focus primarily on visual appearance.
Testing WCAG 1.3.1 Compliance in WordPress
Use Accessibility Checker
Accessibility Checker has multiple automated checks that can alert you to 1.3.1 Info and Relationships failures. These checks include:
Problems
- Duplicate Form Label
- Empty Heading Tag
- Empty or Missing Form Label
- Empty or Missing Table Header
- Incorrect Heading Order
Needs Review
Manual Testing Items
1. Review Heading Structure
- Headings use proper HTML elements.
- The hierarchy is logical.
- Styled text is not being used in place of headings.
2. Inspect Lists
Verify that:
- Related items use list markup.
- Lists are announced correctly by screen readers.
3. Evaluate Forms
Confirm that:
- Every form field has a label.
- Related controls are grouped appropriately.
- Instructions are associated with relevant fields.
4. Check Tables
Ensure that:
- Header cells are defined correctly.
- Data relationships can be determined programmatically.
5. Test with Assistive Technology
Use Screen readers such as:
Verify that:
- Headings are navigable.
- Forms are understandable.
- Tables announce headers correctly.
- Content relationships are communicated effectively.
Take an online course to learn screen reader testing
If you want to learn more about how to use a screen reader for accessibility testing, check out our online courses. These courses include detailed instructions on how to use a screen reader, what keyboard shortcuts to know, recommended settings for testing, and good and bad examples of multiple different components so you know what to listen for.
Start Making Your WordPress Site More Inclusive
WCAG 1.3.1 Info and Relationships is a foundational accessibility requirement that helps ensure content structure is available to all users, not just those who can perceive visual formatting.
By using semantic HTML, proper heading structures, accessible forms, meaningful lists, and correctly marked-up tables, you create a more robust and understandable experience for users of assistive technologies.
Start by reviewing your WordPress site’s content and asking a simple question: if all visual styling were removed, would the structure and relationships still be clear? If the answer is yes, you’re well on your way to meeting WCAG 1.3.1 and creating a more inclusive web experience for everyone.
