v150 · HTML · Device Access

Fallback Experience

<usermedia> carries fallback content for browsers that do not expose HTMLUserMediaElement. This simulator shows five user-facing states — idle, pending, granted, denied, and unsupported — while the real fallback button can still call getUserMedia().

Simulate permission state
<usermedia> state surface
idle
Without <usermedia> (old approach)
Old pattern requires JS to:
1. Call getUserMedia()
2. Listen for devicechange
3. Query navigator.permissions
4. Manually grey out / show error
5. Handle browser differences

<usermedia> centralizes the trusted activation and fallback surface. The browser-owned element reports success through stream and failure through error or cancel.
Click "Enable Camera" above to trigger a real getUserMedia permission request, or use the simulate buttons to preview each state without touching the real API.
<!-- Native element with fallback content --> <usermedia id="capture"> <button id="fallback">Enable camera fallback</button> </usermedia> // Native path: browser-owned UI and events. capture.setConstraints({ video: {} }); capture.addEventListener("stream", () => preview.srcObject = capture.stream); capture.addEventListener("error", () => showError(capture.error)); capture.addEventListener("cancel", () => showCancelled()); // Fallback path: same user gesture, explicit JS call. fallback.addEventListener("click", () => navigator.mediaDevices.getUserMedia({ video: true }));

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