Creating range or selection when text is selected by keyboard

[alxh0610]

Hi,

is it correct that Thorium doesn't create a range object when the content is selected using a keyboard?

I am currently playing around creating a tool that is also as accessible as possible. That's why I wondered whether those informations (selection, range object ...) shoud not also be generated when using a keyboard, e.g. by blind users that can't use a mouse.

[danielweck]

Hello, Thorium does process the text selections created by users inside HTML documents (i.e. "DOM ranges"), via the mouse pointer (click and drag, double-click) or keyboard cursor (shift arrow). This information is currently only used to automatically generate a title when the user adds a bookmark. Side note: we plan to implement a document annotation feature, but we do not have a precise timeframe yet.

Note that "text selections" created by screen readers are typically not DOM ranges, they are usually generated inside the private "virtual buffer" world of each screen reader implementation (NVDA, JAWS, Narrator, VoiceOver all do things slightly differently, for legacy reasons).
In other words, "text selections" created by screen readers via the keyboard cursor are typically not exposed to the Javascript Web APIs that Thorium leverages inside rendered HTML documents. Thorium is simply unaware that such selections even exist. Some screen readers implement special HTML interaction modes, I believe. There are workarounds, but they are poorly documented as far as I know.

One possible avenue is for Thorium to force a special HTML "content editable" mode when detecting screen reader interaction, which would enable a proper "edit" text cursor that screen readers typically handle better. However this would really be a heavyweight change to the normal read-only rendering method, which would be very disruptive in relation to all other existing features. So we would need to trigger this mode only in special user interaction cases, requested by users (e.g. a keyboard shortcut that temporarily activates "content editable" on the currently-rendered document, so that the user can create an editable selection that Thorium could then map with a read-only equivalent selection in the original document). This would be quite costly to implement correctly, I would personally prefer if screen readers implemented DOM text selection properly.