WCAG 1.3.1: Info and Relationships

What This Rule Means

WCAG 1.3.1 — Info and Relationships is a Level A criterion under the Perceivable principle. Its core requirement is straightforward but far-reaching: any information or relationship that is communicated visually must also be expressed in a way that assistive technologies can detect and convey to users. If your design uses visual cues — indentation to imply a list, bold text to mark a required field, color to indicate an error, or size to denote a heading — those same semantics must exist in the underlying code.

The criterion applies to three categories of meaning that web content regularly conveys through presentation:

• Information — facts or data communicated on the page, such as which form fields are required or which table cells share a relationship.
• Structure — the organizational schema of the content, such as heading hierarchies, ordered or unordered lists, and data tables.
• Relationships — associations between elements, such as a label and its input, a table header and its data cells, or a term and its definition.

A page passes 1.3.1 when every piece of structural or relational information available to a sighted user is either encoded in valid, semantic HTML or exposed through a correct ARIA role, property, or state that assistive technologies can interpret. A page fails when visual structure exists only in CSS or images, or when ARIA markup contradicts or is absent from the DOM structure being presented.

Official exceptions are minimal. The criterion does not require that all visual decoration carry semantic meaning — purely aesthetic formatting such as a decorative border or background color does not need a programmatic equivalent. However, any formatting that a user would reasonably interpret as conveying meaning (required asterisks, bold terms in a glossary, numbered steps) must have a corresponding programmatic expression.

Why It Matters

Information and relationships underpin almost every interaction a user has with a web page. When that structure is locked inside visual presentation alone, a significant portion of the population is effectively excluded from understanding the content at all.

Screen reader users — typically blind or low-vision individuals — navigate pages by querying the accessibility tree, which is built from semantic HTML and ARIA. When a developer uses a <div> styled to look like a heading instead of an actual <h2>, a screen reader user jumping between headings with the H key will skip it entirely. They may never find the section it introduces. According to the World Health Organization, approximately 2.2 billion people worldwide live with some form of vision impairment, and tens of millions rely on screen readers daily.

Users with cognitive disabilities benefit just as much from clear structure. Properly nested headings, meaningful list markup, and labelled form controls reduce cognitive load by providing predictable patterns. A screen reader announcing "heading level 2, Products" followed by "heading level 3, Laptops" gives a cognitive map of the page. A flat wall of styled text with no structural anchors is disorienting for everyone, but especially for users with attention or memory challenges.

Motor-impaired users who rely on keyboard navigation, switch access, or voice control software depend on programmatic structure too. Voice control software like Dragon NaturallySpeaking generates clickable targets from accessible names derived from labels and roles — form inputs without associated labels simply cannot be reliably targeted by voice command.

Consider a concrete scenario: a hospital patient portal displays a table of upcoming appointments. The table uses visual alignment and background color to associate dates with doctors, but the <th> elements lack scope attributes and the data cells do not reference headers. A blind user with a screen reader hears isolated cell values — "9:00 AM", "Dr. Ayşe Kaya", "Cardiology" — with no way to know which value belongs to which column. They may misread their appointment time or show up at the wrong department. Correct use of scope='col' on headers and headers attributes on cells would have made the relationships audible.

Beyond accessibility, structural HTML carries significant SEO value. Search engine crawlers use heading hierarchies to understand page topics, list markup to identify enumerated content, and label associations to understand form purpose. A page that passes 1.3.1 is almost always a page that search engines can parse and rank more accurately.

Related Axe-core Rules

The following axe-core rules map directly to violations of WCAG 1.3.1. Each rule targets a specific aspect of programmatic structure or relationship:

