As part of a wider audit, we turned JavaScript off and clicked through every one of the 115 pages in our own sitemap. Three categories of controls were dead or missing sitewide: the phone menu, every footer link group, and every FAQ answer. Below 1300px wide, the phone menu is the only way to navigate at all, so on a phone with scripts blocked or failed, the site had no navigation at all.
None of this showed up in a normal test pass, because a normal test pass has scripts on. It only showed up because we went looking for it on purpose.
The menu, the footer and the FAQs were never really there
All three were built to open and close with JavaScript, which meant that without it they did not open or close at all; the FAQ answers were not even in the page's HTML. The fix was to stop depending on script for something HTML can already do. The phone menu toggle is now a native <summary> element with its groups as nested <details>, the same pattern we used for the footer's link groups and for every FAQ accordion. A browser has handled expand and collapse natively for years; we had quietly rebuilt it in JavaScript and lost the free version. Scripted enhancements still run on top, closing the menu on Escape or after navigating, keeping one FAQ answer open at a time, but none of that is required for the content to be reachable.
Some controls cannot work without a script, and that is fine, if you say so
Not everything on the site can degrade gracefully. The Hexagram Diagnostic and the contact form both depend on Cloudflare Turnstile for bot protection, which needs JavaScript by design. Leaving a "Start the Diagnostic" button sitting there, clickable but doing nothing, is worse than being honest about the limitation. A dead button is a worse failure than an absent one, because it tells a visitor something is broken rather than something is unavailable. We now hide that button without script and show a note offering email, WhatsApp or a booked call instead.
The same logic applied to our own unsubscribe page: the confirm button called an API with fetch, so with scripts off it did nothing. It is now a plain HTML form that posts to the server directly and gets a real page back, and the one-click unsubscribe that mail clients themselves send still works exactly as before.
What the sweep actually found, in order
The audit moved in stages, and the numbers tell the story better than the description does. The first pass found three categories of script-only controls sitewide: the menu and footer on every page, and FAQs on 26 of 33 page types. After fixing those, it was down to three specific pages: the Diagnostic's answer buttons, and the filters on the blog and case studies pages. After hiding what cannot work without script and replacing blog and case-study filters with a plain, complete list when there is no script to drive them, the sweep across all 115 pages came back at zero.
The lesson is not really about JavaScript
Test the version of your site that a slow connection, a blocked script or a corporate proxy actually serves, not only the one your own laptop renders. Most visitors will never notice the difference, because for most visitors JavaScript loads and runs normally; when the UK Government Digital Service measured this on GOV.UK, about 1 in 93 visits arrived without it, and most of those were scripts that failed, not users who had switched them off. The ones who matter most here are the ones you cannot see failing: no error logged, no support ticket, just someone who could not open the menu and left.
That is the same instinct behind the Hexagram Audit: a business's marketing structure is judged by what is actually reachable, not by what works when everything is going right. A related story: the first screen bottleneck we found auditing a different site against a design jury's criteria. If you want your own site or funnel held to the same standard, the Hexagram Diagnostic is the free first step.
