Escapibility of iframe’s resources when navigating using a keyboard

[JayPanoz]

When tabbing into an iframe, interactive elements such as links are focused. In case a resource has a lot of links, you have to go through a significant amount in order to tab into previous or next arrows.

There should be a way to escape the iframe’s resource in order to navigate affordances.

[danielweck]

Not saying this is the best design choice, merely stating what Thorium does, FYi: there is a keyboard shortcut to land the focus just "before" the iframe, i.e. still inside the host app layer but a tab away from reaching into the very first focus anchor inside the iframe-hosted document - which is actually a hyperlink artificially injected by the navigator as the body's first child, in order to allow the user to jump to the "last focused location" in the document, essentially the "current reading location" (which is not necessarily tabbable, thus the indirection).

[JayPanoz]

@danielweck We anticipated during the Web Call that this will be a discussion where the Thorium experience can bring notes and ideas so it’s great to have this quick feedback. 🙏

We’re expecting it to be one of the longer-term discussions as well so I’ll make sure to keep you up to date if needed.

[danielweck]

...so, I think there is a cognitive / UX advantage to keyboard shortcuts dedicated to landing the focus on special areas, as opposed to "escape" semantics that would skip over a bunch of focusables in order to land on the "next" group of tabbables.

Screen readers do handle escaping groups of UI controls pretty intuitively, but the navigation granularity is much finer than during general keyboard usage with tab and arrow keys (though of course tab/arrow cycling can end-up trapping users inside groups if implemented incorrectly ... or because of bugs :)
(there is one such bug in Thorium currently because of the GUI lib integration)

[JayPanoz]

Before I forget since that was mentioned during our Web call on Monday and so that I can get back to it, React Aria has some experimental function related to iframe in their useFocusVisible hook.

[danielweck]

Here is a significant Thorium upgrade (in fact, strictly-speaking this is a breaking change in the navigator-app roundtrip mechanics, but in practice not a problematic update as the Electron navigator is only used in Thorium). I am posting this here FYI.

@HadrienGardeur in reference to your question #45 (comment) feel free to try a newer Thorium revision:

https://github.com/edrlab/thorium-reader/releases

@gautierchomel I think you will need to update Thorium's documentation accordingly.

The special "underscore" invisible hyperlink that was injected at the begining of the body element of all publication XHTML documents is no more (side note: @panaC , I updated the annotation DOM parser code accordingly in your PR). The user needed this jump-link in order to manually transition from the application layer / content host ... into the Electron webview / shadow-DOM-iframe (via coarse shift/tab key strokes, or using finer-grain screen reader navigation commands) at the exact current reading location (well, the atom is a DOM element when it comes to keyboard focus, so not as precise as a DOM Range).

This trick worked well in Thorium v2 where the GUI was simple and hand-orchastrated to work with the navigator's keyboard focus "push" model (essentially, "focus stealing" at key steps in the lifecycle of the managed Electron webview, such as when repositioning the "current reading location") ... but in Thorium v3+ (to be precise, the upcoming version) we now have an "inversion of control" so that the new, more sophisticated refactored GUI can reliably apply its own keyboard focus heuristics, and whenever appropriate to explicitly request keyboard focus redirection into the content rendering area.

For example, when the navigation menu is a transient popup modal, keyboard focus redirection is automatic when the modal closes ... but conversely, a docked navigation menu does not lose its current focus context, and the user must explicitly request focus change if they wish to actually navigate into the content. Note that we currently don't differentiate screen reader users from regular keyboard users, but this could be discussed. Sighted keyboard users benefit from the preservation of focus context inside the navigation menus as they can visually observe the changed document reading location. However, blind / screen reader users could benefit from automatically receiving immediate feedback when forcing the focus into the targeted HTML document. For now, we are making the experience consistent so that all keyboard users remain capable of browsing the navigation menus without focus steal in the content rendering area.

The function of the CTRL-F10 keyboard shortcut has changed, now that the tab-next-into-the-special-underscore-link method does not exist anymore. There is now less friction in the user experience, as the keyboard focus not only moves to the landmark "above" the content iframe (i.e. still in the application layer / webview host), it also moves "on" the actual shadow-DOM-iframe and causes screen readers to automatically sync their state with the currently-focussed element inside the HTML document. There is an additional SHIFT-CTRL-F10 keyboard shortcut that programmatically forces the focus deeper into the HTML document, just in case some screen readers don't figure out the "activeElement".

I only tested this in the Electron navigator, so I don't know that this technique would work in a generic web reader. Essentially, invoking .focus() on an HTML element (with or without automatic scroll-into-view) does not redirect focus from the iframe host (i.e. the application layer) into inside the actual iframe document (i.e. the rendered EPUB document). I am not sure this follows the documented "activeElement" semantics, maybe the behaviour is specific to out-of-process iframes nested in shadow-DOM implemented by Electron webview. For Thorium this is a net positive because it allows us to maintain the internal focus state of the rendered HTML document (we inject tabindex -1 to any non-tabbable / non-focussable DOM elements, so that they can be focussed programmatically but not via tab keystrokes), while not interfering with the application's own GUI keyboard focus handling (for example pop over modal or menu returns). Then, whenever needed, the app can request focus into the webview which already has its "current reading location" set and focussed, on standby (as previously mentioned, we also provide an additional "force" shortcut to ensure that screen readers reach where they need to be in the DOM).

I hope this all makes sense and can be helpful in this "playground" web reader discussion :)

[HadrienGardeur]

Thanks @danielweck for all these additional details, it's quite helpful.

For example, when the navigation menu is a transient popup modal, keyboard focus redirection is automatic when the modal closes ...

Do you keep the focus on actions when the popup/popover is dismissed (Esc)/closed? Or do you automatically switch it back to the content again?

but conversely, a docked navigation menu does not lose its current focus context, and the user must explicitly request focus change if they wish to actually navigate into the content

In this case, I would imagine that instead of hiding the docked sheet/component, Esc would switch the focus back to the content itself.
It's fairly contextual though:

• if I just opened a docked sheet, it could make sense to escape back into the list of actions
• but if it's been opened for a while and managed to tab back into it, escaping should definitely go back to content