Separate plain-text paragraphs the standard way
T1 applies when the deliverable really is plain text. A transcript, a README, a plain-text email. There is no markup to declare structure, so the convention is the structure, and W3C lists this as sufficient for 1.3.1 Info and Relationships in the form that lets a relationship be available in text rather than in code. The rule is narrower than the version most people repeat. A paragraph is defined by blank lines alone. Exactly one blank line before it, one or more after it, and none inside. What happens within the paragraph does not matter, so an indented first line is fine and so is hard wrapping. A blank line can hold spaces or tabs and still count as blank. On an HTML page, use p elements and forget all of this.
How we find it in an audit
This only comes up where plain-text files are part of what gets shipped, which usually means transcripts and text-only email templates. We check that blank lines separate paragraphs consistently, and that no paragraph carries a blank line inside it splitting one thought into two.
How affected users experience it
Software uses the blank-line convention to move by paragraph and to pause in the right places. A transcript with a blank line after every wrapped line reads as dozens of one-line paragraphs, so moving by paragraph becomes moving by fragment and the real topic boundaries vanish into the noise.
Passes vs. fails
Passes
One blank line between speakers and none inside a turn. Each turn reads as one paragraph, wrapped however the file wants to wrap it.
Fails
A transcript with a blank line after every wrapped line, so one speaker's turn arrives as eight separate paragraphs.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
Other ways to satisfy this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C lists this one as sufficient for that rule when used for making information and relationships conveyed through presentation programmatically determinable or available in text, so the condition is part of the test rather than a footnote to it.
- ARIA11sufficientAdd landmarks so users can skip around
- ARIA12sufficientUse role=heading when h1-h6 is impossible
- ARIA13sufficientName repeated landmarks so they are distinguishable
- ARIA16sufficientName controls from visible text with aria-labelledby
- ARIA17sufficientGroup related form fields with ARIA roles
- ARIA20sufficientMark leftover page areas with role=region
This guide is our interpretation of W3C technique T1: Using standard text formatting conventions for paragraphs. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.