Treat keeping the screen awake as a temporary, revocable enhancement for an active visitor task, with visible state and a usable ordinary-page alternative.
A website can ask to keep the screen awake for a useful task; it cannot promise that the device will remain awake indefinitely. The feature should help someone read a recipe, display a QR code or follow instructions without turning an optional enhancement into a requirement for using the page.
Imagine a fictional cooking guide with a “Keep screen awake while cooking” option. The reader may want it for ten minutes, switch to another application, then return. A good design explains what is active now and lets the reader finish normally when the request fails. The scenario and acceptance checks below are proposed, not device test results.
Define the promise before adding a control
MDN’s Screen Wake Lock overview describes a secure-context API that requests a screen lock and returns a sentinel representing it. The sentinel can be released. This is about keeping the display from dimming or locking; do not present it as a guarantee of background processing, uninterrupted downloads, a preserved login session or a completed server operation.
Write the visitor promise in task language: “Keep this recipe visible while you use it.” Avoid “Never sleep” or “Always on.” Explain the control next to the reading task, where someone can decide whether the extra screen time is useful. Do not activate it merely because an article opened.
Opt-in is an editorial product recommendation here, not a claim that this API universally requires the same user gesture as fullscreen. Keep unrelated permissions out of the interaction. A cooking mode does not justify requesting microphone, location or notification access.
Separate intent from the current lock
Use two different internal concepts: the reader wants the feature for this task, and the browser currently holds the requested resource. A checked preference should not be used as evidence that acquisition succeeded. Likewise, a release should not silently erase the reader’s place in the instructions.
| Feature state | Reader-facing message | Product response |
|---|---|---|
| Unavailable | This browser cannot offer the option here | Keep the recipe readable and offer the ordinary fallback |
| Request pending | Requesting screen-awake mode | Prevent confusing duplicate actions without blocking reading |
| Active | Screen-awake mode is active | Provide a clear stop action |
| Refused or released | Screen-awake mode is no longer active | Preserve the task and explain a possible deliberate retry |
| Finished by the reader | Screen-awake mode is off | End this task’s request and keep normal navigation available |
The wording is an original interface proposal, not a prescribed browser dialog. It deliberately avoids “Saved” or “Cooking complete”: neither follows from a screen state. If the reader selects the option twice while a request is pending, the page should still show one understandable task state rather than competing confirmations.
Handle refusal as an expected result
MDN’s request() reference describes asynchronous acquisition and NotAllowedError conditions including policy restrictions, an inactive or hidden document, and inability to obtain the platform lock, for example because battery is low. Feature detection is therefore only an initial check. Handle the actual request outcome and avoid treating refusal as evidence that the reader did something wrong.
Record enough local diagnostic context for the feature owner: the page route, supported browser version, visible task state and a coarse failure category. Do not collect the reader’s recipe history or unrelated device information merely to investigate this option. A report should help reproduce the state transition, not build a profile.
If the feature works as a normal page but not inside an embedded context, ask the site owner to review the applicable policy and integration. Do not instruct the visitor to disable browser protections. Keep the request refused until a responsible maintainer understands the scope.
Plan for leaving and returning
The 29 September 2026 W3C Working Draft ties screen wake locks to a visible document and permits platform-controlled release. It is a work in progress, not a Recommendation. An earlier grant cannot be treated as permanent ownership; the interface must respond when the lock is no longer held.
In the fictional recipe, switching away should not leave an “Active” badge that becomes misleading on return. Re-evaluate the current intent, task and visible state. Decide deliberately whether an eligible return should attempt a new request or ask the reader again. Document that choice for the implementation team.
Do not write a rapid retry loop to fight release. If a new request fails, leave a truthful message and the useful page. Preserve the current step so the visitor can carry on. Returning to a hidden or finished task is not a reason to keep requesting a device resource.
Release when the activity ends
Give the reader an obvious way to stop the enhancement while remaining on the recipe. Finishing cooking, closing the task view or choosing ordinary reading should end this feature’s interest in holding the screen awake. Make the status update reflect the resulting state, including when another event already ended it.
Define ownership if the page has more than one optional activity. A recipe and a presentation widget should not each assume they alone control a shared status label. Use one accountable feature state so ending an unrelated panel does not leave the reader wondering what is still active.
For support, describe the exact action that ended the feature and whether the ordinary page remained usable. An incident note that says only “wake lock lost” omits the practical question: did the reader lose work, control or understanding? Fix that product failure even if the platform’s release was expected.
Provide a fallback that completes the real task
A readable page with stable steps remains the primary experience. Offer an ordinary print route or downloadable instructions only when you can maintain those versions accurately. Do not claim a fallback changes the device’s sleep settings. Let the visitor use their own preferred device controls without prescribing a universal operating-system sequence.
Installation is a separate choice: installing a website as an app does not by itself prove this enhancement is active. Similarly, audio delivery and transcripts and motion preferences each need their own review. Avoid making a single “mode” label imply all of them work.
Accept the lifecycle, including ordinary use
- Review supported and unsupported browsers with the same useful recipe.
- Confirm that the pending message never claims acquisition before success.
- Exercise refusal and release in an authorised development test without weakening device protections.
- Leave and return to the page; check the observed status and preserved reading position.
- Stop the activity deliberately and verify that the feature no longer claims to be active.
- Repeat with the fallback and confirm that the visitor can still complete the task.
Record actual results by browser and device rather than calling the feature universally reliable. This guide supplies a review plan; the real implementation still needs those checks. A screen-awake option succeeds when it is understandable, temporary and recoverable, including the times it cannot be granted.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: Screen Wake Lock APIChecked Secure-context feature, sentinel lifecycle and screen-awake purpose.
Limits: Current support does not cover every older device; the enhancement needs a fallback. - MDN: WakeLock request()Checked Asynchronous acquisition and documented refusal conditions.
Limits: Availability and a completed request do not promise indefinite retention. - W3C: Screen Wake Lock Working Draft, 29 September 2026Checked Visibility and platform-controlled lifecycle constraints.
Limits: This is a Working Draft, not a W3C Recommendation or a universal platform guarantee.