marcellamaki
commented
2 years ago @radinamatic -- just clarifying if this is specific to the custom content renderer that we added. and @rtibbles -- do we have any idea of who might be using this so far? (trying to assess prioritization for the upcoming a11y patch)
Observed behavior
When keyboard users open any resource, they should be able to navigate in and out the renderer frame, and interact with the content inside. This is valid for both normal view and the fullscreen view.
After re-reading the specs and doing more research, I was not able to find much normative requirements regarding where should the focus be once the user tabs into an
iframe, much less where it should be when the embedded content is in fullscreen.When talking about the modal dialogs, the recommendation is as follows:
Comparison of embedded content in fullscreen with the modals comes to mind because the keyboard user is temporarily constrained to interact only with content that is inside the modal or frame in fullscreen. However, I've also found recommendations to avoid trapping the focus inside the
iframe.Regarding our existing content renderers, at this point I don't see problematic that, once the fullscreen is activated, the focus remains on the Exit fullscreen button in the renderer topbar, provided that:
Chances are keyboard-only users know how to enter and exit the fullscreen, and will suffer more not knowing where they are if the focus visual indicator is missing.
Below comments are valid for both normal and the fullscreen view, and now I'm thinking I should open them as separate issues for each renderer.
- Flexbook: OK
- PhET: not all sims are navigable by keyboard, but even in case of those that are, it seems impossible to navigate inside the frame with the keyboard (after the View/Exit fullscreen button, the following TAB key press focuses on the license details below the renderer like for the PDFs).
- Blockly: Possible to navigate inside the frame, but content is not really navigable, drag & drop here is a massive challenge, not much we can do about.
- PLIX: Possible to navigate inside the frame, scroll the up and down, but otherwise the content is not navigable (what looks like a button is not really actionable with the keyboard 🙄) - again, not much we can do about.
As for the new custom navigation channels, it's hard to recommend anything specific without having more than our super well designed and awesome one to look at... 🙂
Is the topbar going to remain visible at all times? If yes, than we can consider the back arrow button as the equivalent of the Exit fullscreen button in our current renderers topbar, and the points 1 & 2 above should still apply. If not, then the creators of these channels should implement another way to exit the fullscreen and return to the list of channels in Learn.
Ultimately, if the sighted keyboard-only user has a clearly visible, tabbable and actionable path to exit the fullscreen (either with the permanently visible topbar, or a custom Exit fullscreen element inside the channel frame), it might not be a total anti-pattern to place the focus directly inside the
iframeupon entering the fullscreen. For screen reader keyboard users benefit, we might consider providing a dedicated keyboard shortcut to exit fullscreen.Errors and logs
…
Expected behavior
Seamless access in & out of the content renderers, as well as interaction with the elements inside the
iframe. …User-facing consequences
Bad user experience for keyboard-only users. …
Steps to reproduce
…
Context
cc @rtibbles @jamalex