Should Your Web App Keep the Screen Awake During Hands-Free Work?

If staff read instructions without touching the device, or show a code while someone scans it, a screen that keeps dimming interrupts the task. Ask for a temporary “keep screen awake” mode for that activity, not a promise that the whole app will run forever. The feature needs a visible status, an off switch and a usable fallback when the device refuses it.

This is a browser-app commissioning decision. It is not a way to bypass a managed device’s security rules, turn a browser into a locked-down kiosk or guarantee background processing.

Name the activity, not just the screen

Imagine a small workshop using a tablet to display assembly instructions. This is an illustrative scenario, not a client result. The technician reads for several minutes with both hands occupied, then returns to the job list. Keeping the instruction view awake could help; keeping the list awake for the rest of the shift is a different decision.

Write down the exact start and end: the person chooses instruction mode, sees that the screen is being kept awake, and ends the mode when finished. Decide whether opening another job ends the mode too. Avoid a site-wide setting that silently follows users through unrelated pages.

MDN’s Screen Wake Lock documentation describes preventing dimming or locking for visible, active documents. It names reading, recipes, presentations and code scanning as examples. Those examples establish the capability’s purpose, not suitability for every workplace.

Requested is not the same as active

A button labelled “Keep awake” expresses intent. It does not prove the browser accepted the request. MDN notes that requests may be rejected because of system settings, power-saving mode, low battery or a document that is not active or visible.

Specify separate messages for active, unavailable and ended. A refusal should leave the instructions readable and explain that normal device sleep settings still apply. Do not show an active badge merely because the person pressed the button.

Ask the developer to check the actual supported browser and device set. A successful demonstration on one laptop does not establish that every older tablet will behave the same way. If this feature is essential to the work, confirm the device plan before accepting a fixed project scope.

Returning to the tab is a new lifecycle decision

The documentation explains that the system can release the lock, including when the document is no longer active or visible. Once released, that lock object cannot simply be reused; another request is needed.

Decide what should happen when a worker switches tabs and comes back. The app might offer to resume the mode or attempt a new request while the user’s chosen activity is still in progress. Either way, the displayed status must reflect the new outcome. Returning must not silently override an explicit choice to turn the feature off.

This is not a background-work guarantee. If your actual requirement is completing a long upload, synchronizing records or receiving work while the browser is closed, scope that separately. Keeping a display awake is not evidence that those tasks will complete.

Stop keeping it awake when the benefit ends

MDN recommends releasing the lock when the activity requiring it ends. Translate that into named exits: completing the instruction sequence, leaving presentation mode or closing the code display. Provide a direct off control as well.

Consider the information left visible. A brighter, longer-lived display can expose a customer name or work details to people nearby. Decide what this view should contain and how the ordinary sign-out or session rules interact with it. These are design and security questions for the project, not claims that a wake lock creates access protection.

Do not instruct workers to disable their organization’s device lock policy as a workaround. If unattended displays are genuinely needed, arrange a separate device-management and security review.

Acceptance should include interruption

Use invented instructions and non-sensitive sample codes. Demonstrate activation on each agreed device/browser combination and confirm the status follows the actual result. Then turn the mode off and verify that the app releases its request; normal sleep behavior remains subject to the device’s settings.

Switch to another tab, return and check the agreed resume behavior. Simulate or reproduce refusal through an available supported test method and confirm that instructions remain accessible without a false success message. End the activity and verify that the app no longer claims to keep the screen awake. Test a user-disabled state as well: returning to the page must not undo that choice.

Bring the hands-free task, intended devices and interruption cases to a web-app project discussion. The useful deliverable is a controlled reading or display mode with honest limits, not an “always on” label that conceals what the device is actually doing.