hamsa software
← All articles
Engineering7 min read

The page around the paragraph

A worked viewport budget and a reference-return fixture reveal how navigation, promotion and source checking compete with sustained reading.

Four overlapping radial blades surround a small dark central opening, suggesting the space left for reading within the surrounding page.

The reader leaves the paragraph for a good reason

A reader follows a source, checks the claim and returns to the article. The link works, but the heading lands underneath the sticky header. At the bottom, a contact prompt covers another piece of the argument. Each component has performed its own job; the reader is left scrolling around to recover theirs. That is a page-layout problem a comfortable font will not solve.

None of those components is obviously unreasonable. Navigation helps people move around; a business needs enquiries; a reference makes an argument inspectable. The problem emerges from their combined effect on the reading task. Reviewing the components separately misses the person trying to use them together.

I would review that whole trip before comparing typefaces: find the claim, inspect its source, return and continue reading. A page can have pleasant typography and still make the trip needlessly difficult. Following the return link with a keyboard adds another question: can the reader continue from the passage, or does the next Tab press leave them in the reference list?

The calculation below assigns layout dimensions to expose the competition for space; it is not a reading-speed or conversion test. A small self-contained fixture lets you follow the reference journey while changing the surrounding layout. Keep the task and content constant so that a new heading, shorter paragraph or easier question does not become another changing part of the comparison.

Account for the screen the article actually receives

Start with an illustrative content viewport 720 CSS pixels high, after browser controls have taken their share. A persistent header uses 72 pixels, a section-navigation strip 44 and a contact prompt 80. Those elements occupy 196 pixels, leaving 524 for unobstructed reading. The figure shows the same calculation against two alternative arrangements so the trade is explicit rather than hidden in a screenshot.

Move the 80-pixel contact prompt to a natural stopping point in the document and the unobstructed span becomes 604 pixels. Use a 56-pixel header and move section navigation into ordinary flow, and it becomes 664. The first change gives the argument another 80 pixels without removing the contact route. The second also changes how quickly a reader can reach section navigation. These are different choices, so compare them separately before deciding that every persistent component should leave.

A visitor ready to enquire may welcome a persistent contact action. Someone still working through the explanation is paying for it with part of their reading area. Putting the action after a worked example and keeping contact in the main navigation is one alternative: the route remains available when the reader reaches a useful stopping point. Compare that journey with the persistent version on the same content before deciding which serves these visitors better.

Actual space changes with viewport, browser state, text size and wrapping. A header that gains another line needs more room than the earlier design assumed. In the fixture, the current rendered header height updates the anchor offset when that option is enabled. Watch its displayed geometry as you change spacing or zoom, then follow the same return link again. This connects the visible lost-heading problem to a specific layout dependency: the destination needs room for the header that exists now.

An illustrative 720-pixel viewport, allocated three ways

Assigned layout values, not measurements or reading-performance results. Browser controls are already outside the assumed content viewport.

Scroll sideways to see all columns.

ArrangementPersistent spaceUnobstructed span
Header 72 + navigation 44 + contact 8072 + 44 + 80 = 196 px720 − 196 = 524 px
Contact moves to document flow72 + 44 = 116 px720 − 116 = 604 px
Header 56; other controls in flow56 px720 − 56 = 664 px
Moving the example contact prompt releases 80 pixels. The ledger compares space allocation; observe the actual return journey separately. Rendered dimensions change with viewport and text settings.

An anchor can arrive and still be hidden

The fragment address can be correct while the heading is invisible. The browser has reached the requested place; it has no reason to complain that the site has parked its navigation on top of it. The reader then scrolls back or guesses where the passage begins. Testing only the URL would mark the link as working and miss the relationship that needs repairing: the target’s position beneath the header that is actually rendered.

One possible repair is to reserve an offset around anchor targets. The CSS scroll-margin-top property provides an outset for the target’s scroll area.[2] In the fixture, the enabled offset follows the observed header height plus a little breathing room. An old fixed offset can become too small when navigation wraps, so repeat the return after changing text settings. Check both the heading and enough following prose to recognise the argument; revealing only the final line of its title is an incomplete repair.

Keep the reference relationship understandable too. Name the source and provide a deliberate return point where appropriate. Do not force every source into a new tab on the assumption that all readers want the same workflow. Some inspect evidence immediately, some compare sources side by side and others save a link for later. An ordinary usable link can leave that choice with them.

