Navigable, Not Just Readable

01What the Page Already Knows

When a sighted reader opens a book, the layout does quiet work. A chapter heading is visually obvious. A footnote sits apart. Running headers tell you where you are. None of that information is typed out in words — it is carried by position, size and white space. A well-formatted print page is a spatial argument, and a reader absorbs it at a glance.

Convert that page to digital text without thinking carefully about structure, and the argument collapses. The words survive. The hierarchy does not. A chapter title becomes a sentence that runs straight into the paragraph below it. A footnote becomes a block of text that interrupts the main narrative at whatever point the conversion software chose to drop it. The reader — using a screen reader, a braille display, or a DAISY player — has no glance. They move through the file sequentially, one element at a time. If those elements are not tagged to indicate what they are, navigation is impossible.

02Tags, Headings and Reading Order

The tags that carry structure are unglamorous: H1, H2, H3 for heading levels; markers for page numbers, sections and asides; a declared reading order that tells the software which block of text comes after which. In EPUB done properly, those tags sit inside the file's markup, invisible to any reader but essential to every reading tool. A screen reader interrogating a well-structured EPUB can present the user with a list of chapter headings, jump to chapter seven without scanning through chapters one to six, or skip a sidebar and return to it. None of that is possible when the file is a continuous unmarked stream of characters, however accurately transcribed.

Page numbers deserve particular attention. They are easy to dismiss — why would a digital reader need a print page number? — but they are how teachers assign reading, how citations are written, how a reader in one format keeps up with a group in another. An accessible file that preserves print page numbers as navigable markers lets a blind reader and a sighted reader work from the same reference points. Omitting them creates a quiet, persistent disadvantage.

03The Invisible Error

What makes structural problems so persistent is that they are invisible to the usual quality check. A sighted proofreader working on screen sees formatted text: the heading looks like a heading because it is bold and larger. What they do not see is whether the software has actually tagged it as a heading, or simply styled a run of text to look like one. Those are entirely different things. The first is navigable. The second is decoration. Both look identical on a visual proof.

This is why proofreading by touch — checking a braille or audio rendering of a file — catches errors that visual proofing cannot. The error only reveals itself when the file is read the way it will actually be used. Structure must be tested from inside the format, not inspected from outside it.

A document can be word-perfect and still be close to useless. Every word correct, every heading untouchable, every footnote precisely reproduced — and a screen-reader user still cannot jump to chapter three, still cannot skip the front matter, still cannot know whether the line they just heard is a section title or the first sentence of a paragraph. Accuracy and navigability are separate problems. They require separate work. Treating one as a proxy for the other is one of the most common and most consequential mistakes in accessible production.

Structure is not a formatting refinement added after the real work is done. It is the real work.