F48: When ASCII Art Masquerades as Data

37%. That's roughly the share of accessibility failures that automated tools can reliably catch — which means the other 63% depends on human judgment. F48 (opens in new window) sits squarely in that harder-to-detect category: a pattern that looks fine on screen, passes a quick visual review, and still completely fails the people who need structure to navigate data.

This is a failure about the gap between visual presentation and semantic meaning — and it's older than most accessibility professionals realize.

The Failure

W3C's official WCAG 2.2 techniques catalog documents F48 as a failure of Success Criterion 1.3.1: Info and Relationships (opens in new window). The pattern is straightforward: using HTML's <pre> element to display what is functionally tabular data.

The <pre> element preserves whitespace and monospace formatting. Developers and content editors have used it for decades to create visual grids — election results, schedules, pricing tables — by carefully spacing columns with tabs and spaces. On screen, to a sighted user, it looks like a table. To a screen reader, it's a wall of text.

Here's the failure pattern directly from the W3C source:

<!-- FAILURE: Schedule as preformatted text -->
<pre>
  Monday    Tuesday    Wednesday  Thursday   Friday
  8:00-
  9:00      Meet with Sam
  9:00-
  10:00     Dr. Williams  Sam again  Leave for
                                     San Antonio
</pre>

And a more complex example — election results:

<!-- FAILURE: Election results as preformatted text -->
<pre>
  CIRCUIT COURT JUDGE BRANCH 3
              W    R    M
              R    I    A
  ...
  0001 TOWN OF ALBION WDS 1-2    22   99    0
  0002 TOWN OF BERRY WDS 1-2     52  178    0
</pre>

The <pre> element communicates nothing about data relationships. There are no column headers. No row associations. No way for assistive technology to tell a user that "22" belongs to candidate W.R. in precinct 0001. The visual alignment is purely cosmetic — it evaporates the moment a screen reader linearizes the content, or a user increases text size, or the viewport narrows on a mobile device.

Why This Matters

For screen reader users, <pre>-formatted tables aren't tables at all. They're undifferentiated text. A JAWS or NVDA user navigating a schedule formatted this way gets the content read out in document order — which, depending on how the spacing was constructed, may produce something nearly unintelligible: a string of day names, then times, then names, with no structural cues connecting them.

Users who rely on table navigation commands — pressing T to jump to the next table, or using row/column navigation shortcuts — find nothing. The structure simply isn't there.

For users with cognitive disabilities, the problem compounds. When the visual grid breaks — because a user's browser renders the monospace font differently, or because they've applied a custom stylesheet, or because they're on a narrow screen — the carefully constructed spacing collapses. What looked like organized data becomes chaotic.

The election results example in the W3C document is particularly telling. Abbreviated candidate names stacked vertically across multiple header rows is already a heavy cognitive load for sighted users. Remove the visual alignment, and the data becomes genuinely inaccessible — not just inconvenient.

The Fix

The correction is semantic HTML. The <table> element exists precisely for this use case, and it carries structural meaning that assistive technologies can interpret:

<!-- CORRECT: Semantic table structure -->
<table>
  <caption>Weekly Schedule</caption>
  <thead>
    <tr>
      <th scope="col">Time</th>
      <th scope="col">Monday</th>
      <th scope="col">Tuesday</th>
      <th scope="col">Wednesday</th>
      <th scope="col">Thursday</th>
      <th scope="col">Friday</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">8:00–9:00</th>
      <td>Meet with Sam</td>
      <td></td>
      <td></td>
      <td></td>
      <td></td>
    </tr>
    <tr>
      <th scope="row">9:00–10:00</th>
      <td>Dr. Williams</td>
      <td>Sam again</td>
      <td></td>
      <td>Leave for San Antonio</td>
      <td></td>
    </tr>
  </tbody>
</table>

Key elements that make this work:

• <caption> — provides a programmatic label for the table as a whole
• <thead> and <tbody> — group header and data rows semantically
• scope="col" and scope="row" — explicitly associate headers with their data cells
• <th> vs. <td> — distinguishes header cells from data cells

A screen reader user navigating this table can press a key to hear "Monday, column 2" or "8:00–9:00, row 2" — the structural relationships are machine-readable and therefore accessible.

Applying This

The detection challenge here is real. Most automated scanners won't flag <pre> content as a table failure — the tool sees preformatted text and moves on. As our research on automated testing methodology documents, this is precisely the category of failure that requires human review: a tester who recognizes that visual alignment doesn't equal semantic structure.

For code review, the signal to watch for is <pre> elements containing tab characters or multiple consecutive spaces in patterns that suggest columns. A simple search across a codebase for <pre> tags is a reasonable starting point — then human review of each instance to determine whether the content is genuinely preformatted code/poetry/ASCII art (legitimate <pre> use) or disguised tabular data (a failure).

For content management systems, the risk is often in legacy content. Editors who learned HTML in the 1990s — or who copied content from old documentation — may have used <pre> tables as a matter of habit. A content audit targeting <pre> elements is a low-cost, high-value task.

For design systems and component libraries, the fix is upstream: ensure that any component presenting tabular data uses <table> semantics, and that documentation explicitly discourages <pre> for data presentation. When the right pattern is the easy pattern, developers make better choices by default.

The compliance picture matters here too. Under Title II of the ADA (opens in new window) — which now explicitly covers web content for state and local governments under the DOJ's 2024 final rule — WCAG 2.1 Level AA (opens in new window) is the enforceable standard. SC 1.3.1 is Level A, meaning it's not optional at any compliance tier. Government sites presenting election results, public meeting schedules, or service information in <pre>-formatted tables aren't just making a technical error — they're potentially failing their legal obligation to provide equal access to public information.

The compliance standards landscape is genuinely complex, as our research on multi-standard compliance explores — but on this particular point, WCAG, Section 508, and EN 301 549 are aligned. Tabular data requires table markup. That's not ambiguous.

CORS Perspective

From a risk/legal priority lens, F48 occupies an interesting position: it's a Level A failure (the floor of compliance, not the ceiling), it affects information that is often civic or high-stakes in nature — election results, government schedules, public records — and it's the kind of violation that surfaces most clearly in a DOJ complaint or OCR investigation, not an automated scan. Organizations that believe their automated testing coverage constitutes due diligence are exposed here. The fix is low-cost and technically straightforward; the barrier is awareness, not capacity. That's actually a reason for cautious optimism — this is a solvable problem, and solving it doesn't require a budget line, just a policy that <pre> is not a table.