WCAG 1.3.1 — Information and Relationships Not Marked Up
Your page shows structure visually — headings, lists, form labels, table headers, groups of related fields — but that structure is not written into the page's code. A sighted visitor sees the layout and understands how the parts relate. A screen reader reads only what the code says, so it announces a wall of undifferentiated text. This is the single most common category of accessibility failure on government websites, and under the ADA Title II rule it is a required fix before your compliance deadline.
Who Is Affected
Screen reader users, who rely entirely on the code to understand how a page is organised. Also keyboard-only users navigating by landmark or heading, users of reading-mode and translation tools, and anyone using a browser extension that reformats pages for readability.
What This Means
This is the broadest success criterion in WCAG, and the one your scan most often reports. It says one thing: if structure is visible, it must also be in the markup.
A person looking at your page infers structure from appearance. Bold 18-point text is a heading. Indented dashes are a list. The word to the left of a box is that box's label. A row of bold cells across the top of a grid are column headers. None of that is conveyed by appearance alone in code — it has to be stated.
When it isn't, assistive technology has nothing to work with. A screen reader cannot announce "heading level 2" for text that is merely large and bold. It cannot say "list, 6 items" for paragraphs that begin with hyphens. It cannot tell a user which label belongs to which field, so a form becomes a sequence of unlabelled boxes.
This article covers the general case. Where your scan identified a specific kind of structural failure, the focused article will be more useful:
- Heading structure — text styled to look like a heading, or heading levels skipped
- Form labels — fields with no programmatic label
- Table headers — data tables with no header cells
- Lists — lists built from paragraphs and hyphens
- Layout tables — tables used to position content rather than present data
Fix: Content Editor
Most 1.3.1 failures are created in the editor, not the theme, and can be fixed there.
- Use the editor's built-in styles rather than manual formatting. Select the heading dropdown and choose Heading 2 — do not make text bold and enlarge it. In the WordPress block editor, use a Heading block. In Joomla's TinyMCE editor, use the Formats menu.
- Build lists with the list buttons. The bulleted and numbered list buttons produce real list markup. Typing a hyphen and a space does not.
- Never skip heading levels. An
h2is followed byh3, noth4. Levels describe nesting, not size — if a heading looks too big, that is a styling matter, not a reason to change its level. - Give every table a header row and mark it as one. In WordPress, the table block has a "Header section" toggle. In Joomla, use the table properties dialog to set the first row as a header.
- Do not use a table to lay out a page. If the table has no header row and its cells are not data, it is a layout table — rebuild it with the editor's column block.
- Check the result. Run the WAVE extension on the saved page. Its Structure panel lists the headings, lists, and tables the browser actually sees, which is what your visitors' assistive technology sees too.
Fix: CMS / Theme
Some 1.3.1 failures are site-wide and come from the theme or a template. Fixing one template repairs every page built from it.
- Wrap the page's regions in landmarks —
<header>,<nav>,<main>,<footer>— with exactly one<main>per page. If several regions share a role (two navigation blocks, say), give each anaria-labelso they can be told apart:<nav aria-label="Main menu">and<nav aria-label="Breadcrumb">. - Check that the template's own headings form a sensible outline. A common failure is a template that hard-codes an
h1for the site name on every page, leaving the actual page title as anh2— or, worse, twoh1elements per page. - Group related form controls. A set of radio buttons or checkboxes belongs in a
<fieldset>with a<legend>describing the group. Without it, a screen reader reads each option with no indication of what question it answers. - Remove presentational attributes from templates.
align,<font>, and inline spacing attributes carry no structural meaning and are flagged as failures. Move the styling to CSS. - Audit one page of each template type — home, landing, article, search results, contact form — rather than every page. Structural failures repeat by template.
Standard Reference
WCAG 2.1 Success Criterion 1.3.1 — Info and Relationships, Level A
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
- W3C Understanding SC 1.3.1
- WCAG Technique G115 — Using semantic elements to mark up structure
- WCAG Technique H42 — Using h1-h6 to identify headings
- WCAG Technique H44 — Using label elements to associate text labels with form controls
- WCAG Technique H51 — Using table markup to present tabular information
- WCAG Technique H63 — Using the scope attribute on table headers
- WCAG Failure F2 — Using changes in text presentation to convey information
- WCAG Failure F17 — Insufficient information in DOM to determine one-to-one relationships
- WCAG Failure F43 — Using structural markup inappropriately
- WCAG Failure F87 — Inserting non-decorative content with CSS
Check if your government website has this issue
OctoComply scans your website and documents for WCAG 2.1 AA violations. The free tier covers up to 10 pages.
Run a complimentary scan