Chapter 3 — Media and Embedded Content: Audio, Video and Iframes
Section 1
Media on a web page is not decoration that happens to move or make sound. It is content in its own right, and visitors come to it for reasons that text alone cannot satisfy. A language learner needs to hear pronunciation, a music student needs to hear phrasing, a cook needs to see a technique, and a traveller needs to hear a place described in a voice. When you add audio or video well, you give those visitors a direct route to understanding. When you add it badly, you create a page that is slow, noisy, confusing, or impossible to use with a keyboard or a screen reader. The difference is rarely the media itself. It is the set of choices around it: which element you use, which formats you offer, how much the browser is allowed to download in advance, whether captions are present, and how the player behaves on a small screen.
Modern HTML gives you native elements for this work, which means the browser itself provides the player. You do not need a plug-in, and you do not need to build play, pause, volume, and seeking controls from scratch for a basic player. The browser supplies controls that visitors already recognise, that work with a keyboard, and that adapt to the device. That familiarity is valuable. A visitor who has learned how one audio player works can use yours without instruction, because the buttons look and behave in a similar way. Your job is therefore less about inventing a player and more about choosing sensible defaults, describing the media honestly, and stepping out of the way when the browser can do the job better than custom code.
There is also a responsibility that comes with media, because media is heavier than text. A paragraph costs almost nothing to download. A minute of video can cost far more, especially for a visitor on a mobile connection or a limited data plan. Every decision in this chapter returns to that balance: give the visitor the media they need, in a form they can actually play, without forcing a download they did not ask for, without starting sound they did not request, and without breaking the layout while the file loads. If you keep that balance in mind, the technical details that follow will feel like tools for a clear purpose rather than a list of attributes to memorise.
A useful habit is to ask, before you embed anything, whether media is the right form at all. Sometimes a short written explanation, a diagram, or a link to a longer recording serves the visitor better than an autoplaying clip in the middle of an article. Media earns its place when hearing or seeing changes understanding in a way that reading cannot. A pronunciation guide earns it. A demonstration of a hand movement earns it. A background video that merely repeats the headline does not. Starting from that question will keep your pages lighter, faster, and more respectful of the people who visit them, and it will make the media you do include feel deliberate rather than decorative.
Check: When does audio or video earn its place on a page, rather than text alone?
Section 2
The audio element, written as <audio>, places a sound player on a page. In its simplest useful form it carries a source file and the controls attribute, so the visitor can play, pause, adjust volume, and seek through the recording. A basic example looks like this: <audio controls src="interview.mp3"></audio>. The browser renders a compact player, usually a horizontal bar with a play button, a timeline, a time display, and a volume control, although the exact appearance varies between browsers and devices. That variation is normal. You should not expect every visitor to see the identical player, and you should not try to force an identical appearance with fragile tricks. The important point is that the controls are recognisable and usable wherever they appear.
Audio is often the right choice when the visitor's eyes are busy or when sound itself is the subject. A podcast episode, an interview, a pronunciation drill, a piece of music, a recorded lecture, and a spoken story all belong in an audio player rather than in a video player with a still image pretending to be a film. Using audio also keeps the page lighter than video, because there is no picture track to download, and it lets a visitor listen while doing something else, such as walking or working. That freedom is part of the appeal, and it is also a reason to respect the visitor's control: they should be able to pause, rewind to hear a sentence again, and move on without hunting for a hidden button.
One detail beginners often miss is that an audio element without controls is invisible in most browsers. If you write <audio src="interview.mp3"></audio> and nothing else, there may be no player on the page at all, and the visitor will have no way to start the recording. That behaviour is useful when JavaScript will provide its own controls, a topic for a later chapter, but for ordinary pages it is a trap. If you want people to play the recording, include controls. If you are building a custom player, you must also build accessible controls yourself, including keyboard support and clear labels, because the browser will not supply them for you. For this chapter, the rule is simple: no custom player, no missing controls.
Audio also needs a text alternative, which later sections cover in detail. For now, remember that a recording alone is not enough. A visitor who cannot hear, a visitor in a noisy room, and a visitor searching for a particular sentence all benefit from a transcript or a written summary placed near the player. The audio element itself does not provide that text. You provide it as ordinary page content, clearly linked to the recording, so that the media is useful to everyone, not only to those who can press play and listen in a quiet room.
Check: What happens if you write an audio element without the controls attribute?
Section 3
The video element, written as <video>, places a moving picture player on a page, with sound when the recording has a sound track. Like audio, it becomes usable in its simplest form when you add controls and a source, for example <video controls src="lesson.mp4"></video>. The browser renders a rectangular player with a play button, a timeline, volume, and usually a fullscreen button. The size of that rectangle matters, because video occupies visible space in a way that audio does not. If you give no width, the player will use the intrinsic size of the video file, which may be far too wide for a phone screen or far too small for a desktop layout. You therefore need to think about sizing from the start, a subject Section 12 and Section 13 return to in detail.
Video suits a different kind of learning from audio. It shows sequence, movement, position, and change over time. A dance step, a repair procedure, a laboratory technique, a sign-language phrase, and a tour of a building are all clearer in motion than in still pictures or prose. At the same time, video demands more attention than audio, because the visitor must watch as well as listen, and it demands more data, because each second contains many pictures as well as sound. Those costs mean video should be used where movement genuinely adds meaning. A talking head reading a paragraph that is already printed below the player adds little, while a close-up of hands shaping dough adds a great deal. Judge each video by what the picture contributes, not by how impressive motion feels.
A video element can also carry a poster image, an image shown before playback begins, which gives the visitor a preview and prevents a blank rectangle while the file loads. A good poster is a frame that represents the content honestly: a clear view of the subject, not a misleading still chosen only to attract clicks. The poster is set with the poster attribute, and it is one of the cheapest improvements you can make to a video, because it costs one small image file and makes the player look intentional even before anyone presses play. If the video is decorative in the background sense, which Section 41 discusses, the rules change, but for ordinary content video, a poster is expected.
Finally, remember that video is not just a bigger version of audio. It has captions, visual description, and layout to consider, and visitors may watch it without sound, in a quiet carriage or a library, which means the picture and any captions must carry meaning even when the volume is off. Designing for silent viewing is not an edge case. It is how a large share of real viewing happens, and a video that only makes sense with sound is a video that fails for those viewers. Keep the picture informative, add captions, and do not rely on spoken words alone to explain what is happening on screen.
Check: Why must a video still make sense when watched with the sound off?
Section 4
The source element, written as <source>, sits inside an audio or video element and names one file that the browser may play. Instead of putting a single file in the src attribute of the player itself, you list one or more source elements, each with its own src and type, and the browser works through the list in order, choosing the first file it can play. A video example looks like this: <video controls><source src="lesson.mp4" type="video/mp4"><source src="lesson.webm" type="video/webm"></video>. The order matters, because the browser stops at the first playable file and ignores the rest. Putting your most widely playable file first is therefore a sensible default, with less common alternatives after it.
The type attribute is more useful than it looks. It tells the browser the format of the file without forcing it to download part of the file to find out. Without a type, the browser may need to fetch a portion of each file in turn to test whether it can play it, which wastes time and data, especially on a slow connection. With a correct type, the browser can skip a file it cannot play immediately and move to the next candidate. The type value is a media type, such as audio/mpeg for an MP3 file or video/mp4 for an MP4 file, sometimes with extra detail about the codec, which Section 6 explains. Getting the type right is a small act of respect for the visitor's connection, and it is easy to verify by testing the page and watching which file the browser actually requests.
Source elements also make your intentions clear to other developers. A single src attribute hides the fallback plan, if there is one. A list of source elements shows it openly: here are the files we offer, in this order, for this reason. That clarity matters when a file is replaced, when a format is dropped, or when a new format is added, because the next developer can see the whole strategy without guessing. It also makes testing easier. You can check each file in isolation, confirm that its type is correct, and confirm that the browser falls through to the next file when the first is unavailable, for example by temporarily renaming a file on a test copy of the page.
There is one more use for source elements that is easy to overlook. The text and elements placed after the last source element, inside the player, are fallback content, shown only when the browser cannot play any of the listed files. Section 20 covers fallback in full. For now, note the structure: sources first, fallback last. That order is not a convention you can rearrange at will. The browser reads sources in order, and anything that is not a source element after them is treated as fallback, not as another candidate file. Understanding that reading order prevents the common mistake of placing a download link before the sources and wondering why the browser never reaches the files.
Check: In what order does a browser try the source elements inside a player?
Section 5
Offering more than one format is not a luxury. It is a practical response to the fact that browsers do not all support the same audio and video formats, and that support can vary by device, operating system, and the codecs installed on that device. A format that plays perfectly on one visitor's laptop may refuse to play on another visitor's phone, not because the file is broken, but because that browser does not include the decoder for it. If you offer only that one format, the second visitor gets nothing. If you offer a second format, the browser can fall through to a file it does understand, and the visitor gets the content. That fallback is the whole reason the source element accepts a list.
For audio, the most widely playable format in practice is MP3, encoded as audio/mpeg, and it is a sensible first choice for speech, music, and podcasts. A common second choice is Ogg Vorbis, served as audio/ogg, which is an open format that some browsers and tools prefer. For video, MP4 is the most widely playable container in practice, and WebM is a common second choice. Those names describe containers, not the precise encoding inside them, which is why Section 6 separates containers from codecs. You do not need to master every format on the web. You need a pair that covers the browsers your visitors actually use, and you need to test that pair rather than assuming it works.
The cost of offering two formats is real, and it should be weighed honestly. You must encode, store, and maintain two files instead of one, and if you update the recording, you must update both. For a short clip, that cost is small. For a large library of lessons, it is a genuine maintenance burden, and some teams decide that one widely supported format, plus a clear fallback message and a download link, is a better trade-off than maintaining many formats. That is a legitimate decision, provided it is made deliberately and tested with real visitors. What is not legitimate is offering one format, never testing it elsewhere, and discovering the failure only when a visitor complains. Whatever pair or single format you choose, test it on more than one browser and more than one device before publishing.
Format choice also interacts with quality and file size. A format that compresses speech efficiently may be a poor choice for music, and a format that preserves fine detail may produce a file too large for a mobile visitor. The right question is not which format is best in the abstract, but which combination gives your visitors a playable file at an acceptable quality and size. Start with the widely playable option, add a second format where testing shows a gap, keep the files reasonably compressed, and document which formats you offer so that future updates do not silently drop one of them.
Check: Why might a file that plays on one device fail on another?
Section 6
A media file has two layers that beginners often confuse: the container and the codec. The container is the wrapper, the file format you see in the extension, such as MP4 or WebM for video, or MP3 or Ogg for audio. It holds the picture track, the sound track, captions, and information about the file, packaged together so that a player can find each part. The codec is the method used to compress and decompress the actual picture or sound inside that wrapper. One container can hold picture and sound encoded with different codecs, and the same codec can appear inside different containers. A browser that supports the container but not the codec inside it may still refuse to play the file, which is why naming the container alone is not always enough.
For video, the picture codec decides how each frame is compressed, and the sound codec decides how the audio track is compressed. Two MP4 files can therefore behave differently, because one may use a picture codec the browser understands and the other may use one it does not. The same is true for WebM files. That is why the type attribute on a source element can include codec information in addition to the container type, for example by adding a codecs parameter after the media type. You do not need to memorise every codec name, but you do need to understand that a file extension is a promise about the wrapper, not a guarantee about the contents, and that testing the actual file matters more than trusting the extension.
For audio, the distinction is simpler in practice but still real. An MP3 file uses a particular audio codec by definition, so the container and codec are closely tied. An Ogg file, by contrast, is a container that can hold Vorbis audio or Opus audio, which are different codecs with different strengths. Opus is efficient for speech at low bitrates, while Vorbis is a long-established choice for music. If you offer an Ogg file, knowing which audio codec it contains helps you describe it accurately and helps the browser decide whether it can play it. Again, the practical lesson is to check the file you actually encoded, not the label you assumed it had.
The takeaway for everyday work is modest and useful. Encode your media with widely supported combinations, write the type attribute accurately, offer a second format where testing shows you need one, and test the real files on real browsers. If a file fails, do not assume the container is at fault. Check the codec, check the type, and check whether another file in your source list plays. That systematic checking will solve most playback failures faster than re-encoding blindly or adding a third format in hope. Containers organise, codecs compress, and both must be supported for playback to succeed.
Check: What is the difference between a container and a codec?
Section 7
The controls attribute is the simplest and most important attribute on a media player. Writing <audio controls> or <video controls> tells the browser to show its built-in player interface, with buttons the visitor can recognise and use. Without it, as Section 2 noted for audio, the player may be invisible, and the visitor has no way to start, pause, or seek. Controls are therefore not a styling choice. They are the difference between media a visitor can use and media that merely occupies space on the page. For ordinary content, include controls unless you have a specific, accessible alternative, and test that the controls are visible and reachable on the devices your visitors use.
Built-in controls offer several advantages that are easy to underestimate. They work with a keyboard, so a visitor can tab to the player and use the space bar or arrow keys in the way their browser supports. They work with a screen reader, announcing the player and its buttons in a form the visitor can understand. They include volume and fullscreen controls where appropriate, without extra code. They also behave consistently with the visitor's expectations, because the same browser controls appear on other sites. A custom player can match those qualities, but only with deliberate work: every button needs a label, every action needs a keyboard equivalent, and every state change, such as play turning into pause, needs to be announced. That work is possible, and later chapters may cover it, but it is not free, and it should not be undertaken lightly for a basic player.
Controls also communicate honesty about the media. A player with a visible timeline tells the visitor how long the recording is before they commit to it. A play button tells them that nothing will happen until they choose to start it. A pause button tells them they can stop at any time. Those signals matter, especially for visitors on limited data or in shared spaces, who need to know what they are agreeing to before they press play. Hiding controls, or replacing them with a single ambiguous image that starts playback on click, removes those signals and replaces a clear choice with a guess. The visitor should never have to guess what will happen when they interact with media.
There is one exception worth naming, and it is narrow. A short, silent, looping video used purely as a visual background may not need visible controls, because it is not content the visitor is expected to play or pause in the usual sense. Even then, Section 41 explains why such background video needs care, including a way to pause it for visitors who need reduced motion. For every other case — a lesson, an interview, a song, a demonstration — controls are the default, not an optional extra. If you remember one rule from this chapter, let it be this: if visitors are meant to play it, show them how.
Check: Name three things built-in controls give a visitor that a bare player does not.
Section 8
The preload attribute tells the browser how much of a media file it may download before the visitor presses play. It has three values, and choosing between them is a decision about data, speed, and respect for the visitor's connection. The value none tells the browser not to download anything in advance, not even the file's metadata, until the visitor chooses to play. The value metadata tells the browser it may download just enough to learn the duration, dimensions, and similar basic information, without downloading the media itself. The value auto tells the browser it may download as much as it thinks is sensible, which in practice often means starting to download the file so that playback can begin promptly. Each value is a trade-off, and none is right for every page.
For a page with a single, central recording that most visitors will play, metadata is often a good balance. The player can show the duration, the timeline becomes meaningful, and the page does not spend the visitor's data on a file they may never play. For a page with many recordings, such as a list of podcast episodes or a catalogue of lessons, none is often better, because preloading even metadata for dozens of files can add up, and most visitors will play only one or two. For a short clip that is the main point of the page, and that visitors are very likely to play, auto may be justified, because the delay between pressing play and hearing sound matters, and the file is small enough that early downloading is not wasteful. The key is to match the value to the page, not to copy a single value everywhere.
It is important to understand that preload is a hint, not a command. Browsers may ignore it in some situations, for example when data-saving settings are enabled, when the connection is slow, or when the browser decides that preloading would be wasteful. That flexibility is a feature, not a bug. It means the browser can protect a visitor on a metered connection even when the page author was careless. You should therefore treat preload as advice you give the browser, not as a guarantee you can rely on for timing or behaviour. If your design depends on a file being fully downloaded before a certain moment, preload alone will not guarantee it, and you need a different approach.
Preload also interacts with the poster image for video. A poster gives the visitor something to look at while the file is not yet loaded, so a page using preload="none" does not have to show a blank rectangle. That combination — no early download, plus a clear poster and visible controls — is often the most respectful default for content video. It tells the visitor what the video is about, lets them decide whether to play it, and spends no data until they do. That respect is the thread running through this chapter, and preload is one of the clearest places where it shows.
Check: Which preload value downloads the least before the visitor presses play?
Section 9
Autoplay means that media starts playing on its own, without the visitor pressing play. Browsers restrict autoplay with sound, and they do so for a reason that is easy to appreciate once you imagine the opposite. A page that starts shouting the moment it loads, in an office, a library, or a quiet home, is startling and embarrassing, and a page that starts several sounds at once is unusable. To protect visitors, browsers generally block autoplay when the media has sound and the visitor has not yet interacted with the page. The exact rules vary between browsers and can change over time, and they can also depend on whether the visitor has previously interacted with the site, whether the tab is in the foreground, and whether the device is in a data-saving mode. You should therefore not rely on a precise rule that you read once. You should design as if autoplay with sound is not available, because for a new visitor on a fresh page, it usually is not.
There are forms of autoplay that browsers commonly allow. A video that is muted can often autoplay, because it makes no sound and therefore does not startle anyone. A video that has no sound track at all can often autoplay for the same reason. Those allowances explain why so many sites use silent looping videos as visual backgrounds: they are the form of autoplay that browsers permit. Even then, autoplay is not guaranteed, and a browser may still block it for reasons such as data saving or user settings. A page that depends on a muted video starting automatically should therefore have a graceful fallback, such as a poster image that still communicates the idea when the video does not start. The poster is not decoration in that case. It is the content the visitor sees if autoplay is blocked.
The honest way to use autoplay is to use it only where it serves the visitor and to accept that the visitor may need to start sound themselves. A common pattern is to autoplay a muted preview, and to let the visitor unmute it with a clear control if they want sound. Another pattern is to avoid autoplay entirely for content media, and to let the visitor press play when they are ready. Both patterns respect the visitor's attention. What does not respect it is trying to work around the block with tricks, such as starting sound after a tiny, hidden interaction, or playing sound from a different element that the visitor did not choose. Those workarounds may work briefly, and they will fail as browsers improve their protections, and they will damage trust in the meantime.
For the purposes of this book, the rule is plain. Do not write <video autoplay> or <audio autoplay> for content that has sound and expect it to play. If you need motion on load, use a muted video, provide a poster, and provide controls so the visitor can pause or unmute. If you need sound, wait for the visitor to press play. That approach works in every browser, it respects every visitor, and it will not break when a browser tightens its autoplay rules in future.
Check: Why do browsers generally block autoplay with sound?
Section 10
Several smaller attributes shape how a player behaves once it is on the page, and understanding them prevents a set of common surprises. The loop attribute tells the browser to return to the start when the media ends, and to play again, until the visitor pauses it. That behaviour suits a short demonstration that a visitor may want to watch repeatedly, or a brief ambient sound, but it is a poor choice for a long lecture, because a recording that restarts without warning can confuse a visitor who thought it had finished. Loop should therefore be used deliberately, for short media, and ideally with visible controls so the visitor can stop it. A looping recording without controls is a trap, because there is no obvious way to make it stop.
The muted attribute starts the player with the sound off, while still showing the volume control so the visitor can turn sound on. It is the attribute that makes muted autoplay possible, as Section 9 explained, and it is also useful for a video whose picture matters more than its sound on first viewing. Muted does not mean silent forever. It means silent until the visitor chooses otherwise, which is a respectful default for any media that starts without a press. If you use muted, make sure the unmute control is easy to find, and do not assume the visitor will notice a small speaker icon in a corner. A clear label near the player, such as a note that sound can be turned on, helps visitors who might otherwise watch a demonstration without hearing its explanation.
The playsinline attribute matters mainly on phones, where a video might otherwise jump to fullscreen as soon as it starts playing. Adding playsinline tells the browser that the video may play inside the page, in the space you have given it, rather than taking over the whole screen. That behaviour is usually what you want for a video embedded in an article or a lesson, where the visitor may want to read surrounding text while watching. Without playsinline, a visitor on some phones may be surprised to find themselves in fullscreen mode, with the article hidden, and may need to dismiss the player to return. Browser behaviour here varies, and playsinline is a request rather than a guarantee, but it is a request worth making for inline video.
Together, these attributes show a pattern that runs through media work. Each one answers a question about the visitor's experience: should this repeat, should it start silent, should it stay in the page? Answering those questions explicitly, rather than leaving them to defaults, makes the player behave in a way the visitor can predict. Defaults are not always wrong, but they are not always right for your page either, and a few short attributes are often enough to turn a surprising player into a predictable one.
Check: What does playsinline try to prevent on a phone?
Section 11
The audio and video elements share a family of attributes, but they are not identical, and the differences matter when you move from one to the other. Both accept controls, preload, autoplay, loop, muted, and src or source elements. Both accept fallback content inside the element. Video alone accepts width, height, and poster, because video occupies a visible rectangle and benefits from a preview image. Audio has no rectangle to size and no picture to preview, so those attributes do not apply to it. Keeping that distinction clear prevents the mistake of adding a poster to an audio player and wondering why nothing changes, or adding width to an audio element and wondering why the player does not grow.
Another difference is less visible but equally important. A video player includes a fullscreen control in most browsers, because a visitor may want to watch a demonstration or a lesson at full size. An audio player has no fullscreen concept, because there is nothing to enlarge. Similarly, a video player's timeline is tied to pictures as well as sound, so seeking to a particular time shows a particular frame, while an audio player's timeline is tied only to sound. Those differences sound obvious when stated, but they affect design decisions. A page that places a video in a narrow sidebar, for example, may make the picture too small to be useful, even though the same sidebar would be fine for an audio player. The medium's shape should guide where you place it.
There is also a common misconception about volume. There is no volume attribute in HTML for setting a player's starting volume. Volume is a visitor-controlled setting, adjusted through the player's own controls or the device's volume, and it is not something the page author sets in markup. If you want a recording to start quietly, the honest approach is to encode it at a lower level, or to start it muted and let the visitor unmute it, not to search for a volume attribute that does not exist. JavaScript can adjust volume for a custom player, but that is a separate topic, and it still needs to respect the visitor's own volume preferences. For ordinary markup, volume belongs to the visitor.
Understanding these shared and distinct attributes saves time when you switch between audio and video. You can carry over your knowledge of controls, preload, and source lists directly, and you only need to learn the video-specific ideas of sizing and poster, and the audio-specific idea that the player is compact and sound-only. That transfer is one of the benefits of native elements: they share a vocabulary, so learning one helps you learn the other, and a page that mixes audio and video can use consistent patterns for both.
Check: Name one attribute that video accepts but audio does not, and why.
Section 12
Sizing a video player is a layout decision, not just a number. The width and height attributes on a video element give the player a size in pixels, for example <video controls width="640" height="360">, which describes a player 640 pixels wide and 360 pixels tall. Those numbers also describe the aspect ratio of the player, the relationship between width and height, which in this example is sixteen to nine. Giving both attributes helps the browser reserve the right amount of space before the video file has loaded, so that surrounding content does not jump down the page when the player appears. That reservation matters, because a page that jumps as media loads is disorienting, and a visitor may lose their place or click the wrong thing when content moves under their finger.
Fixed pixel sizes, however, do not adapt to different screens. A player fixed at 640 pixels wide will overflow a phone screen that is only 360 pixels wide, forcing horizontal scrolling or cutting off the controls. A player fixed at a small size will look lost on a wide desktop screen. The solution, covered in the next section, is to use CSS to make the player responsive while keeping its aspect ratio, but the width and height attributes still have a role. They give the browser the ratio to preserve, even when CSS changes the actual width. In other words, the attributes describe the shape, and CSS decides the size on each screen. Keeping both ideas in mind prevents the mistake of removing width and height entirely and then wondering why the page jumps, or keeping them fixed and then wondering why the player breaks on a phone.
For audio, sizing works differently, because the player is a horizontal bar whose width is determined by the browser and the surrounding layout, not by a picture. You do not set a height for an audio player in the same way, and you should not expect it to behave like a video rectangle. If an audio player looks too narrow, the cause is usually the container it sits in, not the audio element itself. Widening the container, or placing the player in a wider part of the layout, is the honest fix. Trying to force an audio player to a particular height with CSS may produce inconsistent results between browsers, because the built-in player is rendered by the browser, not by your stylesheet, and its internal layout is not fully under your control.
The practical rule for sizing is therefore to think in ratios for video and in containers for audio. Give video a width and height that describe its true shape, then let responsive CSS adapt its displayed size. Give audio a sensible container, with room for its controls and timeline, and let the browser render the player inside it. Both approaches share the same goal: a player that fits the screen it is on, reserves its space before it loads, and does not force the visitor to scroll sideways or hunt for controls.
Check: Why give a video both width and height, even if CSS will change its size?
Section 13
Responsive media means media that fits the screen it is on without breaking the layout, without forcing sideways scrolling, and without distorting the picture. The core CSS idea is simple: a video should never be wider than its container, and its height should adjust to preserve its aspect ratio. A common pattern is to set the video's maximum width to the full width of its container and its height to automatic, for example with a rule that says the video may be at most one hundred percent wide and its height adjusts itself. That rule lets a large video shrink to fit a phone screen, while letting the same video display at its natural size on a wider screen, without stretching or squashing the picture. Stretching a video to fill a space of the wrong shape distorts faces and movement, and it should be avoided even when it seems like an easy fix for an awkward layout.
The aspect-ratio property in CSS gives you a more explicit way to state the shape you want, for example sixteen to nine for most modern video, or four to three for older recordings. When you state the ratio, the browser can reserve the correct height even before the video file loads, and it can keep that shape as the width changes. Without a ratio, a browser may initially render the player at a default height, and then resize it when the file's dimensions become known, pushing content below it down the page. With a ratio, the space is correct from the start, and the visitor's reading position is preserved. The ratio should match the actual video, not an ideal you wish it had, because a mismatched ratio will either crop the picture or leave empty bands, depending on how the browser handles it.
Responsive media also means thinking about the container, not just the player. A video inside a narrow column will be narrow, however large the original file is, and a video inside a wide main area will be wide. That is correct behaviour, but it means you should choose where to place a video with its viewing needs in mind. A demonstration that relies on fine detail, such as close-up hand movements or small text on screen, needs a reasonably wide container to be legible. Placing it in a narrow sidebar because space was available there will make it useless, even though it technically fits. Conversely, a simple talking-head video can work in a narrower space, because the picture carries less detail. Placement is therefore part of responsiveness, not an afterthought.
Finally, test responsive media on real widths, not just by imagining them. Shrink the browser window, or use a device mode in your browser's developer tools, and watch what happens to the player at phone width, tablet width, and desktop width. Check that controls remain reachable, that the picture is not distorted, that no sideways scrolling appears, and that surrounding text does not jump when the video loads. Those checks take minutes, and they catch the problems that visitors on phones encounter most often. A video that works at one width and breaks at another is not responsive, however good it looks on the screen you happened to test first.
Check: What goes wrong if a video is stretched to fill a space of the wrong shape?
Section 14
A poster image is the still picture shown in a video player before playback begins, set with the poster attribute, for example <video controls poster="lesson-poster.jpg" src="lesson.mp4">. It serves several purposes at once. It gives the visitor a preview of what the video contains, so they can decide whether to play it. It prevents a blank or black rectangle from sitting in the middle of the article while the file loads, which makes the page look finished rather than broken. And it provides a meaningful image for visitors whose browsers block autoplay or whose connections are too slow to load the video promptly, because the poster remains visible even when the video does not start. A good poster is therefore not decoration. It is the video's first impression, and for some visitors it may be the only impression they get.
Choosing a poster well requires honesty. The best poster is usually a frame from the video itself, showing the subject clearly, in focus, and in a moment that represents the content. A frame of the presenter mid-sentence, a clear view of the object being demonstrated, or the opening scene of a location all work well. A poster that promises something the video does not deliver, such as a dramatic moment from a different recording, or a heavily edited image that misrepresents the subject, misleads the visitor and damages trust. The same honesty applies to text on a poster. If the poster contains words, they should be legible at the size the player will actually display, and they should not be the only place where essential information appears, because a visitor who cannot see the image, or whose image fails to load, will miss that information entirely.
Poster images should also be reasonably small in file size. A poster is meant to load quickly, before the video itself, so a large, uncompressed photograph defeats its purpose by slowing the page. A compressed image at the approximate display size of the player is usually sufficient, and it will look sharp enough for a preview. If the poster is much larger than the player, the browser downloads data the visitor never sees at full resolution. If it is much smaller, it will look blurred when stretched to fill the player. Matching the poster to the player's displayed size is a small optimisation, but it is the kind that adds up across a page with several videos, and it shows the same respect for data that the preload attribute shows.
There is one situation where a poster matters even more than usual. When a video uses preload none, the browser downloads nothing in advance, so without a poster the player may appear empty until the visitor presses play. With a poster, the player looks complete and inviting, even though no video data has been downloaded. That combination is a good default for content video on a page with several recordings. It gives the visitor information, it gives the page a finished appearance, and it spends almost no data until the visitor decides to watch. A poster is a small file with a large effect, and it should be part of every content video you publish.
Check: Why is a poster especially important when preload is set to none?
Section 15
Captions and subtitles are text versions of the spoken words and important sounds in a video, displayed in time with the picture, and they are provided with the track element inside the video element. A track element points to a timed-text file, usually in WebVTT format, and describes its kind, language, and label, for example <track kind="captions" src="lesson-en.vtt" srclang="en" label="English">. The browser reads that file, shows the text at the times specified in it, and offers the visitor a control to turn captions on or off. That control matters, because captions are a visitor preference, not a page author's decision. Some visitors need captions always, some want them only in a noisy room, and some prefer them off. The browser's captions control respects all three preferences, provided you supply the track in the first place.
The distinction between captions and subtitles is worth learning precisely, because the two words are often used interchangeably, and they mean different things in accessibility work. Captions are written for visitors who cannot hear the audio, so they include not only spoken words but also important non-speech sounds, such as music, a door closing, or a phone ringing, when those sounds matter to understanding. Subtitles are traditionally written for visitors who can hear but do not understand the spoken language, so they translate the spoken words into another language, and they do not usually describe sounds. In HTML, the track element's kind attribute distinguishes them: kind captions for captions, kind subtitles for translated subtitles. Using the right kind helps browsers and assistive technology treat the track correctly, and it helps visitors choose the track they need.
Providing captions is not an optional polish. It is how a video becomes usable for visitors who are deaf or hard of hearing, for visitors in noisy or quiet environments, for visitors learning the language, and for visitors searching for a particular sentence. A video without captions excludes the first group entirely, and it inconveniences the others. The effort of writing captions is real, especially for a long recording, but it is also an opportunity to check the recording itself. Writing out what was said often reveals unclear explanations, repeated phrases, or errors that can be fixed in the transcript as well as in the captions. Captions therefore improve the content for everyone, not only for those who depend on them.
A practical habit is to plan captions at the same time as you plan the recording, not as an afterthought once the video is published. If you write a script before recording, that script is the starting point for captions. If you record without a script, transcribe the recording promptly, while the content is fresh, and time the text to the speech. Do not rely on automatically generated captions without checking them, because errors in names, technical terms, and numbers are common, and an unchecked caption can mislead a visitor more than no caption at all. Captions are part of the video, not an accessory to it, and they deserve the same care as the picture and sound.
Check: What extra information do captions include that subtitles usually do not?
Section 16
The track element can carry several kinds of timed text, and each kind has a distinct purpose. The kind attribute accepts captions, subtitles, descriptions, chapters, and metadata, and choosing the right kind tells the browser and the visitor what the track is for. Captions, covered in the previous section, are for visitors who cannot hear. Subtitles translate spoken words into another language. Descriptions provide a text description of important visual information, for use by screen readers or by tools that can speak the description at appropriate moments. Chapters divide a recording into named sections, so a visitor can jump to a particular part, such as a specific step in a tutorial. Metadata carries timed information for scripts to use, rather than text for visitors to read directly. Each kind serves a different need, and a single video may carry several tracks of different kinds.
Chapters deserve special attention, because they transform a long recording from a single timeline into a navigable structure. A forty-minute lesson without chapters forces a visitor to drag a timeline blindly to find the section they need. The same lesson with chapters lets them jump to "Preparing the ingredients", "Mixing", or "Baking" directly, which is a far better experience for revision and reference. Chapters are written in the same timed-text format as captions, with start and end times and a title for each section, but they are marked with kind chapters, so the browser knows they are navigation, not dialogue. Not every browser displays chapters in the same way, and behaviour varies, so you should test how your chapters appear, and you should not rely on chapters as the only way to navigate a long recording. A written list of sections near the player, with time references, is a useful companion.
Descriptions are less familiar to many authors, but they matter for visitors who cannot see the picture. A description track can describe actions, settings, and visual information that is not conveyed by dialogue, such as "She picks up the red wire" during a silent demonstration. The browser or assistive technology can use that track to provide the description at the right moment, although support and presentation vary. Even when a description track is not fully supported, writing a description forces you to think about what a visitor who cannot see would miss, and that thinking often leads to a better audio explanation in the recording itself, or to a written summary alongside the player. The track is a tool, but the thinking behind it is valuable even when the tool is limited.
Metadata tracks are different again, because they are not meant to be read by visitors. They carry timed data that JavaScript can respond to, such as showing a related diagram when a particular topic begins. That use belongs to a later chapter on scripting, and it is mentioned here only so that you recognise the kind when you meet it and do not confuse it with a captions track. For ordinary publishing, captions, subtitles, and chapters are the kinds you will use most often. Learn those three well, add descriptions where visual information matters, and leave metadata until you have a scripting reason to need it.
Check: How do chapters change the experience of watching a long lesson?
Section 17
A WebVTT file, with the extension .vtt, is a plain text file that contains timed captions, subtitles, chapters, or descriptions. It begins with the line WEBVTT, followed by blank lines and cues, each cue giving a start time, an end time, and the text to display during that interval. A simple example looks like this: a header line, then a cue such as "00:00:01.000 --> 00:00:04.000" followed by the words spoken in those three seconds. The times use hours, minutes, seconds, and milliseconds, separated by colons and a full stop, and the arrow between start and end times is two hyphens and a greater-than sign. The format is deliberately readable, so a human can write and check it without special software, although captioning tools can generate it more quickly for long recordings.
Writing good cues is a skill distinct from writing good prose. Each cue should contain a short, readable chunk of speech, usually one or two lines, that a visitor can read in the time it is on screen. A cue that contains a whole paragraph forces the visitor to read quickly, and a cue that splits a sentence awkwardly in the middle of a phrase forces them to hold the first half in mind while waiting for the second. A useful guide is to break cues at natural pauses in speech, such as the end of a clause or a sentence, and to keep each cue short enough to be read comfortably before it disappears. That guide is not a strict rule, because speech varies, but it is a good starting point, and it can be refined by watching the captioned video yourself and noticing where you feel rushed.
Timing accuracy matters as much as wording. A caption that appears noticeably before or after the words are spoken is distracting, and a caption that stays on screen long after the speaker has moved on can confuse a visitor about which words belong to which moment. When you write or check a VTT file, play the video with captions on, and watch for drift, especially after edits. If a section of the recording was cut or rearranged, the times after that point may all be wrong, and they need to be corrected. Captioning tools that let you adjust times while watching are helpful here, but even a text editor and a careful viewing pass will catch the worst errors. The goal is synchronisation that feels natural, where the text and the speech arrive together.
Finally, a VTT file is a text file, and it should be treated like any other content file: saved in the correct encoding, given a clear name that includes the language, and linked with the correct srclang and label on its track element. A file named captions.vtt is less helpful than lesson-en.vtt when a page later gains a second language, and a track without a label leaves the visitor guessing which language they are selecting. Small naming and labelling habits, applied consistently, prevent a tangle of untracked files that is difficult to maintain when a video is updated or translated.
Check: What two things does each cue in a VTT file need, besides the text itself?
Section 18
When a video offers tracks in more than one language, or both captions and subtitles, the track element's attributes become the visitor's guide to choosing between them. The srclang attribute gives the language of the track, using a language code such as en for English or fr for French. The label attribute gives a human-readable name for the track, such as "English" or "Français", which the browser shows in its captions menu. The default attribute, when present on one track, tells the browser that this track should be turned on by default, if the visitor's settings allow it. Only one track should be marked as default, and it should usually be the captions track in the video's main language, not a translated subtitle, because captions serve the visitors who need text most urgently. The browser may still respect a visitor's own language or captions preferences over your default, which is correct behaviour.
The difference between a track being available and a track being turned on is important. Availability means the visitor can choose it from the player's menu. Default means the browser will enable it without the visitor having to find the menu, subject to their settings. For a video whose main audience needs captions, marking the captions track as default removes a barrier. For a video whose audience is mixed, leaving tracks available but not default may be more respectful, because some visitors prefer to watch without text. There is no single correct answer for every video. The question to ask is who the video is for, and what that audience most likely needs on first viewing, while remembering that any visitor can change the setting with one control.
Language codes for tracks follow the same system as the lang attribute on a page, covered in Chapter 2, and accuracy matters for the same reasons. A track labelled English but containing French text will mislead a visitor who selects it, and a screen reader or browser that relies on the code to match the visitor's language preference will make the wrong match. If you offer a track in Nigerian Pidgin, Hausa, Yoruba, or Igbo, use the correct code for that language, and write the label in a form the audience will recognise. Do not guess a code. Look it up, and test that the track appears in the player's menu under the label you intended.
Testing tracks is a step that is often skipped, and it is the step that catches most errors. Open the page, start the video, open the captions menu, and check that each track appears with the right label, that selecting it shows the right text, and that the default track behaves as you intended. Check also that a track file that fails to load does not break the video itself. The video should still play, with captions unavailable, rather than failing entirely. That graceful behaviour is one of the strengths of the track element: a missing captions file is a loss, but it should not be a catastrophe. Test for it, and you will know before your visitors do.
Check: What does marking a track as default do, and what does it not guarantee?
Section 19
A transcript is a complete written version of a recording's spoken words, and often of its important sounds and visual information, presented as ordinary text on or near the page. It is related to captions, but it is not the same thing. Captions appear in time with the video, a few words at a time, and disappear as the recording proceeds. A transcript stays on the page, where a visitor can read it at their own pace, search it, copy a quotation from it, or jump to a particular section. That permanence makes transcripts valuable for a different set of needs: revision, reference, translation, and searching. A student revising for an exam can scan a transcript faster than they can rewatch a lesson. A visitor who missed a name or a number can find it in the transcript without scrubbing through a timeline.
Transcripts also serve visitors who cannot play the media at all. A visitor on a very slow connection, a visitor whose device cannot play the format, and a visitor who prefers reading to listening can all use a transcript, while captions alone would not help them, because captions require the video to play. For that reason, a transcript should be available as a page in its own right or as a clearly labelled section near the player, not hidden behind a control that only appears during playback. A link reading "Read the transcript" near the player, leading to a full text version, is a clear and honest pattern. Hiding the transcript in a tooltip or in a file that only opens in a separate application is less helpful, because it adds steps between the visitor and the content they need.
Writing a transcript well is similar to writing captions well, with a few differences. A transcript can include speaker labels, such as "Interviewer:" and "Guest:", which captions may omit for brevity. It can include descriptions of important sounds in brackets, such as "[music fades]" or "[applause]", where those sounds matter. It can include headings for sections, which make a long transcript navigable. What it should not do is silently edit the recording into a different message. A transcript should represent what was actually said, with obvious false starts and repetitions cleaned only where that cleaning does not change meaning, and with any edits clearly noted. A transcript that invents a clearer argument than the speaker actually made is misleading, however readable it may be.
For audio, transcripts are even more important than for video, because audio has no picture to fall back on. A podcast episode without a transcript is inaccessible to a visitor who cannot hear, and it is unsearchable for everyone else. Providing a transcript for audio is therefore not an extra. It is the text equivalent that makes the audio part of the searchable, readable web. If you publish audio regularly, make transcripts part of your production routine, in the same way that you make recording and editing part of it, and your archive will become more useful over time, not just more numerous.
Check: How does a transcript help a visitor differently from captions?
Section 20
Fallback content is the material placed inside an audio or video element, after the source elements, for browsers that cannot play any of the files offered. In older browsers, that fallback was essential, because native media support was not universal. Today, most modern browsers support audio and video, so fallback is less often seen, but it still matters, because a browser may fail to play a file for reasons other than age: an unsupported codec, a corrupted file, a network error, or a device with limited media support can all leave a visitor with a player that cannot play. Fallback gives that visitor something useful instead of a silent, empty rectangle. A simple fallback is a paragraph explaining the situation and offering a download link, for example text that says the browser cannot play the recording, followed by a link to download the file directly.
The structure of fallback is worth stating clearly. Inside the player element, after all source elements, you place ordinary HTML content. The browser will show that content only if it cannot play any source. If the browser can play a source, it will show the player and ignore the fallback. That conditional display is automatic. You do not need JavaScript to show or hide it, and you should not try to replicate it with scripting for basic cases. The fallback is therefore a safety net that costs little to add and that activates only when it is needed. A common mistake is to place fallback content before the source elements, or outside the player element entirely, in which case it will either be ignored as a source or shown always, neither of which is the intended behaviour. Sources first, fallback last, inside the player, is the pattern to memorise.
Fallback should be useful, not merely apologetic. A message that says "Your browser does not support this" and offers nothing else leaves the visitor stranded. A message that says the recording cannot be played here, offers a download link, and points to a transcript, gives the visitor two alternative routes to the same content. For a video, the fallback might also include a poster image or a summary of what the video shows, so that a visitor who cannot play it still learns something. The principle is the same as for other forms of progressive enhancement, which later chapters explore: the core content should be reachable by more than one route, so that a single failure does not block it entirely.
It is also worth testing fallback, even though you may never see it in your own browser. You can test it by temporarily using a file format your browser does not support, or by pointing a source at a missing file on a test page, and observing what appears. That test reveals whether your fallback text is clear, whether the download link works, and whether the transcript link is present. A fallback that has never been tested is a promise you have not verified, and media failures are precisely the moments when a visitor most needs a verified alternative. Test it once, and you will trust it thereafter.
Check: Where inside a player element does fallback content belong?
Section 21
Audio players are often used for long-form listening, such as podcasts, lectures, interviews, and audiobooks, and long-form listening has needs that a short clip does not. A visitor may listen over several sessions, may want to return to a particular point, and may want to know how long the recording is before starting. The native player helps with those needs by showing duration and a timeline, and by allowing seeking, but you can help further with the surrounding page. A clear title, a short description of what the episode covers, a list of topics with approximate times, and a transcript all help a visitor decide whether to commit to a long recording and help them find their place when they return. Those surrounding details are part of the audio experience, even though they are not part of the audio element itself.
Chapter markers for audio work in a similar way to chapters for video, although HTML does not provide a native audio-chapter control in the same form. A practical substitute is a written list of sections near the player, with time references that a visitor can use to seek manually. For example, a lecture page might list "Introduction — 0:00", "Main argument — 12:30", and "Questions — 38:00". That list is simple, it works in every browser, and it does not depend on a feature that may vary. It also benefits visitors using a transcript, who can match a section heading to a time in the recording. The lesson is general: when a native feature is limited or variable, a clear written companion often serves visitors better than a clever workaround that works only in one browser.
Long audio also raises a data question. A one-hour recording at a reasonable quality can be a large file, and a visitor on a mobile connection may not want to download it all at once. Preload none, as discussed in Section 8, is a respectful choice for a list of long episodes, because it avoids downloading files the visitor may never play. For a single featured episode, preload metadata lets the player show its duration without downloading the whole file. Either way, the visitor should be able to see the file size or duration before playing, if you can provide that information honestly, so that they can decide whether to listen now, download for later, or wait for a better connection. That decision belongs to the visitor, and the page should give them the facts to make it.
Finally, long-form audio benefits from a download option. Some visitors prefer to download an episode and listen offline, in an application of their choice, rather than streaming it in a browser. Offering a download link alongside the player, clearly labelled with the format, respects that preference and does not undermine the player. It simply gives the visitor another route to the same content, which is the same principle as fallback in Section 20. A page that offers streaming, a transcript, and a download is a page that trusts its visitors to choose how they listen, and that trust is returned in longer, more satisfied listening.
Check: What surrounding information helps a visitor commit to a long audio recording?
Section 22
Video is widely used for teaching, and teaching video has its own design needs. A lesson video should be structured so that a visitor can follow the argument, pause to try a step, and return to a particular point without rewatching the whole recording. That structure begins before recording, with a plan that divides the lesson into sections, each with a clear purpose. It continues in the player, with chapters or a written section list, as described earlier. And it continues on the page, with written steps, diagrams, or code that accompany the video, so that a visitor who learns better by reading can follow the same lesson without watching every second. Video and text should support each other, not duplicate each other word for word, because a visitor who can read the whole lesson does not need to watch it, and a visitor who watches it does not need a transcript that merely repeats the narration without adding structure.
Length is a teaching decision, not just a production detail. A short video that teaches one idea well is often more useful than a long video that teaches five ideas hurriedly, because the visitor can watch it, practise, and return for the next idea when ready. If a topic genuinely needs a long video, dividing it into a series of shorter videos, each with its own title and description, is usually better than publishing a single, unbroken recording. Short videos are easier to update, easier to caption, easier to search, and easier to reuse in a different course. They also respect the visitor's time, because a visitor who needs only the third idea does not have to sit through the first two to reach it. That modular approach is a habit worth forming early in any teaching project.
Visual clarity matters more in teaching video than in many other kinds of video. Text on screen should be large enough to read at the player's actual display size, not just on the editor's large monitor. Hand movements, tool positions, and screen recordings should be framed so that the important detail is visible, not hidden in a corner or obscured by a presenter's hand. If the lesson involves a screen, such as a code editor, the recording should be at a resolution and size that keeps that screen legible, and the player should be wide enough on the page to show it. Testing the finished video at phone width, as Section 13 recommends, will reveal whether small text becomes illegible, and that test should happen before publication, not after visitors complain.
Finally, a teaching video needs a way for the visitor to ask questions or to practise. A video alone is a lecture, not a lesson. Pairing it with a short exercise, a set of questions, or a prompt to try a step and compare results turns watching into learning. That pairing does not need to be complex. A few sentences below the player, asking the visitor to pause and attempt a task, can transform a passive viewing into an active one. The video provides the demonstration. The page provides the practice. Together, they teach in a way that neither could alone, which is the point of embedding video in a learning page in the first place.
Check: Why is a series of short lesson videos often better than one long video?
Section 23
An iframe, written as <iframe>, embeds another page inside the current page, in a rectangular frame that behaves like a window onto that other page. The embedded page can be a video from a video site, a map, a document, a form, or another web page entirely, and it is displayed inside your page while remaining a separate document with its own address, styles, and scripts. A basic iframe looks like this: <iframe src="https://example.com/page" title="Description of the embedded page"></iframe>. The src attribute gives the address of the embedded page, and the title attribute describes it for visitors who cannot see it, which is essential for accessibility, as Section 24 explains in detail. Without a title, a screen reader user may hear only "frame" with no indication of what it contains.
Iframes are powerful because they let you include content you do not host and cannot easily reproduce, such as an interactive map that updates with live data, or a video hosted on a platform with its own player. They are also risky for the same reason, because the embedded page is not under your control. It can change, it can break, it can load slowly, and it can include its own tracking or advertising that you did not choose. Embedding therefore requires judgement. You should embed content from sources you trust, for reasons that serve your visitors, and you should understand the safety controls that limit what the embedded page can do, which Sections 25 and 26 cover. Embedding everything you find interesting, without that judgement, turns your page into a collection of other sites' problems.
It is important to understand that an iframe is not the same as a link. A link sends the visitor to another page when they choose to go there. An iframe brings that other page into your page immediately, whether the visitor asked for it or not, and it loads its resources as part of your page's load. That immediacy has costs in performance and privacy, because the embedded page may set cookies, load scripts, and request data even before the visitor interacts with it. Lazy loading, covered in Section 33, can reduce that cost by delaying the iframe until it is near the viewport, but it does not remove the need to ask whether the embed is necessary. If a link would serve the visitor just as well, a link is the lighter, more respectful choice.
A final distinction helps to keep iframes in perspective. Native audio and video, covered earlier in this chapter, are media you host and control, with players the browser provides. Iframes are windows onto pages you do not control, with players and interfaces provided by the other site. Both have their place, and this chapter teaches both, but they should not be confused. Choose native media when you have the file and want a simple, accessible player. Choose an iframe when the content is genuinely interactive, hosted elsewhere, or available only through another site's embed, and when you have applied the safety and accessibility measures that make that embed responsible.
Check: How is an iframe different from an ordinary link to another page?
Section 24
Every iframe needs a title attribute that describes the embedded content in plain words, because the title is how visitors who cannot see the frame learn what it contains. A screen reader announces an iframe by its title, allowing the user to decide whether to enter the frame, skip it, or return to the main page. Without a title, the announcement may be empty or may use the frame's address, which is often a long string of characters that tells the visitor nothing useful. A good title names the content and its source in a short phrase, such as "Map showing the location of Kelick Tech Hub" or "Video: How to shape bread dough". A poor title repeats the word frame, or uses a generic phrase such as "Embedded content", which tells the visitor that something is embedded but not what it is or whether it matters to them.
The title should be written for the visitor, not for the developer. It should answer the question "What will I find if I enter this frame?" in the same way that link text answers "Where will I go if I follow this link?" That parallel is useful, because the same honesty applies. Link text that says "click here" fails because it does not describe the destination. An iframe title that says "iframe" fails for the same reason. Both leave a visitor who navigates by text alone without the information they need to make a choice. Writing a specific title takes seconds, and it transforms the frame from an anonymous box into a named part of the page that a visitor can understand and navigate.
Titles also help sighted visitors in indirect ways. A browser may show the title as a tooltip, and search tools and accessibility checkers use it to understand the page's structure. More importantly, the discipline of writing a title forces you to decide what the frame is for. If you cannot write a clear title for an embed, that may be a sign that the embed itself is unclear, or that it does not belong on the page. A map with a vague title may be a map whose purpose has not been thought through. A video with a vague title may be a video that was added because it was available, not because it serves the article. The title is therefore not just an accessibility label. It is a test of purpose, and passing that test makes the page better for everyone.
There is a related attribute worth knowing, although it is not a substitute for a title. The name attribute on an iframe gives the frame a name that links and scripts can target, for example to load a new page into the same frame. That name is a technical identifier, not a description, and it should not be confused with the title. A frame can have both a name for targeting and a title for description, and they serve different audiences: the name serves code, the title serves people. When in doubt, prioritise the title, because a frame that code can target but people cannot understand is a frame that has been built backwards. Title first, name only if you have a targeting reason to need it.
Check: What should an iframe title tell a screen reader user?
Section 25
The sandbox attribute is a safety control for iframes. When you add sandbox to an iframe, with no value, the browser applies a set of restrictions to the embedded page, treating it as if it came from a special, untrusted origin. In that restricted state, the embedded page cannot run scripts, cannot submit forms, cannot open pop-ups, cannot navigate the top-level page, and cannot access storage or other powerful features, unless you explicitly allow a particular capability by adding its name to the sandbox value. For example, sandbox with the value "allow-scripts" permits scripts, but still blocks other capabilities unless they are also listed. That allowlist approach is deliberately strict: everything is blocked by default, and you open only the doors you need, one by one.
Sandbox is valuable because it lets you embed content from a source you do not fully control while limiting the harm it can do if that content is compromised or misbehaves. An embedded page that tries to redirect your visitor to another site, for example, will be blocked if you have not allowed top-level navigation. An embedded page that tries to submit a form without the visitor's knowledge will be blocked if you have not allowed forms. Those blocks protect your visitors even when you cannot vouch for every line of code in the embedded page, which is the normal situation for third-party embeds. Sandbox does not make an untrustworthy source trustworthy, but it reduces the damage an untrustworthy source can cause, and that reduction is worth having.
Using sandbox well requires understanding what the embedded content actually needs. A simple embedded document that only displays text and images may work fully sandboxed, with no allowances at all. An interactive map or video player will usually need scripts, so allow-scripts is often necessary, and it may also need same-origin access if it loads resources from its own origin in a way that sandbox would otherwise block. A form embedded in a frame will need allow-forms. Each allowance should be added only after you have tested that the embed fails without it, and you should be able to explain, in a sentence, why that allowance is necessary. Adding every allowance at once, in the hope that the embed will work, defeats the purpose of sandbox, because a frame with all capabilities allowed is barely more restricted than a frame without sandbox at all.
There is a subtlety about sandbox and same-origin access that beginners should note. The value allow-same-origin, when combined with allow-scripts, can allow an embedded page from your own site to remove its own sandbox restrictions, which is a known risk that documentation warns about. For that reason, you should be especially careful when sandboxing content from your own origin, and you should not combine those two values casually. For third-party embeds, the risk is different, but the principle is the same: allow only what the embed demonstrably needs, test the result, and document the allowances you chose, so that a future developer does not add more in a hurry without understanding why the current list is short.
Check: What does a sandbox attribute with no value block by default?
Section 26
The allow attribute on an iframe, also known as the permissions policy for the frame, controls which powerful browser features the embedded page may use. It lists features such as camera, microphone, geolocation, fullscreen, and autoplay, and it states, for each feature, whether the embedded page may use it. For example, an allow value might permit fullscreen but not camera or microphone, which is appropriate for a video player that needs fullscreen but has no reason to access the visitor's camera. The syntax lists features separated by semicolons, and each feature can be followed by a value indicating which origins may use it, although for many embeds the simple form, listing the feature alone, is sufficient to indicate that the embedded page itself may use it. The exact features and syntax have evolved, and behaviour can vary between browsers, so you should check current documentation for the feature you need rather than copying an old example blindly.
Allow matters because embedded pages, by default, may inherit permissions that your page has, or may request features that have nothing to do with their purpose. A map embed has a legitimate reason to request geolocation, if it centres on the visitor's location, but it has no reason to request the microphone. A video player has a legitimate reason to request fullscreen and possibly autoplay, but it has no reason to request the camera. By writing an explicit allow list, you state the embed's needs openly, and you prevent the embedded page from using features you did not intend it to use. That explicitness is similar to sandbox, but it operates on a different layer: sandbox restricts what the frame can do in general, while allow restricts which device and browser features it can access. Using both, thoughtfully, gives you two layers of control.
A common mistake is to copy an allow list from an embed code snippet without reading it. Video and map providers often supply embed code that includes a generous allow list, designed to make their embed work in as many situations as possible, including features your page does not need. Copying that list unchanged may grant the embedded page access to features that are irrelevant to your use, such as picture-in-picture or clipboard access, without you realising it. The responsible approach is to read the list, remove features you do not need, test the embed, and add back only those features whose absence breaks a function your visitors actually use. That review takes minutes, and it turns a copied snippet into a deliberate choice.
There is also a relationship between allow and autoplay to note. Some browsers require the autoplay feature to be allowed in the iframe's allow list before a video inside the frame can autoplay, even if it is muted. If an embedded video that should autoplay does not start, checking the allow list is a sensible step, alongside checking the autoplay rules in Section 9. As with other media behaviour, the rules can vary, and testing in the browsers your visitors use is more reliable than assuming a copied example will work everywhere. Allow is a small attribute with a large effect on privacy and safety, and it deserves the same attention as the source address itself.
Check: Why should you read an embed provider's allow list instead of copying it unchanged?
Section 27
Two further iframe attributes affect privacy and behaviour in ways that are easy to overlook. The referrerpolicy attribute controls how much information about the referring page is sent to the embedded page when the frame loads. By default, a browser may send the full address of your page as the referrer, which can reveal the page your visitor was on, including any query information in its address. Setting a stricter referrer policy, such as no-referrer or strict-origin-when-cross-origin, reduces that disclosure, sending either nothing or only the origin, which is the site's domain without the specific page path. Which policy is right depends on the embed and on your privacy stance, but the important point is that the default is not neutral. It discloses information, and you should choose a policy deliberately rather than accepting the default without thought.
The loading attribute, which Section 33 covers for performance, also has a privacy dimension, because delaying an iframe until it is near the viewport means the embedded page is not loaded, and does not receive information, until the visitor is likely to see it. That delay is a privacy benefit as well as a performance benefit, because it avoids sending data to a third party for content the visitor may never scroll to. Together, referrerpolicy and loading show that iframe attributes are not just technical details. They are statements about how much you are willing to share with a third party on your visitors' behalf, and they should be chosen with that responsibility in mind, not left at defaults because the embed code supplied them.
Another attribute worth knowing is the credentialless concept and the related sandbox values, although support and details vary, and you should check current documentation before relying on them. The general idea is that some embeds can be loaded without sharing the visitor's credentials or storage with the embedded page, which reduces tracking. That idea is part of a broader shift towards embeds that are less invasive by default, and it is worth watching as browsers evolve. For now, the practical lesson is to keep your embeds minimal: use sandbox, use an explicit allow list, choose a referrer policy, and use lazy loading where appropriate. Those four steps, applied consistently, make most embeds substantially safer and more private than a copied snippet with no attributes at all.
It is also worth noting what these attributes cannot do. They cannot make a malicious embed safe, they cannot prevent the embedded page from recording that it was loaded, and they cannot control what the embedded page does with data it legitimately receives, such as a location the visitor deliberately shares with a map. Safety attributes limit the frame's capabilities, but they do not replace the judgement involved in choosing a trustworthy source. If you would not trust a provider with your visitors' attention, you should not embed their content, however many attributes you add. Attributes are a seatbelt, not a substitute for a safe driver, and both are needed for a responsible embed.
Check: What information can a default referrer policy disclose to an embedded page?
Section 28
Some sites refuse to be embedded, and understanding why prevents a frustrating search for a code error that does not exist. A site can instruct browsers not to display it inside a frame on another site, using a response header that either forbids framing entirely or permits it only on specified origins. Two mechanisms are commonly used for this: the X-Frame-Options header, an older mechanism, and the frame-ancestors directive of Content Security Policy, a newer and more flexible mechanism. When a site sends one of these headers, a browser that respects it will refuse to load the site in your iframe, and will typically show a blank frame or an error message instead. That refusal is not a bug in your code. It is the site owner exercising control over where their content appears.
Sites refuse embedding for several legitimate reasons. A bank, a webmail service, or any site that handles private data may refuse framing to prevent clickjacking, an attack in which a malicious page frames a legitimate site and tricks a visitor into clicking something they cannot see, such as a button hidden under a transparent layer. A news site or a video platform may refuse framing to protect its advertising, its analytics, or its terms of use, or to ensure that visitors experience its content in its own context, with its own navigation and controls. A site may also permit framing only on its own pages, so that it can be embedded in its own site but not elsewhere. Those reasons are not obstacles to work around. They are decisions by the site owner, and respecting them is part of responsible embedding.
When you meet a refusal, the first step is to confirm that refusal is the cause. Open the embedded address directly in a browser tab. If it loads there but not in your frame, and your browser's developer tools show a framing-related message, you have your answer. The second step is to check whether the site offers an official embed version, which is often a different address designed for framing, with its own embed code. Many video and map providers offer such a version, and using it is both permitted and more reliable than framing the ordinary page. The third step, if no official embed exists, is to link to the site instead of framing it. A clear link, with descriptive text, gives the visitor access to the content without violating the site owner's framing decision, and it is often a better experience anyway, because the visitor sees the content in its intended context.
Attempts to bypass a framing refusal, such as fetching the site's content through a proxy and displaying it as if it were your own, should be avoided. Such bypasses may violate the site's terms, may break when the site changes, and may expose your visitors to content you have not vetted. They also undermine the security purpose of the header, which exists to protect visitors from clickjacking. The honest response to a refusal is to accept it, to use an official embed if one exists, or to link instead. That response is slower than a workaround, but it is the response that respects both the site owner and your visitors, and it will not break when the site updates its headers.
Check: What is clickjacking, in plain words?
Section 29
Embedding a video from a video platform is one of the most common uses of an iframe, and it deserves care because the embed brings the platform's player, its branding, its recommendations, and its data practices into your page. Most platforms provide an official embed code, which is an iframe pointing to a special embed address, with a title, dimensions, and an allow list. Using that official code is the starting point, but it should not be the end of your review. Read the code, add a descriptive title if the supplied title is generic, review the allow list as Section 26 advises, consider sandbox restrictions where the platform's documentation permits them, and set loading to lazy if the video is not at the top of the page. Those reviews turn a copied snippet into a deliberate embed.
Privacy is a particular concern with video embeds, because the platform may set cookies and record viewing even before the visitor presses play, depending on how the embed loads. Some platforms offer a privacy-enhanced embed address, which is designed to reduce tracking, for example by not setting certain cookies until the visitor interacts with the player. Where such an option exists and is documented by the platform, it is worth considering. The details of what a privacy-enhanced embed does and does not do are defined by the platform, not by HTML, so you should read the platform's own description rather than assuming it makes the embed fully private. Even a privacy-enhanced embed still loads code from the platform, and it still reveals that your page was visited to that platform when the frame loads.
A related decision is whether to embed at all, or to link to the video and host a native version yourself. If you have the rights to the video and a file you can host, a native video element, as covered earlier, gives you more control, fewer third-party requests, and a simpler accessibility story, because you control the captions and the player. If you do not have the rights, or if the video is hosted only on the platform, an iframe embed with the platform's permission is the honest route. Do not download a platform video and re-host it without permission, because that may violate the creator's rights and the platform's terms, even if it is technically easy. Embedding with permission respects the creator, while re-hosting without permission does not, and that distinction matters more than the technical convenience of either approach.
Finally, test a video embed as a visitor would experience it. Check that it plays, that captions are available if the platform provides them, that fullscreen works, that the player does not autoplay with sound, and that the frame has a sensible size on a phone. Check also what appears if the platform is blocked or slow, because a page whose main content is an embed that fails to load leaves the visitor with nothing. A short written summary of the video, placed near the embed, ensures that the page still communicates its point even when the embed does not load, and it helps visitors who prefer reading to watching. An embed should enhance a page, not be the page.
Check: Why might a native video be preferable to a platform embed, when you have the rights?
Section 30
Embedding a map is a common and useful iframe use, because an interactive map lets a visitor explore a location, zoom in, find directions, and see nearby places in a way that a static picture cannot. Map providers typically offer an embed code, which is an iframe pointing to a map view with a particular centre, zoom level, and sometimes markers for specific places. Using that code is the starting point, and the same reviews apply as for video embeds: add a descriptive title, review the allow list, consider lazy loading, and ensure the frame has a responsive size, as Section 32 explains. A map that is too small to read, or that forces sideways scrolling on a phone, is not helpful, however accurate its data may be.
A map embed also needs a text alternative, because a map is visual information that a visitor who cannot see it, or whose map fails to load, cannot use. That alternative should include the essential information the map conveys: the address, in written form, directions or landmarks that help a visitor find the place, and any other details that the map was meant to communicate, such as opening hours or the nearest transport stop. A visitor who reads the address and directions can reach the place even if the map never loads, which is the test of a good alternative. A page that says only "See the map below" fails that test, because it gives the visitor nothing to use when the map is unavailable.
Privacy and data use deserve attention for maps, as for other embeds. A map embed may request the visitor's location, if it offers a "centre on me" feature, and it may record that the page was visited. The allow list should therefore permit geolocation only if that feature is genuinely needed and if the visitor will be asked for permission in a clear way. Browsers ask the visitor for location permission, and that prompt is a protection, but it is still worth considering whether a static address and directions would serve most visitors just as well, without any location request. For many pages, such as a shop or a community centre, a written address plus a link to a map service is sufficient, and an interactive embed is a bonus, not a necessity. Choosing the lighter option when it suffices is a form of respect for the visitor's privacy and data.
Finally, consider the map's purpose before embedding it. A map that shows a single location helps a visitor find that place. A map that shows a route helps a visitor travel. A map that shows many locations helps a visitor compare them. Each purpose suggests a different zoom level, centre, and set of markers, and the embed code should be configured accordingly, not left at a default view that shows the wrong area. Test the embed at phone width, check that markers are visible and labelled, and check that the written alternative matches the map's view. A map that is correctly configured, responsively sized, and paired with written directions is a genuinely helpful embed. A map that is merely present is not.
Check: What essential information should accompany a map embed as text?
Section 31
Iframes can embed more than videos and maps, and each additional kind of embed brings its own considerations. Documents, presentations, forms, social media posts, music players, and interactive tools are all commonly embedded, and the general principles from earlier sections still apply: use an official embed where one exists, add a descriptive title, review sandbox and allow, use lazy loading where appropriate, and provide a text alternative or a link for visitors who cannot use the frame. The specific details vary, however, and it is worth thinking through a few common cases, because each one tempts a different shortcut.
A form embedded in a frame, for example, needs to be usable with a keyboard and a screen reader, and it needs to submit reliably. If the form provider's embed requires scripts and form submission, sandbox must allow those capabilities, as Section 25 explains, or the form will appear but fail when submitted, which is worse than no form at all. Test the form end to end, from opening the page to receiving a confirmation, rather than assuming that a visible form is a working form. A document embed, such as a slide deck or a report, needs a different check: can a visitor read it without the frame, for example through a download link or a written summary, if the frame fails or if the document is too small to read on a phone? A slide deck that is legible on a desktop but illegible in a narrow frame on a phone is not serving mobile visitors, however impressive it looks in the editor.
Social media embeds raise a particular question about necessity. Embedding a post brings the platform's scripts, styles, and tracking into your page, often for a short piece of content that could be quoted in text with a link to the original. Quoting with attribution and linking is often lighter, faster, and more accessible than embedding, and it respects the original author while giving your visitors the content in a form they can read without loading a third-party frame. Embedding is justified when the post itself is interactive, or when its visual presentation is the point, but it should not be the default for every reference to social media. Ask, for each embed, whether the frame adds something that text and a link cannot provide, and embed only when the answer is yes.
Music and audio embeds from streaming platforms follow a similar logic to video embeds, with one extra consideration: audio embeds often autoplay or show a player that competes with other media on the page. If your page already has a native audio player, adding a streaming embed that also plays sound can create confusion about which player is playing, and can lead to two sounds playing at once. Avoid placing multiple playable media items so close together that a visitor can start one without realising another is already playing, and make each player's controls clear. An embed should be a distinct, labelled part of the page, not a surprise that appears in the middle of an article without context.
Check: Why is quoting a social post with a link often better than embedding it?
Section 32
Sizing an iframe responsively requires a different technique from sizing a video, because an iframe has no intrinsic aspect ratio that the browser can discover from a file. A video file declares its dimensions, so the browser can preserve its shape. An iframe's content is a separate page, whose height may change as it loads, and whose shape is not known in advance. If you give an iframe a fixed width and height in pixels, it will overflow a narrow phone screen in the same way a fixed video does, and if you give it a percentage width but a fixed height, it may be too tall on a phone or too short on a desktop, cutting off content or leaving empty space. The solution is to wrap the iframe in a container that defines the shape you want, and to let the iframe fill that container.
For video embeds, the container technique is well established. You create a wrapper element, give it a position and an aspect ratio, such as sixteen to nine, and place the iframe inside it so that it fills the wrapper completely. The wrapper's width adapts to the page, its height follows from the ratio, and the iframe follows the wrapper. That pattern preserves the video's shape at every width, without distortion, and without sideways scrolling. It is the same aspect-ratio idea as Section 13, applied through a wrapper because the iframe itself does not carry the ratio. The wrapper should be described in your stylesheet, not in the iframe's attributes, because the shape is a layout decision, and layout belongs in CSS.
For non-video embeds, such as maps, documents, and forms, a fixed aspect ratio may not be appropriate, because the content's ideal shape is not a video shape. A map, for example, may work well in a wide, short rectangle on a desktop, but need a taller rectangle on a phone to remain usable. A form may need a height that grows with its content, which a fixed-ratio wrapper cannot provide. In those cases, a responsive approach means choosing a sensible height for each screen size, using CSS rules that change the height at different widths, and testing the result at phone, tablet, and desktop sizes. There is no single ratio that fits every embed, and pretending otherwise leads to frames that are too short to use or too tall to scan past. Test each embed type at real widths, and adjust its container accordingly.
A final point about iframe height is worth stating plainly. An iframe does not automatically grow to fit its content, in the way that a normal page section grows as text is added. Its height is whatever you set, unless scripting on both pages cooperates to resize it, which is a more advanced topic and requires the embedded page's cooperation. Do not expect an iframe to resize itself, and do not set a tiny height in the hope that content will expand it. Set a height that shows the content usefully, test it, and provide a link to the full page for visitors who need more space. A frame with a sensible, tested height is usable. A frame that cuts off its content is not, however elegant the surrounding page may be.
Check: Why does an iframe need a wrapper to preserve a video's shape, when a video file does not?
Section 33
Lazy loading delays the loading of media or an iframe until it is near the visitor's viewport, which is the visible area of the page. For iframes, the loading attribute with the value lazy tells the browser to wait until the frame is close to becoming visible before fetching its content. For images, the same attribute exists, and for video, the preload attribute and poster combination serve a similar purpose, although video does not use loading lazy in the same way. The benefit is straightforward: a page with several embeds below the fold, meaning below the initially visible area, does not spend time and data loading all of them before the visitor has scrolled to them. The page loads faster, the visitor sees the top content sooner, and embeds that are never scrolled to are never loaded at all, which saves data and reduces third-party requests.
Lazy loading is most valuable on pages with many embeds, such as an article with several videos, a directory with many maps, or a long page with multiple interactive tools. On such a page, eager loading, which is the default for iframes, means the browser fetches every embed at once, competing for bandwidth with the main content and slowing the initial display. Lazy loading spreads that work out, fetching each embed when it is needed, which feels faster even if the total data downloaded eventually is the same. It is also a privacy benefit, as noted in Section 27, because an embed that is never loaded does not receive information about the visit. For a single embed at the top of a page, lazy loading offers little benefit, because the embed is visible immediately and will be loaded anyway. In that case, eager loading, or simply omitting the loading attribute, is the sensible choice.
There are limits to lazy loading that should be understood. The browser decides what "near the viewport" means, and that distance can vary, so a lazy-loaded embed may begin loading slightly before it becomes visible, which is intentional, to avoid a blank frame when the visitor scrolls to it. It is a hint, similar to preload, that the browser interprets with its own judgement about connection speed, data saving, and user settings. You should therefore not rely on lazy loading to hide an embed's existence or to prevent a third party from ever learning about a visit to a page where the embed is near the top. It reduces unnecessary loading, it does not eliminate it in all cases.
Testing lazy loading is simple and worth doing. Load a page with several lazy embeds, observe that only the visible ones load initially, scroll slowly, and observe that each embed loads as it approaches the viewport. If an embed never loads when scrolled to, check the loading attribute and the surrounding layout, because a frame hidden with CSS or placed inside a container the browser considers hidden may not trigger loading. Lazy loading is a performance tool, not a hiding tool, and it works best when embeds are placed in the normal flow of the page, where the browser can predict when they will become visible. Used that way, it makes long pages faster without changing what the visitor ultimately sees.
Check: When does lazy loading save the most data, and when does it save little?
Section 34
Performance for media begins with file size, because a media file's size decides how long it takes to download, how much data it consumes, and how quickly playback can start. A large video file on a slow connection will stall, buffer, and frustrate, even if its picture is beautiful. A smaller file, encoded at a quality appropriate to its purpose, will start promptly and play smoothly, even if it sacrifices some fine detail that most visitors would not notice on a phone screen. The art of media performance is therefore not to maximise quality, but to choose the quality that serves the content at the size it will actually be displayed, and no more. A video displayed at 640 pixels wide does not need to be encoded at a resolution far larger than that, because the extra detail will be discarded when the browser scales it down, while the extra data will still be downloaded.
Compression is the tool that reduces file size, and it works by discarding information that is less noticeable, such as subtle colour variations or fine detail in fast-moving scenes. Different kinds of content compress differently. Speech compresses well, because it contains relatively little information per second. Music compresses less well, because it contains more detail. A static talking-head video compresses well, because much of the picture stays the same from frame to frame. A fast-moving sports clip compresses less well, because the picture changes constantly. Understanding those differences helps you set realistic expectations. A file size that is reasonable for a lecture may be unreasonably large for a short animation, and vice versa, and comparing files across different kinds of content without accounting for those differences leads to poor decisions.
Practical steps for reducing file size are straightforward, and they should be applied before publishing, not after visitors complain. Encode at a resolution close to the display size, choose a bitrate appropriate to the content, trim silence or unnecessary footage from the start and end, and avoid uploading a file straight from a camera or screen recorder without encoding it for the web. Camera files are often encoded for editing, not for streaming, and they can be several times larger than a web-encoded version of the same content at similar visible quality. A short encoding pass, using a tool you understand, can therefore be the single most effective performance improvement for a media page, and it is worth learning even if you only publish media occasionally.
Finally, measure performance rather than guessing it. Check the file size before publishing, test playback on a slower connection, either by throttling in your browser's developer tools or by testing on a mobile connection, and observe whether playback stalls. If it stalls, reduce the file size or offer a lower-quality alternative, rather than assuming the visitor's connection is at fault. A page that plays smoothly on a fast office connection but stalls on a mobile connection is not a fast page. It is a page that has only been tested in favourable conditions. Testing under realistic conditions is part of publishing media responsibly, and it is the step that turns good intentions about performance into a page that actually performs.
Check: Why is a camera's original file often too large for the web, even if it looks good?
Section 35
Choosing a resolution and quality for video is a balance between clarity and data, and that balance depends on how the video will be watched. A video intended for fullscreen viewing on a large screen needs more detail than a video intended for a small player inside an article, because the larger display reveals flaws that the smaller display hides. A video that shows fine text, such as a code editor or a diagram, needs more detail than a video that shows a presenter speaking to camera, because the text becomes illegible if the resolution is too low, while a face remains recognisable at a lower resolution. The right resolution is therefore not a single number to memorise. It is a decision based on display size, content detail, and the visitor's likely connection, made for each video rather than copied from a previous project.
Bitrate, the amount of data used per second of video, is closely related to resolution, but it is not the same thing. A high-resolution video at a low bitrate can look worse than a lower-resolution video at a higher bitrate, because the low bitrate forces heavy compression that introduces visible artefacts, such as blockiness in fast movement or blurring in detailed areas. Conversely, a very high bitrate at a modest resolution wastes data without visible benefit, because the picture is already clear enough for its display size. The goal is a pairing of resolution and bitrate that produces a clear picture without wasted data, and finding that pairing requires testing with the actual content, not just copying settings from a guide. Encode a short test clip at a few settings, view it at the intended display size, and choose the lowest setting that still looks clear. That test takes minutes and prevents both blurry videos and bloated files.
Audio quality follows a similar logic, although the numbers are smaller. Speech remains intelligible at lower bitrates than music, because speech contains less detail, and a podcast encoded for speech can therefore be smaller than a music recording of the same length without sounding worse to most listeners. Music, especially music with many instruments or wide dynamics, needs a higher bitrate to avoid audible artefacts, such as a muffled or swirling quality in complex passages. As with video, the test is listening at the intended use: headphones, phone speaker, or desktop speakers, and choosing the lowest setting that still sounds clear. Encoding speech at music settings wastes data. Encoding music at speech settings degrades it. Match the setting to the content.
A final consideration is offering a choice where it matters. For a large library, or for visitors on very different connections, offering a lower-quality alternative, or a download link for offline listening, can be more helpful than forcing a single quality on everyone. That choice does not need to be complex. A simple note near the player, stating the file size or offering a smaller version, lets the visitor decide. That decision, like the preload decision, belongs to the visitor, and the page's job is to give them the information and options to make it well. Quality is not a fixed target. It is a trade-off, and a good page makes that trade-off visible and sensible.
Check: Why can a high-resolution video look worse than a lower-resolution one?
Section 36
The poster image and the preload attribute work together as a performance pair, and understanding their interaction helps you choose a sensible combination for each page. Preload none, as Section 8 explains, prevents the browser from downloading media data in advance. A poster, as Section 14 explains, gives the player a preview image without downloading the media itself. Together, they produce a player that looks complete, shows what the video is about, and spends almost no data until the visitor presses play. That combination is ideal for a page with several videos, where most visitors will play only one, because it avoids downloading many large files for the sake of a page that is mostly skimmed. The poster does the work of attracting and informing, while the video data waits for a deliberate choice.
Preload metadata offers a middle ground. It downloads enough to show duration and dimensions, which makes the timeline meaningful and helps the browser reserve space, while still avoiding the full file download. A poster remains useful in that combination, because the player still needs a preview image before playback, and the metadata alone does not provide one. The poster and the metadata together give the visitor two kinds of information: what the video looks like, and how long it is. Those two facts are often enough for a visitor to decide whether to play, which is the decision the page should support. For a single featured video, that middle ground is often the best balance between prompt playback and data respect.
Preload auto, by contrast, may begin downloading the video itself, which can make playback start almost immediately, but at the cost of data that may be wasted if the visitor never plays. In that combination, the poster is less critical, because the video data itself may arrive quickly, but it is still useful as a preview during the brief loading period, and as a fallback if the download stalls. The poster should not be treated as unnecessary simply because preload is set to auto. It still provides the first impression, and it still covers the case where the browser ignores the preload hint, for example on a data-saving connection. A poster is cheap insurance, and it should be present regardless of the preload value, unless the video is a purely decorative background, where different rules apply.
The lesson of this pairing is that performance is not a single attribute. It is the combination of attributes, images, and layout decisions that together determine how much data a page uses and how quickly it becomes usable. Preload controls data. Poster controls appearance before playback. Responsive sizing controls layout stability. Captions and transcripts control accessibility. Each decision affects the others, and a good media page is one where those decisions have been made together, for the specific page and its visitors, rather than copied as a set from another page without thought. Review the combination before publishing, and you will catch the cases where a poster is missing, a preload value is wasteful, or a player is likely to jump.
Check: What does a poster provide that preload metadata alone does not?
Section 37
Lazy loading and preload are both performance tools, but they operate at different levels, and confusing them leads to poor choices. Preload, covered in Section 8, controls how much of a single media file the browser downloads before playback. It applies to audio and video elements that are already on the page. Lazy loading, covered in Section 33, controls when an element itself is loaded, delaying an iframe, or an image, until it is near the viewport. For a video element, preload is the relevant tool, because the video element is already present, and the question is how much of its file to fetch early. For an iframe embed, loading lazy is the relevant tool, because the question is whether to fetch the embedded page at all until it is needed. Using the right tool for the right element is the first step to a coherent performance strategy.
The two tools can also interact on a page that mixes native media and embeds. A long article might contain a native video near the top, with preload metadata, and several iframe embeds further down, with loading lazy. The native video's metadata loads promptly, so its duration is visible, while the distant embeds wait until the visitor scrolls near them. That combination respects both the top content, which the visitor sees immediately, and the lower content, which they may never reach. Reversing the combination, for example by setting preload auto on every native video and eager loading on every iframe, would produce a page that downloads everything at once, defeating the purpose of both tools. Performance is therefore a page-level plan, not a per-element default, and it should be reviewed as a whole before publication.
There is also a common misunderstanding about lazy loading and native video. The loading attribute does not apply to video elements, so adding loading lazy to a video element will not delay its file in the way a beginner might expect. For video, preload none is the equivalent of lazy loading, because it prevents early downloading until the visitor chooses to play. That distinction is easy to miss, because the attribute name suggests a general lazy behaviour, but HTML treats different elements differently, and the specification for each element is the authority. When in doubt, check which attributes an element actually supports, rather than assuming an attribute that works on one element works on all of them. That checking habit will save you from a class of silent failures, where an attribute is present but ignored.
Finally, remember that performance tools are hints, not guarantees, as Section 8 noted for preload and Section 33 noted for lazy loading. Browsers may override them for data saving, for user settings, or for their own heuristics about what the visitor is likely to need. That flexibility is a protection for visitors, and it means your performance plan should be robust even when a hint is ignored. A page that relies entirely on lazy loading to avoid a huge initial download is fragile. A page that also uses reasonable file sizes, posters, and a sensible number of embeds will perform well even if a browser decides to load an embed earlier than you expected. Hints help, but good files and good judgement help more.
Check: Why does loading lazy not delay a native video file in the way preload none does?
Section 38
Accessibility for media begins with the understanding that visitors experience media differently, and that those differences are normal, not exceptional. Some visitors cannot hear, some cannot see, some cannot use a mouse, some are sensitive to motion, and many visitors experience a temporary limitation, such as a noisy room, a quiet library, or a slow connection, that makes media harder to use in that moment. Designing for those visitors is not an extra task to be added at the end. It is the core task of media publishing, because a video without captions, a player without keyboard support, or an autoplay video that cannot be paused fails for a large group of people in ordinary situations, not just for a small group in rare ones. This section and the next few expand that idea into specific practices, starting with the distinction between captions, subtitles, and transcripts, which earlier sections introduced.
Captions, as Section 15 explained, include spoken words and important sounds, for visitors who cannot hear. They should be accurate, synchronised, and complete, not summarised or paraphrased in a way that loses meaning. A caption that omits a speaker's warning, or that paraphrases a technical explanation into vaguer words, misleads the visitor who depends on it. Accuracy therefore matters more than brevity, although brevity matters too, because a caption that is too long to read in its display time is also a failure. The balance is to write captions that convey the full meaning in readable chunks, timed to the speech, with speaker identification where it matters, and with sound descriptions where a sound carries information. That balance is a writing skill, and it improves with practice and with watching your own captioned videos critically.
Subtitles, by contrast, translate speech into another language, and their accuracy is a translation issue as much as a timing issue. A subtitle that mistranslates a key term can mislead a visitor just as surely as an inaccurate caption, and a subtitle that is too literal can be hard to read, while a subtitle that is too free can lose the speaker's meaning. If you offer subtitles, have them checked by someone who knows both languages well, and test them on the video, because a translation that reads well on paper may be too long for its cue duration on screen. That checking is part of publishing, not an optional polish, and it should be budgeted in time in the same way as recording and editing.
Transcripts, as Section 19 explained, provide a permanent text version that serves visitors who cannot play the media, visitors who need to search or quote it, and visitors who prefer reading. A page that offers captions but no transcript still excludes a visitor who cannot play the video at all, for example because of a connection or device limitation. A page that offers a transcript but no captions still excludes a visitor who is watching the video and needs synchronised text. Both are needed, for different needs, and neither replaces the other. Providing both is the standard for accessible media, and it should be planned from the start of a project, not added as an afterthought when a complaint arrives.
Check: Why is providing captions alone not enough for full media accessibility?
Section 39
Audio description is a spoken or written description of important visual information in a video, for visitors who cannot see the picture. In a video with dialogue, description fits into pauses between speech, describing actions, settings, facial expressions, or on-screen text that the dialogue does not convey. In a silent demonstration, description may be the main audio track, explaining each step as it happens. HTML supports description tracks through the track element with kind descriptions, as Section 16 noted, but support for presenting those tracks varies, and a description track alone may not be sufficient. A practical companion is a written description or summary near the player, describing the visual content in words, so that a visitor who cannot see can still follow the lesson, even if their browser does not present the description track in the way they need.
Writing good description requires thinking about what is visually essential. Not every detail needs describing. The colour of a presenter's shirt rarely matters, unless the lesson is about colour. The position of a tool, the direction of a movement, and the text on a screen often do matter, because they carry the lesson's meaning. A useful test is to listen to the video without watching it, and to note every moment where you feel lost because a visual action was not explained. Those moments are where description is needed. If the narration already explains the action, description may be unnecessary for that moment. If the narration says "do it like this" while the picture shows the action, description is essential, because "this" has no meaning without the picture. That test, applied honestly, reveals how much of a video depends on sight alone, which is often more than the author realised.
For audio-only content, the accessibility needs are different. There is no picture to describe, but there may be sounds that carry meaning, such as music cues, sound effects, or changes in speaker that a transcript should note. A transcript that records only spoken words, without noting that music changed, that a new speaker began, or that a sound effect illustrated a point, may be incomplete for a visitor who cannot hear. Including bracketed sound descriptions in the transcript, as Section 19 suggested, addresses that gap. Similarly, a podcast that relies on a visual element, such as a diagram mentioned but not described, should describe that diagram in the transcript or in accompanying text, so that a listener is not left wondering what the diagram showed.
Accessibility for media is therefore not a single feature. It is a set of complementary provisions: captions for hearing, description for sight, transcripts for reading and searching, keyboard controls for interaction, and pause controls for motion. Each provision serves a different need, and together they make media usable for a wider audience than any one provision alone. Planning them together, at the start of a project, is far easier than retrofitting them after publication, when the recording may need to be re-edited or re-captioned. Accessibility planned early is accessibility that actually ships.
Check: How can you test whether a video needs audio description?
Section 40
Keyboard accessibility for media means that a visitor who cannot use a mouse, or who prefers a keyboard, can operate the player fully: play, pause, seek, adjust volume, toggle captions, and enter or exit fullscreen, all without a mouse. Built-in browser controls, as Section 7 explained, generally provide that keyboard support, because the browser implements the player as a set of focusable controls with standard keyboard behaviour. A visitor can tab to the player, use the space bar to play or pause in many browsers, use arrow keys to seek or adjust volume where supported, and use the player's own buttons for captions and fullscreen. That support is one of the strongest reasons to use built-in controls for ordinary media, rather than building a custom player that must replicate all of that behaviour from scratch.
Custom players, when they are necessary, must be built with keyboard support as a first requirement, not as a later addition. Every custom button needs to be focusable, needs a visible focus indicator so a keyboard user can see where they are, needs a label that a screen reader can announce, and needs to respond to the expected keys: space or enter to activate a button, arrow keys for sliders where appropriate, and escape to exit fullscreen where that applies. A custom player that looks beautiful with a mouse but cannot be operated with a keyboard is not a finished player. It is a player that excludes a group of visitors, and it should not be published until keyboard support is tested. Testing is simple: unplug the mouse, or simply do not use it, and try to play, pause, seek, and toggle captions using only the keyboard. If any action is impossible, the player is not ready.
Focus management is a related detail that custom players often get wrong. When a visitor opens a fullscreen player, or opens a captions menu, keyboard focus should move to a sensible place inside that interface, and when they close it, focus should return to the player. Without that management, a keyboard user may find themselves lost, tabbing through the whole page to find their way back, or trapped inside a menu they cannot exit. Built-in players handle much of this automatically, which is another reason to prefer them. If you build a custom player, you must handle focus deliberately, and you must test it with a keyboard, not just with a mouse, because focus problems are invisible to mouse users.
Finally, remember that keyboard accessibility is not only about the player itself. It is also about the page around the player. A transcript link, a download link, and a captions toggle should all be keyboard reachable, in a logical order, so that a visitor can move from the article to the player to the transcript without getting lost. A page that places the player in a logical reading order, with clear headings and links, supports keyboard users far better than a page that places media in an unexpected location or hides its controls behind hover-only interactions. Keyboard accessibility is a property of the whole page, and the player is one part of it, however important that part may be.
Check: What should you do to test a custom player's keyboard support?
Section 41
Reduced motion is a visitor preference for less animation and movement, expressed through the prefers-reduced-motion media feature in CSS, and it matters for media because autoplay video, looping animation, and moving backgrounds can cause discomfort, distraction, or, in rare cases, illness for some visitors. A visitor who has set their system to prefer reduced motion is telling websites, in a standard way, that they want less movement, and a responsible page should respect that preference. For a content video that the visitor chooses to play, reduced motion does not mean the video must be removed, because the visitor has chosen to watch it. For a background video that plays automatically, or for a looping animation that the visitor did not choose, reduced motion is a strong signal to pause it, replace it with a still image, or provide a clear pause control.
Background video deserves particular care, because it is the form of video most likely to move without the visitor's choice. A full-width video behind a headline, looping silently, may look impressive, but it moves constantly, it competes with the text for attention, and it cannot be paused unless the page provides a control. For a visitor who prefers reduced motion, that constant movement is not a minor annoyance. It can make the page hard to read, because the eye is drawn to movement, and it can cause physical discomfort. The responsible approach is to respect the reduced-motion preference by not autoplaying the background video for those visitors, showing the poster image instead, and providing a pause control for all visitors, so that anyone can stop the movement if they wish. That approach preserves the visual design for visitors who enjoy motion, while protecting those who do not.
The same principle applies to other moving media, such as a carousel that advances automatically, or a looping animation that cannot be paused. Automatic movement should always have a pause control, and it should respect reduced-motion preferences where the technology allows. A carousel that advances every few seconds without a pause button forces a visitor to read against a deadline, which is stressful for everyone and particularly difficult for visitors who read slowly or who use assistive technology. A pause button transforms that experience from a timed test into a reading experience the visitor controls. The control should be easy to find, clearly labelled, and keyboard reachable, not hidden in a menu or shown only on hover.
Implementing reduced-motion support does not require complex code for the purposes of this chapter. The concept is what matters: detect the preference where your stylesheet or script can, pause or replace automatic movement for those visitors, and always provide a manual pause for automatic media. Test the result by enabling reduced motion in your system's settings and loading the page, observing whether background video still plays and whether a pause control is available. That test, like the keyboard test in the previous section, is simple and revealing, and it should be part of publishing any page with automatic movement. Motion should be a choice, not an imposition.
Check: Why should a background video respect the reduced-motion preference?
Section 42
Fallback text for media is not only the technical fallback inside the player, covered in Section 20. It is also the ordinary text around the player that ensures the page still makes sense when media cannot be played, cannot be seen, or cannot be heard. That surrounding text includes a title for the recording, a short description of what it covers, a transcript link, and, for video, a summary of the visual content. Together, those elements form a text layer that stands in for the media when necessary, and that supports the media when it does play, by helping visitors decide whether to play it and by helping them find their place in it. A page that consists only of a player, with no surrounding text, fails when the player fails, because there is nothing else for the visitor to use.
The title and description deserve attention, because they are often written hastily. A title such as "Video 1" tells a visitor nothing, while a title such as "Shaping a loaf: folding and resting the dough" tells them exactly what they will learn. A description that says "Watch this video" adds nothing, while a description that says "This three-minute video shows the folding technique, the resting time, and the signs that the dough is ready" gives the visitor a reason to watch and a preview of the content. Those details matter for search as well, because search tools index text far more easily than they index media, and a well-described video is more likely to be found by visitors searching for its topic. Text around media is therefore not just accessibility. It is discoverability, and it is good writing.
For audio, surrounding text is even more critical, because there is no picture to give a clue about the content. A podcast episode page with only a player and no description leaves a visitor guessing about the topic, the guests, and the length, and it gives a search engine almost nothing to index. A page with a title, a description, a list of topics, and a transcript, by contrast, is useful even before the visitor presses play, and it remains useful after they have listened, as a reference. That text layer is what turns an audio file into a web page, rather than a file that happens to be hosted on the web. The distinction is important, because the web is a text medium first, and media succeeds on the web when it is integrated into that text medium, not when it replaces it.
A final form of fallback text is the description for a poster image. The surrounding title and description serve that purpose instead, describing the video for visitors who cannot see the poster. If the poster contains essential text, that text should also appear in the surrounding description, so that no information is poster-only. That rule, like the rule against essential information being image-only, which Chapter 4 discusses for ordinary images, applies to media posters as well. No essential information should exist only in a picture, whether that picture is a poster, a diagram, or a frame of video.
Check: What text should surround a player so the page still works if the media fails?
Section 43
Media pitfalls often begin with a single, understandable mistake: assuming that what works on the author's device will work everywhere. A video that plays on a laptop with a fast connection may stall on a phone with a slower connection. A format that plays in one browser may fail in another. An autoplay video that starts on a desktop may be blocked on a phone. A player that looks fine at desktop width may overflow a phone screen. Each of those failures is predictable, and each is preventable by testing on more than one device, more than one browser, and more than one connection speed before publishing. Testing is not an extra step for perfectionists. It is the step that catches the predictable failures, and it should be part of every media publication, however small the page may seem.
A second common pitfall is missing controls, which Section 7 covered, but which deserves repeating because it recurs in new forms. A custom thumbnail that starts a video on click, without showing a player, may seem elegant, but it hides duration, volume, and pause controls until after playback has started, and it may not be keyboard accessible. A background video without a pause control, covered in Section 41, has the same problem in a different form. An audio player styled to look like a simple play button, without a timeline or volume control, has the same problem again. In each case, the design prioritises a clean appearance over usable controls, and the visitor pays for that appearance with lost control. The remedy is to start from built-in controls, and to add custom styling only where it does not remove functionality. Clean design and usable controls are not opposites. A player with clear controls can still look clean, if the controls are well placed and well labelled.
A third pitfall is the large, unoptimised file, covered in Sections 34 and 35, which recurs because it is easy to upload a file directly from a camera or recorder without encoding it for the web. The symptom is a page that loads slowly, a video that buffers, or a visitor who abandons the page before playback starts. The remedy is encoding for the web, at a resolution and bitrate appropriate to the display size and content, and measuring the result before publishing. A media page that has not been encoded for the web has not been finished, however good its content may be.
A fourth pitfall is the missing text layer: no captions, no transcript, no description, no title that describes the content. That pitfall is often invisible to the author, because the author can hear and see the media, and therefore does not notice what is missing for other visitors. The remedy is to check the page as if you could not hear it, then as if you could not see it, then as if you could not play it at all, and to ask whether it still works in each case. Pitfalls are not mysterious. They are predictable, and they are preventable by testing, by using built-in controls, by encoding for the web, and by providing text.
Check: What three checks reveal most media accessibility gaps?
Section 44
Another set of pitfalls concerns layout and placement, and these are easy to overlook because they do not prevent playback. They prevent comfortable viewing. A video placed in a narrow column, where its picture is too small to show detail, is a layout pitfall, even though the video technically plays. A video placed at the very top of a page, pushing the article's introduction below the fold, is a placement pitfall, because the visitor must scroll past a large player to reach the text that explains it. An iframe given a fixed height that cuts off its content, as Section 32 warned, is a height pitfall, because the visitor sees a cropped map or form and may not realise that more content exists below the frame's edge.
The remedy for layout pitfalls is to design the page around the media, not to insert media into a finished layout as an afterthought. Ask where the media belongs in the reading order: after the introduction that explains it, beside the text that it illustrates, or at the end as a supplement. Ask how wide its container needs to be for its detail to be legible, and choose a container that meets that need, rather than squeezing the media into whatever space remains. Ask whether the media's height is sufficient on a phone as well as on a desktop, and test it at both widths. Those questions sound obvious, but they are often skipped when a page is assembled quickly, and their absence shows in the finished page as a player that is technically present but practically unusable.
A related pitfall is the page with too much media. An article with five videos, three audio players, and two iframes may seem rich, but it is heavy, slow, and confusing, because the visitor does not know where to start, and the browser must load many players at once. A page with one well-chosen video, placed where it supports the argument, is often more effective than a page with many videos competing for attention. The question to ask for each additional media item is whether it adds understanding that the existing media does not already provide, and whether the visitor is likely to use it. If the answer to either question is no, the item should be a link, not an embed, so that the visitor can choose to open it without burdening the main page. Restraint is a media skill, not just an aesthetic preference.
Finally, watch for the pitfall of media that distracts from the page's purpose. A looping background video behind text, an autoplaying audio clip that starts while the visitor is reading, and a carousel of videos that advances automatically all compete with the visitor's attention, and they often win that competition in a way that harms reading. The page's purpose should decide whether movement or sound is appropriate, not the availability of a media file. If the purpose is reading, movement and sound should be optional, started by the visitor, and pausable. If the purpose is watching, the video should be central, with controls and captions, and without competing media nearby. Aligning media with purpose prevents distraction, and it makes the media that remains feel intentional rather than intrusive.
Check: Why can a page with many media items be less effective than a page with one?
Section 45
A third set of pitfalls concerns rights, consent, and honesty, and these are more serious than technical pitfalls, because they affect other people, not just playback. Using a recording of a person without their permission, embedding a video you do not have the right to use, or re-hosting a creator's work without attribution can harm the people involved and can create legal and reputational problems for the site owner. The rule is simple to state, although it requires care to apply: only publish media you have the right to publish, with the permission of the people in it and the creator who made it, and with attribution where attribution is required. If you are unsure about rights, do not publish until you have checked. A missing video is a smaller problem than a video published without permission.
Consent deserves particular attention for recordings of people. A person who agreed to be recorded for one purpose, such as a private class, may not have agreed to be published on a public website. A child who appears in a video needs additional care, and the consent of a parent or guardian, according to the rules that apply in your context. A visitor who appears incidentally in a background shot may not have consented to publication at all, and blurring or cropping may be necessary. These are not technical decisions. They are decisions about respect, and they should be made before recording, not after publication, when removing a video may already be too late to undo its spread. When in doubt, ask, and record the permission you receive, so that you can show it if questions arise later.
Honesty about media also matters. A poster that misrepresents a video, a title that promises content the recording does not contain, a caption that invents words the speaker did not say, and a transcript that edits a speaker's argument into a different one are all forms of dishonesty, even when they are unintentional. Each one misleads a visitor who trusts the page, and each one damages the site's credibility when discovered. The remedy is to check posters, titles, captions, and transcripts against the actual recording, and to correct errors promptly when they are found. A site that corrects its media errors openly is more trustworthy than a site that leaves them, because correction shows that accuracy matters to its authors.
Finally, be honest about what media is. If a video is a simulation, a dramatisation, or a generated clip, label it as such, so that visitors do not mistake it for a real recording. If a recording has been edited to remove a section, note the edit where it matters, so that visitors do not assume the recording is complete. If a clip is used out of its original context, provide that context, so that visitors do not misinterpret it. Those labels cost a sentence, and they prevent misunderstandings that can be far more costly. Media is powerful because it feels direct and true. That power carries a responsibility to label, attribute, and contextualise honestly, and that responsibility is part of front-end work, not separate from it.
Check: What should you check before publishing a recording of another person?
Section 46
Testing media is a systematic process, not a single glance at the page on your own device. A useful testing routine covers playback, controls, captions, layout, and failure, in that order, because each step reveals a different class of problem. Start with playback: does each file play in more than one browser, on a phone as well as on a desktop, and at a connection speed similar to your visitors'? If a file fails in one browser, check its format and codec, as Sections 5 and 6 explain, before assuming the browser is at fault. If a file stalls, check its size and encoding, as Sections 34 and 35 explain, before assuming the visitor's connection is at fault. Playback testing catches the problems that prevent the media from working at all, and it should happen before any other testing, because a player that does not play cannot be assessed for anything else.
Next, test controls and keyboard access. Can you play, pause, seek, adjust volume, toggle captions, and enter fullscreen using only the keyboard, as Section 40 describes? Can you do the same with a mouse, and can you see where keyboard focus is at each step? If a control is missing, unreachable, or unlabelled, fix it before publishing, because a player that cannot be controlled is a player that cannot be used. Test captions next: turn them on, watch the video, and check that the text matches the speech, that it is synchronised, and that it includes important sounds where they matter. Turn captions off, and check that the video still makes sense from its picture and surrounding text, for visitors who watch without captions. Those two caption checks, on and off, reveal both caption errors and over-reliance on spoken words.
Then test layout at several widths. Shrink the browser to phone width, expand it to desktop width, and check that the player fits, that controls remain reachable, that the picture is not distorted, and that surrounding content does not jump when the media loads. Check the page on a real phone if you can, because device mode in developer tools, while useful, does not perfectly reproduce a phone's browser, its controls, or its connection. Layout testing catches the problems that visitors on phones encounter most, and it is the testing step most often skipped by developers who work only on a desktop. Skipping it is a choice to test only for visitors like yourself, which is not a representative sample.
Finally, test failure. Temporarily break a media file on a test copy of the page, or block a third-party embed, and observe what the visitor sees. Is there a fallback message, a download link, a transcript, and a written summary, as Sections 20 and 42 describe? Or is there a blank rectangle and a silent page? Failure testing is uncomfortable, because it requires deliberately breaking something you built, but it is the test that reveals whether your page degrades gracefully or collapses. A page that degrades gracefully is a page that respects visitors in difficult conditions, which are precisely the conditions where respect matters most. Test failure once, and you will publish with confidence thereafter.
Check: What five areas should a media testing routine cover, in order?
Section 47
Media and page performance interact in ways that go beyond individual file sizes. A page's total media load is the sum of all its players, posters, embeds, and the scripts those embeds bring with them, and that total decides how quickly the page becomes usable. A single well-encoded video may be acceptable on its own, but five such videos on one page, plus two map embeds and a social feed, can produce a page that takes far longer to load than any one item would suggest. The total matters because the browser must download, parse, and render all of those resources, often in competition with each other, and because a visitor on a limited connection experiences that total as waiting time, not as a list of separate files. Planning a page's media budget, meaning a rough total you are willing to spend on media, is therefore a useful habit, even if the budget is informal.
A practical way to manage that total is to prioritise media by its role on the page. The main video, the one that carries the page's central point, deserves the best encoding, the earliest loading, and the most prominent placement. Supporting media, such as additional examples or background material, can be lazy loaded, linked rather than embedded, or offered as downloads, so that they do not compete with the main content for bandwidth. That prioritisation mirrors the way a reader experiences the page: they encounter the main point first, and they choose whether to explore further. Prioritising is not about removing content. It is about ordering its delivery to match the visitor's likely journey.
Embeds deserve special attention in a media budget, because their cost is often hidden. An iframe embed may load not only the visible content, such as a video player, but also scripts, styles, fonts, and tracking code from the provider, and those resources may themselves load further resources. The total cost of an embed can therefore be several times the cost of the visible player alone, and it is difficult to predict from the embed code itself. Measuring the page's total load, using your browser's developer tools to observe network requests, reveals that hidden cost, and it often surprises authors who assumed an embed was lightweight. If an embed's total cost is disproportionate to its value on the page, consider replacing it with a link, a static image with a link, or a native alternative.
Finally, revisit the media budget when the page changes. Adding a new video to an existing page increases its total load, and that increase should be a deliberate decision, not an accident of editing. Removing an outdated embed reduces the total, and that reduction is a benefit worth noting. Media performance is therefore an ongoing practice, not a one-time optimisation. Review the page's media periodically, check its total size and load time, and ask whether each item still earns its place and its data cost. A page whose media is reviewed regularly stays fast as it grows. A page whose media is only added, never reviewed, grows slow by accumulation, even if each addition seemed small at the time.
Check: Why can an embed cost far more data than its visible player suggests?
Section 48
Choosing between native media, an iframe embed, and a simple link is a decision that shapes the whole page, and it should be made deliberately for each item, not by habit. Native media, using audio or video elements with files you host, gives you the most control: you choose the formats, the captions, the poster, the preload behaviour, and the player, and you avoid third-party requests. It is the best choice when you have the file and the rights, when accessibility matters most, and when you want a simple, predictable player. Its costs are hosting and encoding, and the need to maintain formats and captions yourself. For many teaching, podcast, and demonstration pages, those costs are worth paying, because control and accessibility outweigh convenience.
An iframe embed is the best choice when the content is interactive, hosted elsewhere, or available only through another platform, and when you have the provider's permission to embed it. A live map, a video you do not own, a form hosted by a service, and an interactive tool are all cases where an embed provides something native media cannot easily reproduce. Its costs are loss of control, third-party requests, and the need for sandbox, allow, title, and lazy-loading reviews, as earlier sections explain. An embed should therefore be chosen because it provides a capability you cannot provide natively, not because it is easier than encoding a file you already have. Ease alone is a poor reason to give a third party a frame on your page, with all the performance and privacy costs that frame brings.
A link is the best choice when the visitor does not need the content inline, when the content is long or heavy, or when the page would be burdened by embedding it. A link to a full lecture, to a large document, to a map service, or to a video platform gives the visitor access without loading the content into your page, and it respects their choice to open it when they are ready. Links are also the fallback when embedding is refused, as Section 28 explains, and when a native file is too large to host comfortably. A page that uses links thoughtfully is not a page that lacks media. It is a page that distinguishes between content the visitor needs now, which belongs inline, and content they may want later, which belongs behind a link. That distinction is a form of editorial judgement, and it improves both performance and readability.
In practice, a single page may use all three forms: a native video for its central lesson, an iframe map for its location, and links to further reading and full recordings. That mix is normal, and it is often the best solution, because each form serves a different purpose. The mistake is to use one form for everything, out of habit. A page that embeds everything is slow and intrusive. A page that links everything is fragmented. A page that hosts everything natively may be unmaintainable for interactive content. The balanced page, using each form where it fits best, is the goal, and reaching it requires asking, for each media item, what it is, who owns it, how the visitor will use it, and what it costs to include it inline.
Check: When is a link a better choice than an embed, even if embedding is possible?
Section 49
Media should be integrated into a page's structure, not dropped into it as an isolated block. That integration begins with headings and text that introduce the media, explain what it covers, and tell the visitor what to do after watching or listening. A video placed under a heading that names its topic, preceded by a sentence that explains why it matters, and followed by a task or a summary, feels like part of the argument, not an interruption. A video placed without introduction, between two unrelated paragraphs, feels like an advertisement, even if its content is relevant, because the visitor has no context for why it appears there. Context is not decoration. It is the bridge between the text and the media, and without it, the media floats, disconnected from the page's purpose.
Integration also means considering the reading order. A screen reader user encounters a page as a sequence, and media should appear in that sequence where it makes sense: after the text that introduces it, before the text that discusses it, and near the transcript or description that supports it. Placing media at the top of a page, before any introduction, forces a screen reader user to encounter a player before they know what it contains, which is confusing, even if the player has a good title. Placing media at the bottom, after the discussion that refers to it, forces the visitor to scroll back and forth. The natural order — introduce, show, discuss — works for sighted readers and screen reader users alike, because it follows the logic of the argument, not just the visual layout.
Visual integration matters too, although it should not override structural integration. A player that matches the page's width, that uses a consistent style for its surrounding caption and transcript links, and that sits within the main content area rather than floating in a sidebar, feels like part of the page. A player that is wider than its container, that uses clashing colours for its custom controls, or that sits in an unrelated part of the layout, feels like an intrusion, even if its content is good. Consistency is not about making every player identical. It is about making each player feel like it belongs to the page, through sensible sizing, clear labelling, and a predictable placement pattern that visitors learn as they move through the site.
Finally, integration means planning for the media's lifecycle. A video that is updated needs its captions, transcript, poster, and description updated too, or the page will contain a mixture of old and new information that confuses visitors. A video that is removed needs its surrounding text updated, or the page will refer to a player that no longer exists. Those maintenance tasks are easy to forget, because they are not part of recording or encoding, but they are part of publishing, and they should be included in the checklist for any media update. A well-integrated page is one where text, media, captions, and transcripts change together, so that the page remains coherent over time, not just on the day it is first published.
Check: Why should media appear in the HTML source order where its introduction says it belongs?
Section 50
This chapter has covered a wide range of media decisions, and it is useful to gather them into a checklist you can apply to any page before publishing. Start with purpose: does this media earn its place, by providing hearing or seeing that text cannot provide, or is it decoration that could be a link or nothing at all? If it earns its place, choose the right form: native audio or video when you have the file and the rights, an iframe embed when the content is interactive or hosted elsewhere with permission, and a link when inline inclusion is unnecessary or too costly. That purpose and form decision, made first, prevents most later problems, because a media item in the wrong form will struggle however well it is encoded or captioned.
Next, check the technical basics. For native media, confirm that you offer playable formats, with correct types, in a sensible order, and that the player has controls, a sensible preload value, and, for video, a poster and a width and height that describe its shape. For embeds, confirm that the iframe has a descriptive title, a sandbox value that allows only what is needed, an allow list that has been reviewed, a referrer policy you chose deliberately, and lazy loading if the embed is below the fold. For all media, confirm that it fits its container at phone, tablet, and desktop widths, without distortion, sideways scrolling, or layout jumping, and that its surrounding text includes a title, a description, and a transcript link where appropriate. Those checks take minutes, and they catch the technical failures that visitors notice first.
Then check accessibility, as a set of complementary provisions, not as a single feature. Are captions present, accurate, and synchronised, with the correct kind and language? Is there a transcript, available as readable text near the player? Is there a description or summary for important visual information? Can the player be operated fully with a keyboard, and can automatic movement be paused, especially for visitors who prefer reduced motion? Does the page still make sense if the media cannot be played, seen, or heard? Answering those questions honestly, and fixing the gaps before publishing, is what makes media accessible in practice, rather than in intention. Accessibility is not a label you add to a page. It is the result of those checks, applied consistently.
Finally, check performance, rights, and maintenance. Is the file encoded for the web, at a size appropriate to its display and content, and is the page's total media load reasonable? Do you have permission to publish this recording, with consent from the people in it and attribution where required, and have you labelled it honestly? Will you update captions, transcripts, posters, and descriptions together when the media changes, and will you review the page's media periodically as it grows? If you can answer yes to those questions, your media page is ready. It will not be perfect, because browsers, devices, and visitor needs vary, but it will be purposeful, playable, accessible, and respectful, which is the standard this chapter has aimed for throughout.
Check: What is the first question on the media checklist, before any technical check?
Practical task
Build a single practice page called media-practice.html that contains one native audio player and one native video player, plus one responsibly embedded map or video. For the audio player, use two source elements in different formats, add controls, set preload to metadata, and place a written summary and a transcript link beside it, even if the transcript is a short paragraph you write yourself for practice. For the video player, use two source elements, add controls, a poster image, and width and height that describe a sixteen-to-nine shape, then make the player responsive with CSS so it fits a phone screen without sideways scrolling. Add one captions track to the video, using a short WebVTT file you write yourself with at least four correctly timed cues, and mark it with the correct kind, language code, and label. For the embed, use an iframe with a descriptive title, lazy loading, a reviewed allow list, and a sandbox value that allows only what the embed demonstrably needs to display. Test the finished page in two browsers and at phone width, test every player with the keyboard alone, turn captions on and off, and deliberately break one source on a test copy to confirm that your fallback text and download link appear. Write down what failed during testing and what you changed, because that testing log is part of the task, not an afterthought.
Chapter questions
- Why should you offer more than one audio or video format, and what does the type attribute on a source element help the browser avoid?
- Explain, in your own words, why browsers generally block autoplay with sound, and describe a respectful alternative for a video that should move when the page loads.
- What is the difference between captions and subtitles, and why is a transcript still needed even when captions are present?
- A site you want to embed refuses to load inside your iframe. What is the most likely reason, and what are the two honest alternatives to bypassing that refusal?
- A page contains a large video, two map embeds, and several audio players, and it loads slowly. Name three different changes, covering file size, loading behaviour, and page structure, that could improve its performance without removing the content entirely.