A successful preview build left one practical question unanswered: would the page still fit when its text became larger? In a September 23, 2026 check of Agent Model Fit, the browser had 390 pixels of available width, but the document measured 500 pixels across. After a change allowing header controls to wrap onto another line, the same recorded check measured a 390-pixel document.
That is a useful, limited finding for anyone reviewing an agent-built interface. The build had produced a working preview. A rendered-state check then exposed a layout defect. This account covers one static publication, headless Microsoft Edge, and text enlarged through CSS. It does not describe operating the browser’s zoom control or testing a physical phone.
What a successful build had established
The initial preview was recorded as READY on Vercel. That gave the reviewer a deployed candidate to inspect. It did not supply evidence for every way a reader might use the interface.
The distinction also applies to the development record. Separate local checks for types, lint, formatting, and a complete build could not run in that earlier session because required tooling was unavailable. A successful remote preview did not turn those unexecuted commands into passes. Each check retained its own result and limitation.
Our earlier publication build retrospective describes the project’s initial decisions and documentation work. This later episode concerns a specific rendered header, after the site’s reading and discovery changes.
The check and the correction
A viewport is the area in which a browser displays the page. Here its width was set to 390 CSS pixels. A CSS pixel is a browser layout unit; this measurement does not describe a device’s physical screen resolution.
The automated check opened an existing article in headless Edge, a browser running without its normal visible window. It injected a style that set the root font size to 200% and the reading column’s text to 36px. It then compared the document’s scroll width with the viewport width. The reading text normally measured 18px. The injected styles were a targeted enlargement technique, not proof that every text element doubled in size.
| Recorded state | Viewport width | Document width | Result for this check |
|---|---|---|---|
| Before the header correction | 390px | 500px | Document exceeded the viewport by 110px |
| After the header correction | 390px | 390px | No document-level horizontal overflow detected |
The header’s flex container initially kept its contents in one row. The code
change added flex-wrap, allowing the row to break when the controls needed
more room. The first observation was retained alongside the later result, so
the final pass did not erase the original failure.
An earlier narrow-screen correction had shortened the visible Search control below 360px. That belongs to the implementation chronology; it is not another independent experiment supporting the enlarged-text result.
The before-and-after measurements support the statement that the observed overflow was absent after the wrapping change under the recorded conditions. They do not establish a general defect rate, the number of all development attempts, or how well other browsers would behave.
Why the width difference matters
Reflow is the way content rearranges as the available space changes. When an ordinary article requires horizontal movement as well as vertical scrolling, reading becomes harder. W3C’s explanation of the Reflow criterion describes keeping content usable without scrolling in two directions at specified viewport sizes, with exceptions for content that needs a two-dimensional layout.
W3C’s separate Resize Text guidance addresses enlarging text to 200% without losing content or functionality, subject to the criterion’s exceptions. These sources explain why enlarged text and reflow deserve attention. They do not certify this check or this website.
The 390px check was narrower in scope than a full accessibility assessment. Matching document and viewport widths can rule out the particular overflow detected by this assertion. It cannot establish that all controls are readable, all content is available, or every accessibility requirement is met.
Some failed assertions belonged to the test
The same review cycle also retained four initial interaction assertion failures. Those need a different interpretation from the header overflow. The interaction harness checked focus after pointer input and read clipboard status before an asynchronous operation had completed. Its assertions were corrected to follow keyboard interaction and wait for completion; the final recorded interaction suite passed.
It would be misleading to call those four assertions four additional product defects. A useful review distinguishes a faulty interface from a check that asks the wrong question or checks too early. Keeping the initial results makes that distinction inspectable.
What the record still cannot tell us
This is first-party Fieldwork. Internal test records and the targeted code diff were inspected for this article; the editor retains their exact revisions and timestamps. Only this bounded summary is published. Raw logs, private paths, and deployment account details are excluded.
Physical-device testing, screen-reader testing, actual browser zoom controls, and exhaustive contrast assessment were not performed in the recorded episode. The evidence does not establish full Web Content Accessibility Guidelines (WCAG) conformance. Nor does it identify a model as the cause of the defect or the correction. Exact model attribution, total effort, cost, and business effects are unavailable.
An automated browser pass is also not human editorial acceptance. It answers the test’s question about a specific candidate. A person still decides whether the evidence is sufficient for the intended use.
Add one check that reflects a reader’s task
For the next interface you review, name one consequential rendered state before accepting the build: larger text, a narrow viewport, a long table, or navigation by keyboard. Record the candidate, browser, conditions, expected behavior, and observed result. When a defect is fixed, repeat the affected check and any related checks the change could invalidate.
Our agentic workflow architecture guide puts validation among the responsibilities of the surrounding system. This episode gives that responsibility a concrete example: a successful build and a page that fits the reader’s viewport answer different acceptance questions.
Provenance and review status
Prepared by Agent Model Fit with AI assistance for research, drafting, and comparison with the September 23 records. External guidance and internal evidence were inspected on October 2, 2026. Human editorial review by the Agent Model Fit team was completed on October 2, 2026. This article reports a historical observation; no new accessibility experiment or model comparison was performed for the article.