A team drops the `controls` attribute from `<video>` and builds their own control bar. What does the native control bar provide that the custom one now has to reproduce?
answer
- a widget, not decoration
- the invisible half is the expensive half
- keyboard, names, captions, OS keys
- captions still render, the menu does not
- real buttons and a real slider
basics
~20 sThe native bar is a fully keyboard-operable, screen-reader-labelled, localised player with play, seek, volume, fullscreen, picture-in-picture, a captions menu and OS media-key integration. Removing it hands all of that to the team, and most custom bars rebuild only the visible parts.
solid answer
~50 s`controls` is not decoration — it is a whole user agent widget. It gives you play/pause, a seekable timeline, volume and mute, fullscreen, picture-in-picture in most browsers, a menu listing every `<track>` by `label`, and integration with the operating system's media keys and lock-screen controls. All of it is keyboard-operable, labelled for assistive technology, and localised into the user's language for free. A custom bar must rebuild every one of those, and the parts teams forget are the invisible ones: keyboard operation, accessible names, the caption switcher and the OS integration. There is one thing you do keep — text-track rendering is a browser behaviour, so a `default` caption track still paints over the video without native controls, while the user's way to switch or disable it vanishes with the menu. Build controls from real `<button>` elements, and only take the job on when the design genuinely requires it.
code
html · 15 lines<!-- One attribute buys a keyboard-operable, localised, caption-aware player -->
<video src="talk.mp4" controls width="1280" height="720" poster="frame.jpg">
<track kind="captions" src="talk-en.vtt" srclang="en" label="English" default>
</video>
<!-- Custom bar: real buttons and a real slider, not divs -->
<video id="player" src="talk.mp4" width="1280" height="720" poster="frame.jpg">
<track kind="captions" src="talk-en.vtt" srclang="en" label="English" default>
</video>
<div class="bar">
<button type="button">Play</button>
<input type="range" min="0" max="100" value="0" aria-label="Seek">
<button type="button">Mute</button>
<button type="button">Captions</button>
</div>go deeper
Know that the controls attribute makes the browser render a full player, and that removing it leaves a bare video the user cannot start. Do not remove it without a reason.
Enumerate what the native bar provides beyond visible buttons — keyboard operation, accessible names, localisation, the captions menu — and explain why a div cannot serve as a play button.
Weigh the trade explicitly: name the invisible features teams drop, note that a default caption track still renders while the menu vanishes, and give the concrete review checklist for a change that removes controls.
Decide the policy — whether the organisation runs a shared player, buys one, or uses native controls by default — and set the accessibility bar any custom player must clear before it can ship in a product.
## What the attribute actually is ```html <video src="talk.mp4" controls width="1280" height="720" poster="frame.jpg"></video> ``` One boolean attribute, and the browser renders a complete media player. It is worth enumerating the surface, because "we'll add buttons" badly underestimates the job. ## The inventory you are taking over **Visible transport.** Play/pause, a timeline showing current position and buffered ranges that can be scrubbed and clicked to seek, elapsed and remaining time, volume with mute. **Windowing.** Fullscreen. Picture-in-picture, offered by most desktop browsers. On mobile, the platform's own fullscreen player with its gestures. **Text tracks.** A menu listing every `<track>` child by its `label`, letting the user turn captions on, switch language, or turn them off. This is the single most commonly dropped feature in custom players, and it is the one that matters most to the users who depend on it. **Keyboard.** The native bar is reachable by Tab and operable by Space, arrow keys and Enter without a line of your code. Every control has an accessible name, exposed to screen readers, already translated into the user's language. **Platform integration.** Media keys on the keyboard, lock-screen and notification-shade controls on mobile, and the browser's own tab-level mute and "currently playing" affordances. **Localisation and familiarity.** The labels are in the user's language and the widget looks like every other video they have used in that browser. A custom player is a new interface to learn. ## What survives removal One useful nuance, and a good discriminator in interviews: **text-track rendering is not part of the control bar.** A `<track kind="captions" … default>` still renders its cues over the video with `controls` absent, because painting cues is a media-element behaviour. What disappears is the *menu* — so a custom player without a caption control can leave a user stuck with captions burned on screen and no way to turn them off, which is worse than either extreme. The media element also still fires its events and exposes its state; you are re-skinning the UI, not replacing the player engine. ## Rebuilding it without regressions - **Use real elements.** Play/pause, mute and fullscreen are `<button>` elements. A `<div>` with a click handler is not focusable, is not announced as a control, and does not respond to Space or Enter — a whole class of users simply cannot operate it. - **A timeline is a slider.** It must be reachable by keyboard and adjustable with arrow keys, with a current value a screen reader can read out. `<input type="range">` gives all of that natively. - **Give every control a name.** An icon-only button with no text is nameless to a screen reader. - **Keep the state visible and announced.** A single play/pause toggle has to communicate which state it is currently in, not just change its glyph. - **Provide the caption control.** If the video has `<track>` children, the custom bar owes the user a way to enable and disable them. - **Do not remove focus outlines** in the pursuit of a clean look; keyboard users navigate by them. ## When it is worth it Legitimate reasons exist: consistent branding across browsers, a design that integrates the transport into a larger layout, adaptive streaming that needs a quality selector the native bar has no concept of, or analytics on playback behaviour. Those are real, and mature player libraries exist precisely because the rebuild is substantial. The wrong reason is "the native bar looks different in Safari". Users do not compare browsers side by side, and cross-browser visual identity is rarely worth trading a fully accessible, localised, OS-integrated widget for a partial reimplementation. ## The reviewable version of this question If a pull request removes `controls`, the review checklist is short and concrete: can I operate the player with the keyboard alone; does a screen reader name every control; can I turn captions on and off; is the timeline a real slider; does fullscreen still work on mobile. A custom bar that fails any of those is a regression, however good it looks.
- Do caption tracks stop working when the controls attribute is removed?No. Rendering text-track cues is a media-element behaviour, so a `<track>` marked `default` still paints over the video. What disappears is the browser's captions menu, meaning the user can no longer switch language or turn captions off. A custom bar that omits a caption control can therefore trap someone with permanent on-screen captions.
- Why is a <div> with a click handler an unacceptable play button?It is not in the tab order, it is announced as nothing in particular, and it does not respond to Space or Enter, so keyboard and screen-reader users cannot start the video. A `<button>` provides focusability, keyboard activation and an implicit role at no cost. Reaching for `role` and `tabindex` to patch a `<div>` is rebuilding what the native element already gives you.
- What is a legitimate reason to replace the native control bar?Adaptive streaming that needs a quality or audio-track selector the native bar has no concept of, transport controls that must be integrated into a larger layout, or playback analytics. Cosmetic consistency across browsers is a weak reason — users never see two browsers side by side, and the trade costs keyboard, screen-reader, localisation and OS media-key support.
saying these in an interview costs you the question
- Calling the native control bar just default styling
- Building play buttons from divs with click handlers
- Shipping a custom player with no caption control
- Assuming keyboard support comes for free after restyling
- Ignoring picture-in-picture and OS media keys entirely