iFrame video becoming a keyboard trap

Hi MettaLash​ 

I think the important thing here is to test the whole keyboard path, not just whether the video itself can be controlled.

After Tab enters the YouTube player, keep pressing Tab and check whether focus eventually returns to the Rise content. If there are many unexpected stops inside the player, that can make the experience feel like a keyboard trap even though the video controls themselves are keyboard accessible.

Articulate also confirmed that some of those extra focusable elements come from the YouTube player rather than Rise.

Their suggested rel=0 parameter may reduce some of the extra stops, but I’d still test the published course with the keyboard afterward.

This A11yCheck guide has a simple keyboard-trap testing workflow that may help:

Keyboard Navigation Guide — A11yCheck