• aria-required-children — Checks that elements with certain ARIA roles contain the required child roles. For example, a role='list' must contain children with role='listitem'. Without the correct child structure, the relationship between a container and its items is broken for assistive technologies.
• aria-required-parent — The inverse of the above: checks that elements with roles that require a specific parent context actually have that parent. A role='listitem' that is not inside a role='list' or <ul>/<ol> is flagged because the relationship context is missing.
• aria-roles — Validates that all role attribute values are valid ARIA roles. An invalid or misspelled role (e.g., role='heading' instead of using a heading element, or a completely fabricated role) means the assistive technology receives no useful information and may ignore the element entirely.
• definition-list — Verifies that <dl> elements contain only permitted children: <dt>, <dd>, <div>, <script>, and <template>. Inserting other elements like <p> directly inside a <dl> invalidates the term-definition relationship structure.
• dlitem — Checks that <dt> and <dd> elements are only used inside <dl> elements. Using these elements outside their required parent context destroys the semantic meaning of the term-definition pair.
• heading-order — Flags heading levels that are skipped in the document outline (e.g., jumping from <h2> to <h4>). While not always a strict failure, skipping levels misleads assistive technologies about the hierarchical structure of the page and confuses users who navigate by heading.
• label — Verifies that every form input has a programmatically associated label, either via <label for='...'>, aria-label, aria-labelledby, or a wrapping <label> element. An input without an accessible label denies blind and voice-control users the information they need to understand what to enter.
• list — Ensures that <ul> and <ol> elements contain only <li> elements as direct children (plus <script> and <template>). Invalid child elements break the list structure that screen readers use to announce item counts and positions.
• listitem — Checks that <li> elements are only used inside <ul>, <ol>, or role='list' containers. Orphaned list items lose their semantic meaning entirely.
• scope-attr-valid — Validates that the scope attribute on <th> elements contains only the permitted values: col, row, colgroup, or rowgroup. An invalid or absent scope value on a complex data table means screen readers cannot reliably announce which header applies to a given data cell.
• td-headers-attr — Checks that when data cells use the headers attribute, every ID referenced actually exists in the same table and belongs to a header cell. Broken or missing references sever the programmatic relationship between data and its descriptive header, leaving screen reader users without context.

Note that automated tools like axe-core cannot catch every violation of 1.3.1. For example, a developer might use a visually styled <div> with role='list' and correctly structured child role='listitem' elements — axe will pass this — but a human tester might discover the visual indentation implies a nested sub-list that is not represented in the ARIA structure. Whenever visual hierarchy is complex, manual inspection and screen reader testing are essential complements to automated scanning.

How to Test

1. Automated scan with axe DevTools or Lighthouse: Install the axe DevTools browser extension (Chrome or Firefox). Open the page under test, open DevTools, navigate to the axe tab, and run a full-page scan. Filter results by the tag wcag131 or review all issues tagged under "Info and Relationships." Look specifically for violations of the eleven axe rules listed above. In Lighthouse (Chrome DevTools Audits panel), run an accessibility audit and check the "Accessibility" category for heading order, label, and list-related failures. Note all flagged elements and their DOM selectors for remediation.
2. Manual heading structure review: Use the HeadingsMap browser extension or the "Headings" panel in axe DevTools to view the complete heading outline of the page. Verify that the outline is logical and hierarchical — it should read like a well-structured table of contents. Confirm that no heading levels are skipped and that heading text is meaningful and not just visual styling applied to non-heading elements.
3. Form label verification: Tab through every interactive form element on the page. For each input, select, and textarea, confirm that a visible label is present and that it is programmatically associated (check the element in DevTools and look for a matching for/id pair, or an aria-label/aria-labelledby). Use the accessibility tree in Chrome DevTools (Elements panel → Accessibility tab) to confirm the computed accessible name for each control.
4. Screen reader testing with NVDA + Firefox: Launch NVDA and open the page in Firefox. Press H to cycle through headings and verify the announced heading levels match the visual hierarchy. Press F to move between form fields and confirm each field's label is announced. Press T to navigate tables and arrow through cells, listening for header announcements. Press L to cycle through lists and confirm item counts are announced.
5. Screen reader testing with VoiceOver + Safari (macOS/iOS): Enable VoiceOver (Cmd+F5 on macOS). Open the Rotor (Ctrl+Option+U) and inspect Headings, Links, Form Controls, and Tables. Confirm that all structural elements appear in the Rotor and that their announced names are meaningful and accurate.
6. Screen reader testing with JAWS + Chrome: Open JAWS and the page in Chrome. Use the JAWS List of Headings (Insert+F6) to review the heading tree. Use Insert+F5 for form fields to verify label associations. Navigate tables with arrow keys and confirm that JAWS announces column and row headers for each data cell.
7. Table header relationship check: Identify all data tables on the page. For simple tables, verify that <th> elements have appropriate scope attributes. For complex tables with multi-level headers, verify that data cells use the headers attribute referencing the correct id values. Visually trace each cell to its logical row and column headers, then confirm the same path is represented in the code.

