How to Test YouTube Videos in Rise for Keyboard Accessibility

Questions answered by this guide

• ?Is an embedded YouTube video in Rise a keyboard trap?
• ?Why does Tab need so many presses to get past a YouTube video?
• ?Does rel=0 remove related videos from an embedded YouTube player?
• ?How do I test keyboard access on an embedded video in Rise?
• ?Should I use Rise's Embed block or the native Video block for YouTube?

What you'll learn

• A true keyboard trap means focus can never leave using the keyboard. Needing many Tab presses is a different, still real, problem
• The extra Tab stops inside a YouTube embed come from the YouTube player itself, not from Rise
• Test the published Rise course with Tab and Shift+Tab, not just the authoring preview
• rel=0 no longer removes related videos, it limits them to the same channel

What's inside

Rise developers embedding YouTube video who need to test whether keyboard focus behaves acceptably

1. 01Short answer
2. 02Is this really a keyboard trap
3. 03Why embedded YouTube content behaves differently
4. 04How to test it
5. 05What happens after the video ends
6. 06YouTube related-video settings and rel=0
7. 07When to consider a different approach
8. 08Common mistakes
9. 09Practical checklist

Why it matters

A keyboard-only learner who gets stuck on a video, or who has to press Tab a dozen times to get past one, is having a genuinely bad experience either way. But the two situations are not the same problem, and treating them the same leads to the wrong fix. A true keyboard trap, where focus can never leave, is a WCAG 2.1.2 failure, and something is broken. A large number of unexpected Tab stops inside a working YouTube player is a usability problem you may not be able to fix directly, because the player is YouTube's, not yours. Testing the actual keyboard behavior tells you which situation you have before you spend time on a fix that will not work.

When you'll encounter this

• You embedded a YouTube video in a Rise Embed block using iframe code and someone reports trouble tabbing past it.
• A learner or reviewer says keyboard focus gets stuck on a video.
• An accessibility review flags an embedded video and you need to confirm what is actually happening before responding.
• You are deciding between Rise's native Video block and a custom Embed block for a YouTube video.

Examples

Best practices

• Test the published Rise course, not just the authoring preview. Start just before the video, use Tab only, and note exactly what receives focus at each press: the video itself, then whatever controls the YouTube player exposes (play, pause, mute, captions, settings, fullscreen, and similar), then whatever comes after. Do not assume, watch it happen.
• Confirm whether focus actually leaves the player. Keep pressing Tab past the video. If focus reaches the next Rise block or control, focus left the component, and by WCAG 2.1.2's own definition that is not a keyboard trap, even if it took many presses to get there. If Tab gets stuck and never reaches anything past the video no matter how many times you press it, that is a real keyboard trap.
• Test Shift+Tab too. Confirm you can move backward out of the player the same way you moved forward into it, not just forward.
• Test what happens after the video finishes playing. Some players show an end screen with additional video suggestions or replay controls, which can add more focusable elements than the player had while playing.
• The extra Tab stops inside a YouTube embed come from the YouTube player itself, confirmed directly by Articulate in the original community report on this issue, not from anything Rise added. This matters for what you can actually fix: you can change how the video is embedded, but you cannot change how YouTube's own player handles keyboard focus internally.
• Know what rel=0 actually does before relying on it. YouTube's own developer documentation is specific here: as of a 2018 platform change, rel=0 no longer removes related videos from the end screen. It limits the related videos shown to ones from the same channel as the video being played. It does not reduce the number of focusable controls in the player itself, so it is not a fix for excessive Tab stops, only for which videos get suggested afterward.
• Prefer Rise's native Video block over a custom Embed block when the content allows it. A native Video block, added by pasting the YouTube URL rather than iframe embed code, is Rise's own supported way of adding video and gets Rise's own handling. A custom Embed block just renders whatever HTML you paste in, iframe included, with no changes from Rise. This does not guarantee a different Tab-stop count, since the underlying YouTube player is still YouTube's, but it is worth testing directly since it is a genuinely different embedding path.

Common mistakes

• Calling any embedded video with many Tab stops a keyboard trap without confirming whether focus actually leaves.
• Testing only in Rise's authoring preview instead of the published course.
• Assuming rel=0 removes related videos, or that it reduces the number of focusable controls in the player.
• Trying to fix YouTube's own player behavior directly, when the actual options are how the video is embedded, not the player's internals.
• Not testing Shift+Tab, and only checking forward Tab movement.
• Not retesting after changing the embed code or switching between an Embed block and the native Video block.
• Assuming the same behavior holds across every browser and device without testing the ones your actual learners use.

Practical checklist

• Open the published Rise course, not the authoring preview.
• Start just before the video and use Tab only.
• Record exactly what receives focus at each Tab press.
• Confirm whether focus eventually leaves the video player.
• Test Shift+Tab moving backward out of the player.
• Test what happens after the video finishes playing.
• Check whether the current embed uses rel=0, and confirm what it actually changes.
• Test the browser and device your learners actually use.
• Retest after any change to the embed code or block type.
• Record the actual learner experience, not just pass or fail.

Frequently asked questions

Summary

Needing many Tab presses to get past an embedded YouTube video in Rise is not automatically a keyboard trap. A true keyboard trap means focus can never leave using the keyboard, which is a WCAG 2.1.2 failure. A large number of unexpected Tab stops inside a working player is a different, real usability problem that comes from the YouTube player itself, not from Rise. Test the published course with Tab and Shift+Tab, confirm whether focus actually leaves, and know that rel=0 only limits which related videos are suggested, it does not reduce the player's own Tab stops. Use that evidence to decide whether the current embed is good enough or whether a different approach is worth testing.