Skip to main content
Accessibility.com, LLC
Category: ARIA and Semantic Structure

Info and Relationships

Also known as: WCAG Success Criterion 1.3.1, SC 1.3.1
Simply put

Info and Relationships is a Web Content Accessibility Guidelines (WCAG) requirement stating that any information, structure, or relationships shown visually on a page must also be available to assistive technologies or provided in text. For example, if a heading looks like a heading because it is large and bold, it must also be coded as a heading so a screen reader can recognize it. This helps people who cannot perceive visual formatting still understand how content is organized.

Formal definition

Info and Relationships is WCAG Success Criterion 1.3.1, a Level A criterion first published in WCAG 2.0 and carried forward through WCAG 2.1 and 2.2. It requires that information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. In practice this means visual or structural cues, such as headings, lists, tables, form labels, and grouped controls, must be expressed through semantic markup or accessible names and roles so they are exposed to assistive technologies, rather than relying on visual styling alone. Meeting this criterion is one component of conformance and does not by itself guarantee an accessible experience; manual and assistive technology testing are generally required in addition to automated checks. This entry describes the technical standard as published by the W3C and is not legal advice.

Why it matters

Visual formatting communicates a great deal of meaning to sighted users. Headings signal how a document is organized, tables group related data into rows and columns, lists show that items belong together, and a label sitting next to a field tells you what to type. When these relationships exist only in the visual presentation, people who rely on screen readers, braille displays, or other assistive technologies lose access to that structure. Info and Relationships (WCAG Success Criterion 1.3.1) addresses this gap by requiring that the same information, structure, and relationships be programmatically determinable or available in text, not just visible on screen.

Because 1.3.1 is a Level A criterion, it represents one of the most foundational requirements in WCAG, and failures to meet it are among the more common issues surfaced during accessibility audits. When structure is not encoded correctly, screen reader users may be unable to navigate by headings, may hear table data read as an undifferentiated stream, or may not know which label belongs to which form field. These barriers can make content difficult or impossible to use even when it looks well organized to a sighted visitor.

Meeting 1.3.1 supports conformance but does not by itself guarantee an accessible experience or immunity from legal claims, and automated tools detect only a portion of the ways this criterion can fail. For that reason it is often treated as a starting point that must be paired with manual and assistive technology testing rather than a box to check and move on from.

Who it's relevant to

Accessibility engineers and developers
Developers implement the semantic markup that satisfies 1.3.1, choosing correct heading levels, list and table structures, form label associations, and ARIA roles where native semantics are insufficient. Because this is a Level A criterion and a frequent source of audit findings, getting structure right in code is one of the highest-leverage steps toward broader conformance.
UX and content designers
Designers and content authors influence whether structure is meaningful and consistent. Deciding what should be a heading, how content should be grouped, and how forms and data are organized shapes the relationships that must then be encoded. Aligning visual design with an intended structure makes it easier to expose that structure to assistive technologies.
QA and accessibility testers
Testers verify that visual relationships are actually available programmatically or in text. Because automated tools catch only part of the potential failures, testers commonly combine automated scans with manual review and assistive technology testing to confirm that headings, lists, tables, labels, and groupings are exposed as intended.
Compliance officers and legal counsel
Those responsible for accessibility programs should understand that 1.3.1 is a widely cited Level A requirement often included in conformance targets, but that meeting it does not guarantee an accessible experience or legal safety. This entry describes the technical standard as published by the W3C and is not legal advice; questions about legal obligations should be directed to qualified counsel and current regulatory guidance.

Inside Info and Relationships

Success Criterion 1.3.1 (Level A)
Info and Relationships is WCAG Success Criterion 1.3.1, a Level A criterion introduced in WCAG 2.0 and carried forward in WCAG 2.1 and 2.2. It requires that information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Programmatically determined structure
Structure and relationships that are visually apparent (such as headings, lists, tables, and form label associations) should be encoded in the markup so that assistive technologies can convey the same relationships to users who do not perceive the visual presentation.
Semantic markup
Using native HTML elements such as heading elements, list elements, table header and data cells, and correctly associated form labels to expose meaning, rather than relying solely on visual styling like bold text or spacing to imply structure.
ARIA as a supplement
Where native semantics are insufficient, WAI-ARIA roles, states, and properties may be used to convey relationships programmatically. ARIA is generally intended to supplement, not replace, native HTML semantics.
Text alternatives for relationships
When relationships cannot be made programmatically determinable, the criterion allows the information to be provided in text so it remains available to all users.