How to Fix

Visual headings implemented as styled divs — Incorrect

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

Visual headings implemented as styled divs — Correct

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

Form input without an associated label — Incorrect

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

Form input without an associated label — Correct

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

Data table without scope attributes — Incorrect

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

Data table without scope attributes — Correct

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

List items used outside a list container — Incorrect

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

List items used outside a list container — Correct

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

Common Mistakes

• Using font-size and font-weight CSS alone to create the visual appearance of headings on <div> or <span> elements, while never adding role='heading' and aria-level or converting to actual <h1>–<h6> elements — screen readers cannot discover these as navigable headings.
• Using placeholder text as the only label for form inputs, which causes the label to disappear as soon as the user begins typing, leaving the field unlabelled for the duration of input — always pair inputs with a persistent <label> element.
• Marking required fields with a red asterisk (*) that is only explained in a visual legend at the top of the form, without adding aria-required='true' or including "required" in the programmatic label so screen reader users receive the same information.
• Applying list-style: none via CSS to a <ul> without understanding that some screen readers (particularly Safari + VoiceOver) may then stop announcing the element as a list — if the list semantics are meaningful, add role='list' explicitly to preserve them.
• Skipping heading levels — for example, placing an <h4> directly after an <h2> because the designer wanted smaller text — rather than using the correct heading level and controlling visual appearance through CSS.
• Building complex data tables with merged cells (colspan/rowspan) without adding the headers attribute on data cells, leaving screen reader users unable to determine which header governs an ambiguous merged cell.
• Using <table> elements for layout purposes and then adding role='presentation' inconsistently — some cells still contain headers that are announced out of context, confusing users who cannot see that the table is purely decorative.
• Wrapping a <dt>/<dd> pair inside a <p> or <div> that is a direct child of a <dl> without understanding that only <div> wrappers are permitted inside <dl> in HTML5, and that mixing other block elements destroys the definition list structure.
• Adding aria-labelledby on an input that references an ID which does not exist in the DOM, or referencing the ID of a non-text element — the computed accessible name becomes empty and the input is effectively unlabelled for assistive technologies.
• Assuming that because a page looks correct visually and passes a Lighthouse score above 90, it complies with 1.3.1 — automated tools cannot detect every structural violation, such as visual nesting relationships that are not reflected in the ARIA role hierarchy, requiring mandatory manual and screen reader verification.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web accessibility obligations aligned with WCAG 2.2 for a broad range of entities operating in Turkey. WCAG 1.3.1 is a Level A criterion, which means it sits at the foundational tier of conformance — the minimum acceptable level of accessibility — and is therefore fully mandatory for all covered entities under the circular.

The circular defines two compliance timelines. Public institutions — including central government bodies, municipalities, state universities, and public hospitals — must achieve full Level A conformance within one year of the circular's entry into force. Private sector entities covered by the regulation have a two-year window to comply. However, the obligation is not optional for either group: non-compliance exposes covered entities to regulatory scrutiny and potential enforcement action.

The private sector entities explicitly covered by the circular include e-commerce platforms, banks and financial institutions, private hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, licensed travel agencies, private transportation companies, and private schools operating under authorization from the Ministry of National Education (MoNE). Any of these entities operating a public-facing website or mobile web application must ensure that 1.3.1 is satisfied across their digital properties.

For practical compliance purposes, 1.3.1 is one of the most impactful Level A criteria because it governs fundamental page structure. A Turkish e-commerce site whose product category pages use styled <div> elements for headings, whose checkout form inputs lack label associations, or whose order summary is an unstructured table without scope attributes would fail 1.3.1 comprehensively. Remediation is not merely a legal obligation — it directly improves the experience for the estimated 700,000 or more blind and low-vision individuals in Turkey who rely on assistive technologies to shop, bank, access healthcare, and engage with government services online.

Organizations seeking to demonstrate compliance are advised to conduct both automated axe-core scans and manual screen reader audits covering the full breadth of their digital content. Structural accessibility — the foundation that 1.3.1 enforces — should be built into design systems and component libraries so that compliance is maintained as content is created and updated, rather than treated as a one-time remediation exercise.