Tonight's weird tech question: Is there a DOM API/JavaScript hack of some sort I can use to track, save, and restore the screen reader's position in a relatively static HTML document? Say, for instance, you were reading a book in an HTML document with your screen reader, then closed the window. Now imagine that window was an app, and I wanted to make certain your position was restored when that app opened again. Is there an API I could hook into for that?
It's not quite focus, because that'd require tabindex. It probably isn't one of the text properties, right? Because you're not exactly in charted territory when you're arrowing through a paragraph not in a writable element like an input or textarea. Can I track that at all?
Peter Vágner reshared this.
James Scholes
in reply to Nolan Darilek • • •No. The closest thing to an automatic solution to that is probably tracking scroll position, and you may or may not be able to make that more granular by making the text quite big (I haven't tried). But even then, the best you're gonna be able to achieve is to track the closest element and put focus back there to restore the position, without character-level accuracy.
I know that Mozilla and NV Access have done some work to allow selection of text within the NVDA browse mode buffer to be communicated to the browser for on-page actions that require a selection. But:
1. That doesn't work across browsers; and
2. your use case seems targeted at reading, not selecting.
Nolan Darilek
in reply to James Scholes • • •Thanks, that's what I was thinking. And just to check an assumption, setting the scroll position won't update the screen reader's position in the doc--I'd have to use focus shenanigans for that?
For context, this is my attempt at a document reader that saves/restores position when the document is closed/reopened. I don't think I need character accuracy, or even paragraph accuracy, if I can open books or longer documents to roughly where the reader closed out.
FWIW I'm not just being lazy and asking, I'm trying right now and it isn't working, which I suspected it wouldn't. It's also possible I'm using my web framework wrong or that something is behaving silly under Linux.
Thanks again!
Matt Campbell
in reply to Nolan Darilek • • •Nolan Darilek
in reply to Matt Campbell • • •Quin
in reply to Matt Campbell • • •James Scholes
in reply to Nolan Darilek • • •That's mostly correct.
There are some instances in which a webpage can move the scroll position without explicitly setting focus to the target element, and have the screen reader's reading position follow. But that can be less reliable, particularly if the target element is visually obscured, and setting focus is a more explicit/guaranteed way to do it.
Note that if you're setting focus to things like headings and paragraphs that aren't focusable by default, you'll need to dynamically inject a `tabindex="-1"` for the best results.
Nolan Darilek
in reply to James Scholes • • •