F34: When Spaces Pretend to Be Tables

Plain text can do a lot. It can carry meaning across decades, survive format migrations, and render on almost any device. What it cannot do — reliably, accessibly — is represent a table.

WCAG Failure F34 (opens in new window) documents exactly this problem: using spaces, tabs, line breaks, and carriage returns to visually arrange data into rows and columns. The result looks like a table. It is not a table. And the gap between those two things has real consequences for people who rely on assistive technology.

The Failure

F34 applies to all technologies and names two success criteria as failing: 1.3.1 Info and Relationships (opens in new window) and 1.3.2 Meaningful Sequence (opens in new window).

The W3C's example is a weekly meal menu — Monday through Tuesday, Breakfast through Dinner — formatted with white space to create visual columns:

Menu
Breakfast            Lunch                Dinner
Monday
2 fried eggs         tomato soup          garden salad
bacon                hamburger            Fried Chicken
toast                onion rings          green beans
                     Oatmeal cookie       mashed potatoes
Tuesday
Pancakes             vegetable soup       Caesar salad
sausage              hot dogs             Spaghetti with meatballs
orange juice         potato salad         Italian bread
                     brownie              ice cream

Visually, this reads across rows. A screen reader reads it linearly, top to bottom, left to right — in document source order. What a screen reader actually announces:

"Menu. Breakfast. Lunch. Dinner. Monday. 2 fried eggs. tomato soup. garden salad. bacon. hamburger. Fried Chicken..."

The spatial relationship between "Monday" and "Breakfast" and "2 fried eggs" is gone. The header associations don't exist. There's no way to navigate to a specific cell, no way to know which column you're in, no way to understand that "tomato soup" is a lunch item and not a dinner item.

Why This Matters

Two distinct access barriers appear here, mapped to two distinct criteria.

1.3.1 Info and Relationships requires that information conveyed through visual presentation also be available programmatically. A sighted user understands the table structure because of how items are spatially arranged. A screen reader user gets none of that — there are no <table>, <th>, or <td> elements, no headers attributes, no structural signal of any kind. The relationship between a day of the week and a meal type simply doesn't exist in the markup.

1.3.2 Meaningful Sequence requires that when reading order affects meaning, that order be determinable programmatically. White-space tables fail this because their visual order (across columns) and their source order (down lines) are different things. The meaning depends on reading across, but the technology reads down.

This isn't a subtle edge case. It affects screen reader users who navigate content linearly. It affects users who increase text size until lines reflow and the spatial layout collapses entirely. It affects people using alternative display modes where fixed-width fonts aren't assumed. The W3C's own documentation notes that if text reflows or changes from fixed to variable font, the visual presentation breaks too — so this pattern fails sighted users in certain contexts as well.

The Fix

The W3C's guidance is direct: plain text is not suitable for displaying complex information like tables. The structure cannot be perceived. Two paths forward exist.

Option 1: Use semantic HTML. If the content is in HTML, use actual table markup:

<table>
  <caption>Weekly Menu</caption>
  <thead>
    <tr>
      <th scope="col">Day</th>
      <th scope="col">Breakfast</th>
      <th scope="col">Lunch</th>
      <th scope="col">Dinner</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">Monday</th>
      <td>2 fried eggs, bacon, toast</td>
      <td>Tomato soup, hamburger, onion rings, Oatmeal cookie</td>
      <td>Garden salad, Fried Chicken, green beans, mashed potatoes</td>
    </tr>
    <tr>
      <th scope="row">Tuesday</th>
      <td>Pancakes, sausage, orange juice</td>
      <td>Vegetable soup, hot dogs, potato salad, brownie</td>
      <td>Caesar salad, Spaghetti with meatballs, Italian bread, ice cream</td>
    </tr>
  </tbody>
</table>

The scope attributes on <th> elements create explicit associations between headers and data cells. A screen reader can now announce "Monday, Breakfast column: 2 fried eggs, bacon, toast" — the relationship is real, not implied by position.

Option 2: Present the information linearly. If the context is genuinely plain text (a .txt file, an email, a terminal output), restructure the content so it reads sensibly in source order. Group by day, then list meals by type with explicit labels. Remove the dependency on spatial layout entirely.

Applying This

F34 is one of those failures that automated testing catches inconsistently. A linter can flag a <pre> block full of spaces, but it can't always determine whether that block is decorative ASCII art or an attempt at data presentation. Research on automated testing limitations shows this pattern repeatedly — tools find what they're built to find, and semantic intent requires human judgment.

For code review, the signal to watch for is any content that uses monospace formatting or whitespace alignment to create visual columns outside of a <table> element. Common locations:

• README files rendered in web interfaces
• Email templates using plain-text fallbacks
• CMS content areas where authors paste from spreadsheets
• PDF exports from word processors with tab-aligned columns
• Help documentation written in plain text and converted to HTML

The CMS and email cases deserve particular attention. Authors who paste tabular data from Excel or Google Sheets often get white-space output if they paste into a plain-text field. A content governance policy that flags or blocks this pattern at the authoring layer prevents the problem from reaching production.

For teams navigating multiple compliance frameworks simultaneously, F34 is a clean example of a failure that triggers across standards — WCAG 2.2, Section 508, and EN 301 549 all trace back to the same underlying requirements. The compliance framework analysis on this site explores how organizations can address these overlapping obligations without duplicating effort.

CORS Perspective

Through a Strategic Alignment lens, F34 is a content governance problem as much as a technical one. The failure often originates not with developers but with authors, editors, and content managers who don't know that their formatting choices erase structure for a significant portion of their audience. Fixing this sustainably means addressing the authoring environment — restricting plain-text table entry, providing accessible templates, and training content teams — rather than auditing output after the fact. Organizations that treat this as a one-time remediation find the pattern returning; those that address it at the source see durable results. The testing methodology research on this site makes a related point: catching structural failures requires both automated scanning and human review of authoring workflows, not just published pages.