WCAG 2.2 · Guideline 1.3 · Perceivable
Adaptable
Structure has to live in the code, not only in the way the page looks.
Sighted readers get structure for free. Headings look big, labels sit beside their fields, and a table lines up in a grid. None of that reaches a screen reader, which reads the code rather than the picture. So this guideline asks you to write the structure down as well as draw it. That is what lets a page survive being read aloud, zoomed to 400%, restyled by the reader, or flattened into one column.
Five A/AA success criteria live here, out of six. The one that carries the guideline is 1.3.1 Info and Relationships, which has fourteen automated test rules behind it, nine of them checking ARIA syntax rather than page structure. That is why a scan report can name 1.3.1 forty times on a site whose headings are perfectly good. Orientation, input purpose and reading order fill out the rest. The guideline itself has no test, so a finding written against 1.3 is a finding against one of those five, and the heading work you do for 1.3.1 also pays off against guideline 2.4.
- Rules
- 5
- Level A
- 3
- Level AA
- 2
- Human testing only
- 2
All 5 Adaptable rules
- 1.3.1Level AInfo and RelationshipsWhatever a sighted reader works out from the way a page looks has to be recoverable another way.Partly scannable52 fixes
- 1.3.2Level AMeaningful SequenceWhen the order content is presented in affects what it means, a correct reading order has to be recoverable from the code.Human testing12 fixes
- 1.3.3Level ASensory CharacteristicsInstructions for understanding or operating a page cannot lean only on how something looks, where it sits, which way it is turned, or what it sounds like.Human testing3 fixes
- 1.3.4Level AAOrientationContent must not restrict its view and its operation to one screen orientation, unless that orientation is essential.Partly scannable3 fixes
- 1.3.5Level AAIdentify Input PurposeA field collecting information about the person filling in the form has to declare what it is for, in code, using one of 53 defined purposes.Scanner-detectable2 fixes
Level AAA in this guideline
One enhanced criterion sits under 1.3. They are outside the level almost every law names, so our audits treat them as reference rather than scope. Some are still worth adopting, and the Level AAA hub says which.
What goes wrong here
These are the failures we find repeatedly under 1.3, across sites of every size.
- Headings are bold text rather than heading elements. The page looks structured and is not. Nothing can navigate it.
- A data table has no header cells, which turns a grid into a stream of unrelated values. A layout table is a different problem and not automatically a failure, though giving one false headers is.
- A form field has a visible label that was never tied to the input. The label is there for the eye and missing from the markup.
- Instructions lean on shape, size or position. "The button on the right" and "the green field" both stop working the moment the layout or the colour is not available.
- Inputs collecting a user's own name, email or address carry no autocomplete attribute, so their purpose is not exposed programmatically for the tools that can act on it.
Who it affects
- Screen reader users, who navigate by heading and landmark and are stranded when a page has neither. It is the fastest way to make a long page unusable.
- People using speech input, who say the name they can see. A control's accessible name has to contain its visible label, or the spoken command misses.
- People with motor disabilities, for whom autofill removes a large amount of typing from a long form.
- Anyone reading through their own stylesheet. Custom styling replaces yours rather than removing all of it, so the question is whether your meaning survives when your presentation does not.
How to work through it
- 1Turn the site's CSS off. Read the page through. What survives is your real structure, and what vanishes was never structure at all.
- 2Pull up the heading outline on its own and read it as a table of contents. If it does not describe the page, neither does the markup.
- 3Tab through every form and confirm each field announces its own label as you arrive. Clicking the label and watching focus move is a hint, not proof, because a script can move focus without exposing any relationship.
- 4Search the copy for directions that depend on where something sits or what colour it is. Then rewrite them to name the thing.
- 5Rotate the page to landscape and back. Content that locks to one orientation fails unless that orientation is essential to what it does.
- 6Check the autocomplete attribute on inputs asking for the user's own information. The rule covers a defined list of purposes, so it is not every field on the form.
How the levels build
Level A sets the structural core: information and relationships, meaningful sequence, and instructions that do not depend on a sensory characteristic. Level AA adds two. Content works in either orientation unless one is essential, and inputs collecting the user's own data expose what they are for. Level AAA reaches further, asking that the purpose of components, icons and regions be identified programmatically. Implementation of that last one is thin in practice, and the honest reason is that the ecosystem around it is still settling rather than anything about the criterion itself.
Other Perceivable guidelines
- 1.1Text AlternativesAnything that is not text needs words attached, because text can be read, spoken, or felt.
- 1.2Time-based MediaAudio and video need captions, transcripts, and description, because sound and picture do not reach everyone.
- 1.4DistinguishableContent has to be easy to see and hear as it ships, with no adjustment needed.
Part of the Perceivable principle · browse by level: Level A · Level AA · or the full 55-rule library.
See how your site does against these rules.
An expert review plus a real blind screen-reader user, on up to 10 pages, every finding with its screenshot, criterion, and fix. $499, report in 5 business days.