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?
@nolan 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.
@jscholes 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!
@nolan @jscholes This is, as far as I know, the primary reason why QRead, Christopher Toth's book reading app for Windows, uses a rich edit and not a web view; the rich edit has a caret, so the application can save and restore its own cursor position. The screen reader's virtual cursor is invisible to the application.
@matt @nolan @jscholes You can sort of try and hack this by giving all your divs a negative tabindex and then calling .focus on them, we tried this a few years ago when thinking about QRead web, but the biggest problem is the inaccuracies. I'm okay with being a paragraph back in a book, but not a paragraph forward, and because of the nature of screen readers and the DOM we'd likely get the latter in a lot of cases.
@nolan 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.