@fastfinge@GamingWithEars@dhamlinmusic@lynessence@pixelate@quanin@mcourcel And, a PDF reader that can also fill out forms is a fundamentally different kind of user interface than the one implemented by Paperback (and Christopher Toth's QRead before it). Realistically, for anything besides Acrobat/Adobe Reader or Chromium itself to do it accessibly, it would probably entail an embedded web browser engine and converting PDF to HTML rather than a single text edit control.
@matt@dhamlinmusic@lynessence@pixelate@quanin@GamingWithEars@mcourcel This is also why none of the accessible open source ebook readers support Math content, or cope with footnotes and endnotes correctly. Modern ebooks really, really need to be loaded in an HTML webview. The issue is that I want continuous reading, and none of the HTML implementations like Thorium support that.
@fastfinge@dhamlinmusic@lynessence@pixelate@quanin@GamingWithEars@mcourcel By continuous reading, do you mean fine-grained saving of your position in the document, or something else? If the former, then yes, the fundamental problem is that Windows screen readers don't allow the application to know precisely where the virtual cursor is located. I ran into that in Serotek's DocuScan Plus; I had committed to an HTML view, then could only do bookmarks approximately.
@matt@dhamlinmusic@lynessence@pixelate@quanin@GamingWithEars@mcourcel I mean that I want to press NVDA+down arrow, start reading, and not have to press next page or next chapter constantly. But doing that requires loading the entire book into the HTML webview control, and now you get massive lag for various API related reasons. You can't do some sort of autoscroll to load content as you need it, because screen readers doing say all don't always update the focus position correctly, so you can't tell when they're about to hit the end of the currently loaded content. This is a thing I've thought about, and chatted with some folks about over coffee/beer.
@matt@dhamlinmusic@lynessence@pixelate@quanin@GamingWithEars@mcourcel IMHO those are larger problems than bookmarking. We can get close enough (nearest paragraph) bookmarking in a webview. And that would be fair exchange to have working links, footnotes, endnotes, media, math content, and all the rest. But I can think of no way with current screen readers and API's that we can do autoscroll. Kindle manages it, but they're doing...something custom that I don't know anything about. And I'm just not willing to give that up.
@matt@dhamlinmusic@lynessence@pixelate@quanin@GamingWithEars@mcourcel Nope. Direct TTS output is available if you want that. But both NVDA and jaws present kindle ebooks in some sort of custom virtual buffer. It supports pressing enter on links, autoscroll during say all, etc.
@matt I've honestly been afraid to look at it too close. Kindle Cloud broke accessibility because people started using it as a way to remove Kindle DRM now that the other popular methods don't work. If I wanted too, it would be pretty easy to create a new synth driver for NVDA that uses say all as a way to extract the text from a Kindle book. Here's the current technique they're using, if you're curious: blog.pixelmelt.dev/kindle-web-drm/
@fastfinge For the record, my interest wouldn't be in bypassing DRM, but in making it easier for applications and toolkits other than the big two Windows browser engines to trigger the virtual cursor behavior in JAWS and NVDA.
@matt When you first open Kindle for PC, your ebook library is shown in what is just a standard web view. So they do have a full browser engine as part of Kindle. But they don't seem, from what I can tell, to be using it to show the actual ebook.
@fastfinge Thanks. Bottom line: The virtual cursor implementation that NVDA uses for Kindle is hard-coded to the Kindle app, and based on that window class name, the same is probably true for JAWS.
@matt Yup. So in short, if I wanted to make another ebook app that worked the way Kindle does, I'd need to write a custom virtual cursor implementation for NVDA to work with it.
@fastfinge NVDA is modular enough that the implementation work in NVDA, or in an add-on, wouldn't have to be done from scratch, but yes, as far as I can tell, some app-specific or toolkit-specific work would currently have to be done. And for JAWS, that would basically mean being big enough to get onto Vispero's development roadmap.
