How do I tell users when a website feature requires JavaScript or cookies?
Quick answer
Test the specific feature in the relevant browser conditions before saying it requires JavaScript or cookies. State what users need to do and what they will see if the requirement is not met. JavaScript and cookies are different mechanisms: either may be involved, both may be involved, or neither may be required. Mention an alternative only after confirming it works; otherwise, say plainly that you have not confirmed one.
The question, the details, the next step.
How should I figure out what to tell visitors? I know a feature may not work for everyone, but I don’t want to claim it needs JavaScript or cookies without checking.
Start by testing the actual feature, not by guessing from how the site was built. Check it in the browser conditions you intend to describe—for example, with JavaScript unavailable, with cookies blocked, and with both available. Record what happens in each case: does the feature work, show a message, fail to load, or offer another route? Repeat a test if the result seems inconsistent.
Keep the two requirements separate in your notes. JavaScript can be used to add interactive behavior, and a site can provide a message for people without it or, where possible, reproduce functionality through HTML and server-side scripting. Scripts may also fail to load because of third-party or network problems. Those general possibilities do not prove that your particular feature requires JavaScript or has an alternative. [S1]
Cookies can be set by a server or accessed by browser scripts, subject to browser rules. That general mechanism does not establish whether your feature needs cookies or what a visitor will experience if they are blocked. Verify the feature’s actual behavior before making either claim. [S2]
What should the note say if the feature really does require one of them?
Name the feature and the verified requirement in direct, specific language. Avoid broad statements such as “This website requires cookies” if you tested only one feature. Say what visitors can expect if the requirement is unavailable, but don’t promise that an error message or workaround appears unless you confirmed it.
A useful structure is:
“[Feature name] requires [JavaScript / cookies / both] to [specific action]. If [requirement] is unavailable, [verified result]. [Alternative, if confirmed].”
For example, as a wording placeholder—not a claim about any real site: “The [interactive planner] requires JavaScript to calculate and display your selections. If JavaScript is unavailable, the planner will not display the results. To continue, use [confirmed alternative].” If you have not confirmed an alternative, leave that sentence out rather than implying there is another way to complete the task.
How do I describe an alternative without overstating it?
Treat the alternative as a separate claim that needs its own check. Try the stated route from the same starting point and confirm that it lets a visitor complete the relevant task—not just view information about it. Be precise about its scope: an alternative might cover only part of the feature. If it is not equivalent, say what it does and does not let people do.
Use wording such as “You can [confirmed action] using [confirmed route]” only after checking that route. If no alternative is available or you have not verified one, say so plainly: “We have not confirmed an alternative for this feature.” That is more useful than suggesting visitors change settings, try random workarounds, or contact a person when you have no verified contact route.
Can you give me a reusable requirements note and a final check before I publish it?
Use this copyable template, filling every bracket from your own checks:
“[Feature name] [requires / does not require / has not been confirmed to require] [JavaScript / cookies / both] for [specific action]. When [JavaScript is unavailable / cookies are blocked / the requirement is unavailable], [observed result]. [If verified: To [complete the task / access the information], use [alternative] for [what it supports].] [If not verified: We have not confirmed an alternative.]”
Example with placeholders: “The [booking preview] requires [JavaScript] to update the displayed total. With JavaScript unavailable, [the total does not update]. [We have not confirmed an alternative.]” Use “requires” only when your test supports it; if behavior varies or the test is incomplete, describe what you observed and qualify what remains uncertain.
Before publishing, make sure the note is limited to the tested feature, distinguishes JavaScript from cookies, describes the actual fallback behavior, and does not present an untested route as an option. General documentation explains how these technologies can work; it cannot establish your site’s specific requirement or alternative. [S1] [S2]
A practical checklist
Test the specific feature in the browser conditions you plan to mention.
Check JavaScript and cookies separately; record the result for each condition.
Describe only behavior you observed, including any message or failure state.
Verify that a proposed alternative completes the stated task and note its limits.
Remove or qualify claims that remain untested or uncertain.
A few more useful answers
Can I say the whole site requires cookies if one feature uses them?
Not based on that feature alone. Limit the statement to the feature you checked, unless you have separately verified a broader site-wide requirement.
What if the feature behaves differently on repeated tests?
Do not state a definite requirement yet. Describe only the behavior you can confirm, investigate the inconsistency, and update the note when the conditions are clear.
Should I suggest that visitors change their browser settings?
Only if you have verified that the change addresses the specific issue and can explain it accurately. Otherwise, avoid presenting settings changes as a confirmed fix.
Sources
References used for this guide.
- [S1] Add JavaScript to your web page — MDN HTML guide developer.mozilla.org · Checked
- [S2] Using HTTP cookies — MDN developer.mozilla.org · Checked