Common questions

Answers to the questions practitioners most commonly ask about Info and Relationships.

Does using visual styling like bold text or spacing satisfy Info and Relationships?
No. Info and Relationships (WCAG 2.0 Success Criterion 1.3.1, Level A) requires that information, structure, and relationships conveyed through presentation be programmatically determinable or available in text. Visual cues such as bold text, color, spacing, or position may communicate meaning to sighted users, but if those relationships are not also conveyed through proper markup or text, they are generally not available to assistive technology users. For example, styling text to look like a heading without using a semantic heading element does not meet this criterion.
If my page passes automated accessibility checks, does that mean Info and Relationships is fully met?
Not necessarily. Automated testing detects only a portion of potential issues and can flag some structural problems, such as missing table headers or improperly nested headings. However, many aspects of Info and Relationships require human judgment to verify, such as whether a heading accurately reflects the content it introduces or whether a visually implied grouping is correctly conveyed in the markup. Manual review and testing with assistive technology are generally required to confirm conformance.
How do I convey a data table's structure to meet Info and Relationships?
Use semantic table markup so that relationships between cells are programmatically determinable. This commonly includes using table header cells (th) with appropriate scope attributes to associate headers with the correct rows or columns, and using elements such as caption where a table description is helpful. Layout tables used purely for visual arrangement are generally discouraged; where content is tabular data, the structural relationships should be expressed in the markup rather than only through visual alignment.
How should form fields and their labels be associated to satisfy this criterion?
Labels should be programmatically associated with their corresponding form controls so that assistive technology can convey the relationship. This is commonly done by associating a label element with a control (for example, via matching for and id attributes) so that the visible label is also the accessible name. Related fields can be grouped so the grouping is programmatically determinable. Relying on visual proximity or placeholder text alone generally does not meet Info and Relationships.
What is the correct way to mark up headings and lists for Info and Relationships?
Use native semantic elements that reflect the actual structure of the content. Headings should use heading elements at levels that represent the document's logical hierarchy rather than being chosen for visual size. Lists should use list markup so that the grouping and sequence of items are programmatically determinable. When native elements cannot be used, appropriate roles and properties may be applied to convey equivalent structure, though native semantics are generally preferred.
Where does responsibility for Info and Relationships fall between design, development, and content authoring?
Meeting Info and Relationships is generally a shared responsibility. Designers should indicate intended structure and relationships so they can be implemented in markup. Developers are responsible for expressing that structure with correct semantic elements, roles, and attributes. Content authors, particularly those using content management systems, should apply real headings, lists, and table headers rather than manual visual formatting. This entry is general guidance and not legal advice; consult qualified counsel and current standards for your specific obligations.

Common misconceptions

If content looks correctly structured on screen, it satisfies Info and Relationships.
Visual appearance alone does not meet 1.3.1. The structure and relationships conveyed visually must also be programmatically determinable or available in text, which requires appropriate underlying markup rather than styling that only mimics structure.
Automated testing tools can fully confirm conformance with 1.3.1.
Automated tools detect only a portion of potential issues. Verifying that programmatic structure matches the intended visual relationships generally requires manual review and testing with assistive technologies.
Adding ARIA attributes is the primary way to satisfy this criterion.
Native HTML semantics are commonly the preferred approach. ARIA is generally intended to supplement native semantics where they are insufficient, and misapplied ARIA can obscure rather than clarify relationships.

Best practices

Use native HTML elements such as heading, list, and table markup to convey structure, rather than relying on visual styling like font size, bold text, or spacing.
Associate form controls with their labels programmatically so that the label relationship is exposed to assistive technologies.
Use table header markup and appropriate associations for data tables so that data cells are linked to their corresponding headers.
Reserve WAI-ARIA for cases where native semantics are insufficient, and ensure any ARIA used is applied correctly to avoid conveying misleading relationships.
Test with assistive technologies and perform manual review in addition to automated checks, since automated tools capture only part of the potential issues.
Where a relationship cannot be made programmatically determinable, provide the information in text so it remains available to all users.