Follow both the browser’s return route and the explicit backlink. With a keyboard, inspect the destination and press Tab once: does the next focusable item belong to the passage you returned to, or are you still navigating the distant reference list? A visible scroll position and a keyboard position can diverge. Record the starting link, destination, focus indicator and next Tab target. Those four observations locate the problem much more precisely than a note saying that the page jumped.

css
/* Illustrative target offset; update the variable from rendered height. */
.anchor-offset h2 {
  scroll-margin-top: calc(var(--header-height) + 1rem);
}
Check where the return link leaves the keyboard

A reference-return observation record for the article fixture, independent of its viewport-space calculation.

Scroll sideways to see all columns.

ObservationInspect on returnWhy it matters
Scroll destinationHeading clears the current headerCorrect fragment does not guarantee visibility
Focus indicatorCurrent keyboard position is apparentFocus and scroll can diverge
Next Tab targetBelongs to the returned passageReader can continue from the relevant point
Record the starting link and these observations at each setting. These are proposed checks, not reported assistive-technology test results.

Enlarge the whole journey, not just the central text

Zoom and narrow-screen layout can expose competition the default view conceals. W3C's reflow guidance concerns preserving information and functionality without unnecessary two-dimensional scrolling, with exceptions for content that genuinely needs that layout.[1] Meeting that requirement still leaves an editorial decision about how much persistent furniture should surround a sustained argument. A technically reachable paragraph can receive very little space.

Text-spacing overrides test another relationship. W3C describes preserving content under specified changes to spacing; it does not prescribe those values as everybody's preferred default.[3] The central paragraph may adapt while a reference card clips its title or a control wraps into an overlapping row. Check captions, labels, citations and navigation with the article, rather than declaring success because the body text grew.

A wider font or larger text may push navigation onto another line. Now the header occupies more space and the old anchor offset is too small, even though neither the link nor the heading changed. Let the destination offset follow the rendered component and let containers grow. At some settings several persistent rows may stop being helpful; compare an alternative that retains their destinations, rather than gaining reading room by quietly deleting part of the journey.

Keep code and genuinely wide tables in usable, labelled regions where necessary instead of making the whole page scroll sideways. The reader should not have to traverse a long horizontal line simply to return to the prose. For this review, the question is whether they can carry a thought through the evidence journey at their chosen settings, not whether each isolated component still resembles its original thumbnail.

Follow the same return path after the repair

The reading-journey fixture keeps the content constant while offering switches for a fixed contact prompt, an anchor offset and increased spacing. It contains a claim, supporting note and explicit return link. Its displayed dimensions come from the current viewport and rendered elements. Open it beside the article and use one setting at a time: otherwise it becomes difficult to tell whether the extra space, corrected heading position or changed spacing made the journey easier to follow.

A useful review note names the exact place the reader lost: the target heading was hidden, the return went to the source list, or keyboard focus remained away from the passage. Ask a colleague what they expected the return action to do before changing the design. Then repeat the same claim-checking task after the repair. Compare that expectation with the position of the heading and the next keyboard target. A repair needs to restore the route the colleague expected, rather than simply move more content into view.

Keep the claim, its reference and the return link when the template changes. Together they catch a failure that a screenshot of beautiful body text cannot show: losing the argument while checking its source. Repeat the route at the reader’s chosen text settings, including the next keyboard move. That gives a font discussion something concrete to work around—the space and navigation needed to carry the same thought out to its evidence and back.

  • Begin with the contact prompt fixed and the anchor offset disabled. Follow the note and return to the heading.
  • Enable the offset and repeat the same return, checking the heading and the next keyboard target.
  • Move the prompt into document flow and compare available space while retaining access to the contact action.
  • Change browser zoom and spacing. Record the viewport, browser, settings and actual obstruction so a colleague can repeat the route.

Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.

See the Payment Operations Pilot

References & further reading

Primary sources behind this article. Living documentation may change.

  1. W3C: Understanding Reflow
  2. MDN: scroll-margin-top
  3. W3C: Understanding Text Spacing
Hamsa Jama

Practical engineering. A human perspective.

More about Hamsa Software and the person behind it. Editorial notes.

A few more things
worth a read.

Back to the reading room
Engineering7 min read

What does £240 belong to?

A readable table preserves relationships between values, row labels, column headings and actions across different ways of reading.

Engineering7 min read

When two calculations agree on the wrong answer

A shadow comparison exposes differences. Independent rule examples explain whether those differences are bugs, corrections or changed assumptions.