F33Documented failure WCAG 1.3.1 WCAG 1.3.2 Level A Human testing required

Do not fake columns with white space characters

F33 is a documented failure filed under both info and relationships and meaningful sequence, and it is what happens when plain text is asked to do a layout job. Two columns drawn with spaces look right on screen and hold no relationship at all. Each line is a slice of column one glued to a slice of column two, and that is exactly what gets read out. There is a second consequence that reaches sighted readers, and it is the one that convinces people. Reflow the text, change to a variable-width font, or enlarge it until the lines no longer fit, and the visual presentation breaks apart the same way. So this is not only about assistive technology. Two repairs are on offer and most summaries give one. Use a technology with structural elements for columnar data, or change the content so it is not columnar at all, which for a plain text export or an email template is usually cheaper and better.

How we find it in an audit

The check needs no assistive technology. Find the parts of the page that look like columns, then look at whether the columns are made of white space, which is two steps and settles it. We do listen to it as well, because hearing the interleaving is the fastest way to show somebody why it matters. Automated tools can find runs of spaces inside text blocks, which shortlists the candidates. Whether the result is columnar is something you see.

How affected users experience it

Assistive technology reads content in the reading order of the language, which for English is left to right, line by line. Two columns of addresses become "Our offices Our hours", then "Berlin and Madrid Weekdays 9 to 17", and the reader has to work out which half belongs to which heading while it is still being read to them. Longer columns are worse, because the interleaving carries on for as long as the columns do. By the fifth line the pattern has stopped being recoverable.

Passes vs. fails

Passes: headings exist in the code. Fails: one flat wall of text.

Passes

<div class="columns">
  <div><h3>Our offices</h3><p>Berlin and Madrid</p></div>
  <div><h3>Our hours</h3><p>Weekdays 9 to 17</p></div>
</div>

Fails

Our offices:        Our hours:
Berlin and Madrid   Weekdays 9 to 17
<!-- Read aloud, each line pairs the wrong halves. -->

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

The other techniques filed under this rule

52 guides on this site are filed under 1.3.1 Info and Relationships. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.

This guide is our interpretation of W3C technique F33: Failure of Success Criterion 1.3.1 and 1.3.2 due to using white space characters to create multiple columns in plain text content. 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.