Consider a common failure: at 09:41 on day one, the sponsor bug appeared in the lower-right corner of the stream. At 09:42, the live captions rolled up underneath it. By 09:43, the interpreter feed in the second language had lost its first line. Nobody in the control room noticed until an attendee posted a screenshot with the caption text half-hidden behind a logo. This is a constructed example, not a report of a specific event.
This is a layout failure, not a captioning failure. The captioner did their job. The sponsor did what the contract said. The stream layout had no enforced safe areas, so two overlays competed for the same pixels and the one with the higher z-index won.
The fix is not to remove the sponsor bug. It is to define, test, and lock the regions where captions, interpretation feeds, and graphics are allowed to live — before doors open, with a reversible change if something conflicts.
What the standards actually say about captions and obstruction
WCAG 2.2 Success Criterion 1.2.2 (Captions, Prerecorded, Level A) requires captions for prerecorded audio in synchronized media. The W3C’s Understanding document for that criterion includes a note in its definition of captions: “Captions should not obscure or obstruct relevant information in the video.” That is a normative-adjacent expectation, not a pixel specification, but it establishes the principle: captions and video content are not allowed to fight for the same space.
The same document defines captions as synchronized visual and/or text alternatives for both speech and non-speech audio information needed to understand the media. It also notes that captions identify who is speaking and include non-speech information such as meaningful sound effects. That matters for layout because speaker identification and sound-effect annotations add lines. A two-line caption region can become three or four lines during a panel with multiple speakers and audience reactions.
WebVTT, the W3C’s format for external text tracks, gives authors explicit positioning controls. Cues can be placed with position, line, align, and size settings. Regions can be defined with width, lines, regionanchor, and viewportanchor. The specification’s own example shows two regions, each 40% wide and 3 lines tall, anchored at 10%,90% and 90%,90% of the viewport, scrolling up. That is a concrete, testable layout: two caption columns, bottom-anchored, with a defined line budget.
What WebVTT does not do is protect those regions from other overlays. If your streaming platform composites a sponsor bug, a lower-third, and a WebVTT caption track in the same player, the player’s stacking order decides who wins. The specification describes cue positioning within the video viewport; it does not arbitrate between the caption track and a separately rendered graphic.
For broadcast reference patterns, ITU-R BT.1729 defines a common 16:9 or 4:3 digital television reference test pattern. It is a test pattern recommendation, not a caption placement rule, but it is the kind of artifact that lets you verify geometry on a monitor before you trust a layout. If your production chain includes broadcast-style monitoring, a reference pattern is a useful calibration step. If it does not, a simple grid overlay generated in your streaming tool is sufficient for the same purpose.
Where the conflict actually happens
Three overlays compete for the bottom third of a 16:9 stream:
- Captions. Typically bottom-centered or bottom-left, two to three lines, 32–48 px at 1080p depending on platform and viewer settings.
- Interpretation feeds. Often a picture-in-picture or a separate audio channel with its own caption track. If the interpretation is delivered as burned-in text or a second caption layer, it needs its own region.
- Sponsor graphics. Bugs, lower-thirds, tickers, and end cards. These are frequently placed in the lower-right or lower-left because that is where broadcast convention puts them.
The collision is predictable. A lower-right sponsor bug at 1080p might occupy roughly 200×80 px. A bottom-centered caption region at 80% width and 3 lines might occupy roughly 1,536×180 px. If both are anchored to the bottom edge, they overlap by the height of the bug across the right portion of the caption region.
On a 16:9 stream viewed on a phone in portrait, the player may letterbox or crop. A caption region anchored at 90% of the viewport height can end up under the platform’s own UI controls. A sponsor bug anchored at 95% can end up off-screen entirely. The layout that looked correct in the control room monitor is not the layout the attendee sees.
This is the same class of failure described in Why Hybrid Events Fall Apart at the Room-to-Chat Handoff: a handoff between two systems that each work correctly in isolation but were never tested together. The room-to-chat handoff fails on timing and state; the overlay handoff fails on geometry and stacking order.
A safe-area model you can test before doors open
The following is a recommendation, not a standard. It is designed to be simple enough to verify in 15 minutes and reversible if it conflicts with a platform constraint.
Divide the 16:9 frame into three horizontal bands:
- Top band (0–15% height): Reserved for platform UI, persistent event branding, and any top-anchored ticker. No captions, no interpretation text.
- Middle band (15–75% height): Primary video content. Speaker faces, slides, and demonstration content should be composed to survive a 5% crop on each side. Sponsor bugs may be placed here only if they do not overlap the caption region.
- Bottom band (75–100% height): Caption and interpretation region. Sponsor graphics are not allowed in this band during captioned sessions.
Within the bottom band, allocate sub-regions:
- Caption region: Bottom-centered, 80% width, 3 lines maximum, anchored at 90% viewport height. This matches the WebVTT region example’s bottom-anchored approach.
- Interpretation region: If a second language is delivered as text, place it above the primary caption region, 80% width, 2 lines maximum, anchored at 80% viewport height. If it is delivered as audio only, no visual region is needed.
- Sponsor region: Upper-right or upper-left of the middle band, 15% width maximum, 10% height maximum. This keeps it clear of the bottom band entirely.
If the sponsor contract requires a lower-third, place it at 70–75% height, full width, and treat it as a temporary overlay that suppresses captions for its duration. That is a worse outcome for accessibility, so the preferred fix is to renegotiate placement to the upper band. If renegotiation is not possible, the lower-third must not exceed 5% height and must not overlap the caption region’s top edge.
How to test the layout in 15 minutes
You need a test stream, a caption file with known line counts, and a way to composite the sponsor graphic. The test is not a substitute for a full rehearsal, but it catches the majority of overlay collisions.
- Generate a grid overlay. Draw horizontal lines at 15%, 75%, 80%, and 90% of the frame height. Draw vertical lines at 10% and 90% of the frame width. This is your safe-area reference. If you have access to a broadcast test pattern generator, ITU-R BT.1729 is the reference pattern for 16:9 and 4:3. If not, a simple PNG overlay in your streaming tool works.
- Load a caption file with maximum line count. Use a WebVTT file with cues that produce three lines in the caption region and two lines in the interpretation region. The W3C WebVTT specification’s region example is a useful starting point: two regions, 40% width, 3 lines, bottom-anchored.
- Composite the sponsor graphic. Place it at its contracted position. If it overlaps the caption region, you have found the bug before doors open.
- Check three aspect ratios. View the stream at 16:9, 4:3, and a portrait phone aspect ratio (approximately 9:16). Note where the caption region and sponsor graphic land in each. If the sponsor graphic disappears or the caption region is cropped, adjust anchors.
- Check platform UI. View the stream in the actual player used by attendees. Platform controls, chat overlays, and picture-in-picture buttons occupy screen space. If the caption region is under a control, raise its anchor by 5%.
- Record the result. Save a screenshot of each aspect ratio with the grid overlay. This is your baseline. If a sponsor changes their graphic mid-event, you can compare against the baseline in under a minute.
The entire test can be run with a 60-second looped video, a caption file, and a static sponsor PNG. It does not require a live speaker or a full rehearsal.
Reversible fixes when a conflict is found
Every fix below can be applied and reverted without rebuilding the stream layout.
- Move the sponsor graphic. Change its anchor from lower-right to upper-right. This is a one-line change in most streaming tools and is fully reversible.
- Reduce caption region width. If the sponsor graphic must stay in the lower-right, reduce the caption region to 60% width and anchor it at 10% from the left. This keeps captions clear of the graphic but reduces line length. Test with your longest cue to ensure it still fits in three lines.
- Raise the caption region. Move the caption anchor from 90% to 85% viewport height. This creates a 5% buffer above the bottom edge. It may conflict with platform UI, so test in the actual player.
- Suppress the sponsor graphic during captioned segments. If the sponsor contract allows, fade the graphic out when captions are active. This is the cleanest fix but requires a control path between the caption system and the graphics system.
- Use a separate interpretation region. If the interpretation feed is text-based, give it its own region above the primary captions. Do not stack them in the same region.
Each of these changes should be documented with the time, the person who made it, and the reason. If the change causes a new conflict, revert to the baseline screenshot and try the next option.
What to hand to the operator
The artifact below is a copyable safe-area checklist for the streaming operator or AV lead. It is designed to be pasted into a runbook or a shared doc. It assumes a 16:9 primary stream with optional interpretation and sponsor graphics.
STREAM LAYOUT SAFE-AREA CHECKLIST
Role: Streaming operator / AV lead
Version: 1.0
Last updated: [date]
BANDS (16:9 frame, height percentages)
- Top band: 0-15% — platform UI, event branding, top ticker
- Middle band: 15-75% — primary video content
- Bottom band: 75-100% — captions and interpretation
SUB-REGIONS (bottom band)
- Primary captions: bottom-centered, 80% width, 3 lines max, anchor 90% height
- Interpretation (text): above primary, 80% width, 2 lines max, anchor 80% height
- Sponsor graphic: upper-right or upper-left of middle band, 15% width max, 10% height max
PRE-EVENT TEST (15 minutes)
[ ] Grid overlay: lines at 15%, 75%, 80%, 90% height; 10%, 90% width
[ ] Caption file with 3-line cues loaded
[ ] Interpretation file with 2-line cues loaded (if applicable)
[ ] Sponsor graphic composited at contracted position
[ ] Viewed at 16:9, 4:3, and 9:16
[ ] Viewed in actual attendee player
[ ] Screenshot saved for each aspect ratio
CONFLICT RESPONSE
If sponsor overlaps captions:
1. Move sponsor to upper band (reversible)
2. If not possible, reduce caption width to 60% and anchor left
3. If not possible, raise caption anchor to 85%
4. If not possible, suppress sponsor during captioned segments
REVERT
- Baseline screenshots stored at: [path]
- Last known good layout: [description]
- Revert procedure: restore anchors to baseline values, reload stream layout
ESCALATION
- If captions are obscured for more than 30 seconds, notify accessibility lead
- If sponsor contract requires lower-third, notify event producer before doors open
The checklist is not a standard. It is a starting point that encodes the principle from WCAG 2.2: captions should not obscure or obstruct relevant information. The numbers are recommendations for a 1080p 16:9 stream; adjust them for your resolution and platform.
Questions that come up in the control room
Does WCAG require a specific caption position? No. WCAG 2.2 Success Criterion 1.2.2 requires captions for prerecorded audio, and the definition of captions includes the note that captions should not obscure or obstruct relevant information in the video. It does not specify pixels, percentages, or anchors. The safe-area model above is a practical implementation, not a conformance requirement.
Can I use WebVTT regions to enforce safe areas? WebVTT regions let you define width, line count, and anchor points. They are enforced by the player for that caption track. They do not prevent a separately rendered sponsor graphic from overlapping the region. You still need a layout agreement between the caption track and the graphics layer.
What if the sponsor contract requires a lower-third? A lower-third at 70–75% height will overlap a bottom-anchored caption region. The options are: renegotiate to an upper-band placement, reduce the lower-third to 5% height and accept that it may still overlap, or suppress captions during the lower-third. The last option is an accessibility failure. The first option is the only one that preserves both the sponsor placement and caption visibility.
How do I test on a phone without a phone? Use your streaming platform’s preview at a 9:16 aspect ratio. If the platform does not offer that, resize your browser window to a narrow portrait shape and check where the caption region and sponsor graphic land. The goal is to see whether the bottom band is cropped or covered by platform UI.
What if the interpretation feed is audio-only? Then no visual region is needed. The interpretation audio is mixed into a separate channel or delivered as a second audio track. The layout conflict only applies when interpretation is delivered as text or burned-in captions.
How often should I re-test? Re-test when the sponsor graphic changes, when the streaming platform updates its player, when the caption font size changes, or when a new aspect ratio is added to the distribution list. A 15-minute test before each event day is cheap insurance against a 30-second accessibility failure.
The sponsor bug is not the problem. The problem is that nobody defined where it was allowed to sit. Define the bands, test the composite, and keep a baseline screenshot. That is the whole fix.