Thursday Field Note · Founder field note

The Menu Opened. Nobody Could See It.

A real website repair and a practical way to test the difference between an interface changing state and a visitor completing a task.

Thursday Field Note 04 · Founder Field Note

Operating question: did the interface change, or could the visitor actually complete the task?

Practical move: follow one action from intention through visible feedback to completion and recovery.

The menu was open. The person trying to use it still had no menu.

On October 1, a report about this website identified a concrete failure: at mobile and narrower widths, pressing the Menu button did not reveal the navigation. The expected behavior was simple. Open the menu; choose a destination or press outside it to close it.

During the repair, the technical state showed that the menu was open. The navigation itself was hidden. A responsive rule in a separate page's stylesheet was applying too broadly and suppressing navigation in the shared header.

I did not need a more elaborate animation to solve that problem. I needed the visitor's action to produce a visible, usable result.

The state was true. The experience was false.

This was a website maintenance episode, not a customer case study. The source change scoped that page's styles to its own route rather than letting them affect shared elements. The repair also checked menu closure, focus recovery, and behavior when moving between narrow and wide layouts.

Verification included local browser checks at widths of 360, 390, 768, and 1,024 pixels, followed by live checks at 390, 768, and 1,024 pixels. We checked opening, choosing a link, pressing outside, keyboard operation, repeated use, and resizing. Those checks support a bounded report of the repair; they do not establish that every device or accessibility need was covered.

A developer can ask whether the control changes state. A visitor asks whether they can get where they intended to go. The first can succeed while the second fails.

Conceptual interface layers show a triggered state becoming visible and usable rather than remaining hidden
Editorial Visualization · One visual modelIntention. Action. Visible result. Completed journey.

These four stages are a checking model, not a screenshot of the defect. A technical state transition sits inside the journey; it does not replace it.

Follow the action all the way through

I now use a four-stage model for reviewing an interface. It is small enough to use during ordinary maintenance.

  1. Intention: what is the person trying to accomplish? Here, it was reaching another part of the website.
  2. Action: can they operate the control with the input they are using? A click alone does not cover keyboard operation.
  3. Visible result: can they perceive what changed? An open state is not useful if its content is hidden, clipped, unreadable, or obscured.
  4. Completed journey: can they choose the destination, dismiss the panel, and continue? Recovery is part of use, not an optional finishing touch.

This model is not limited to menus. A filter should make the changed results understandable. A saved form should show whether saving succeeded. A review gate should reveal whether a decision is pending, accepted, or blocked. The precise feedback differs; the need to make the result perceivable remains.

Try the Visible Action Check

Choose one important action on your website or application. Use a real browser at a narrow width and a wider width. Then repeat with a keyboard. Ask five questions:

  • Trigger: can I find and operate the control?
  • Perceive: can I tell what changed without inspecting code?
  • Complete: can I reach the intended destination or outcome?
  • Recover: can I close, cancel, go back, or understand failure?
  • Repeat: does it still work after another action, route change, or resize?

Also enlarge the text. W3C's explanation of the resize-text criterion addresses resizing to 200 percent without loss of content or functionality, with exceptions for captions and images of text. That is a reason to check more than a default-sized screenshot.1

A fictional accessibility review scene includes a phone, tablet, keyboard, and desktop display
Editorial Visualization · Practical rehearsalCheck the journey, not just the screenshot.

Conceptual artwork, not a photograph of our testing team. Different inputs and layouts can expose a break that one polished screenshot misses.

Fix the boundary, then keep the test

In this repair, a shared visual failure came from a style boundary that was too broad. Fixing only the button would have left the underlying interaction between pages unresolved. The lesson is not a special trick for a menu; it is to inspect what else can affect a shared component and preserve a regression check for the actual journey.

This check is not a full accessibility audit, a security review, or proof that a design deserves an award. It is one practical way to catch a class of failures before declaring an interaction finished.

Start with the action your customers need most. Do not ask only whether the system did something. Ask whether the person could see it, use it, and continue. I would be interested in the first gap you find.

Research Record

References and Evidence

The October 1 repair is founder-directed experience documented in the website's source revision and browser verification record. No revenue effect, customer outcome, or universal device coverage is claimed. The model and checklist are my interpretation.

  1. Understanding SC 1.4.4: Resize TextAccessibility explanation · W3C WAI, WCAG 2.2 Understanding document; accessed October 8, 2026

    Explains resizing text to 200 percent without losing content or functionality, with stated exceptions. This informative explanation does not certify the website or validate the Visible Action Check.

Read nextReading Is Not Permission: Keep Business Documents From Becoming AI Instructions ↗

Continue the conversation

Good ideas improve under pressure.

If this model resembles something you are seeing in practice, or fails to account for it, I'd value the conversation.