Keyboard shortcuts #155
Comments
|
Note: in Readium "1" (cloud / web reader and Chrome app) a number of keyboard interactions / shortcuts are implemented in order to facilitate key-driven UI navigation. |
|
Reading the R1 document, I see mention of Windows function keys only where stated that F8 is not supported. So, first, should we support Windows function keys here ? then what is the list of function keys we should support, for which action (for which assistive technology)? |
|
From what I find on the Web, we could map some Windows function keys to useful actions: F1 | Brings up a Help window (but we don't have a Help so far) |
|
From George's comments on the use of Thorium vs Daisy tests, it seems we are lacking a keyb shortcut to move between chapters without going through the ToC. |
|
Only F6 seems really interesting in practice. But not easy to implement. Slack has this feature. F3: people use Ctrl-F in practice, and it does not seem really useful in the bookshelf view as the search field is always displayed. It will be useful for implementing search inside a book, later. |
|
How to do implement the F6 feature ? The F6 allow to focus on each main screen block at each hit |
|
Note that |
|
|
Common NVDA & JAWS Keystrokes(contributed by Prashant Verma, DAISY Consortium) For Reading Text, navigation in tables, navigation in browser window Insert key can be replaced with the screen reader modifier key (e.g. caps lock)
Tables
Quick keys for navigation in the browser The screen reader needs to be in the browse or virtual cursor mode
Use the above keys with Shift to move to the previous element |
|
Imported from #572 |
|
Note that at the time of writing, Thorium implements the following keyboard shortcuts in the reader window:
|
|
Also note that at the time of writing, Thorium implements the following keyboard shortcuts in the library window (catalog section, OPDS feeds):
|
|
On JAWS / Windows,
How should it work? |
|
With every screen reader there is a "start continuous reading" from current position. |
|
Usually SPECIAL_KEY + arrow-down (I use CAPS LOCKS, as I don't have INSERT) |
|
For JAWS, simply change this code (for example remove ALT, like we already do for MacOS VoiceOver): |
|
Some suggested keyboard shortcuts. I am thinking here of Windows: Ctrl + f4 (and maybe Ctrl + W and Escape) = close window, back to the bookshelf Items like TOC and go to page are within the navigation control, so I don’t know if it is possible to go straight to them, but if you can: Daniel also wondered about a ‘go to the main reading area’ key. Text smaller/bigger = ctrl + ‘-‘/'+' (same as Edge and many others) Thinking ahead: Getting to the Where am I? information is a common challenge, getting to it without losing the place in the text. Perhaps ctrl + i can also include the location information? Or ctrl _ shift + i? |
|
FYI: I am finalizing PR #958 |
|
The current set of keyboard shortcuts is described in this Wiki page: |
|
I am in the reader view, in the main content window enjoying my book with NVDA. I want to go back to my library (ideally there would be a shortcut for this), I press ctrl T and the focus moves to the top, but NVDA says 'blank'. I tab once, the button appears 'Skip to content' but there is no speech. I press again and I hear 'Back to the bookshelf'. Could the top landmark be labelled so it is spoken? Can you fix the silent 'Skip to content button'? |
|
-keyboard shortcuts using NVDA version 19.3 on Windows 10. Most of theshortcut keys worked as expected, except for these: -left or right arrow moves me to the next character. Ctrl+right arrow moves me to the next word, which is what is expected with a screen reader. |
|
Ctrl+T and CTRL Home do the same thing. Using a screen reader, CTRL+Home takes you to the top of the page. It seems that CTRL+T is a shortcut that could take a person to the table of contents. |
There is now |
This was fixed via afa6827 |
This is actually now a built-in feature in Thorium. I implemented support for "alternative" keyboard shortcuts for situations such as when arrow keys are effectively reserved by screen readers for their own top-level interactions. Note: if you have previously edited / customized your own keyboard shortcut scheme, you may need to reset the default preset using the dedicated menu in Thorium's settings section. See the full description in the wiki page: |
|
Confirming that the ctrl+w works great on my Windows 10+NVDA combination. Also the top landmark and skip to content are spoken- good job! Ctrl+PgUp and Ctrl+PgDn move to the next spine item, but the reading position is left in a strange place, Like on the same place on the page, but in the new document. I think that ideally the reading position will be the top of the new document. |
I'm not sure which revision of Thorium you used, but there is a fix for this problem in the develop branch (therefore available in the automated releases https://github.com/readium/readium-desktop/releases ). This fix is actually a pretty big leap forward, because it applies to any kind of content navigation, e.g. TOC or bookmark links from the navigation panel (Thorium's GUI), but also hyperlinks clicked directly from within EPUB documents, etc. The fix is actually a workaround which consists in "instructing" the screen reader to focus on a particular HTML element even if this element is not focusable, let alone keyboard-tabbable (note to developers: this is achieved using Now, the caveat is that because EPUB HTML documents are rendered within their own sandboxed webview / frame, the screen reader doesn't necessarily follows deep into the content. For example, Voice Over remains outside the frame container (just "above" it, where the "main" landmark is), whereas NVDA pauses but then automatically dives into the linked content (which is neat!). In other words, the UX with VoiceOver is to activate a TOC or bookmark link, then to wait briefly for the keyboard focus to be automatically placed immediately before the frame container (at which point NVDA kindly dives deep into the content), and as Voice Over stays there, simply tab once in order to get access inside the frame, directly on the first hyperlink which points to the exact link location (e.g. a particular chosen section from the TOC). Please try and let me know how it goes. This is a pretty heavyweight screen reader workaround, but so far the best I have found using trial and error (the main issue to solve being the transition from GUI to EPUB content inside the frame). |
The Eventually, this command may be used in the reader window's TOC (i.e. when a search feature is implemented there too), same with the bookmarks list, and of course the full text search inside publication contents. Note that eventually, |
If I understand correctly, |
Did you start NVDA before launching Thorium? This is important, because the Electron framework and the Chromium webview subsystem (which Thorium is based on) activate a special accessibility bridge when a screen reader is detected (apparently, this is because of significant performance loss when the screen reader layer is activated unnecessarily). |
|
PS: at this point I should come clean about the keys "page up/down" and "home" ... my primary keyboard does not actually support these keys (i.e. no physical buttons, and no virtual "function" key modifier to emulate the key code), so I tend to ignore these keys in my design decisions. Naturally, I added support for the alternative "page up/down" shortcuts because it made a lot of sense for inter-chapter navigation, but I haven't actually tested this myself (I just use the primary arrow keys shortcuts instead). So, your feedback is greatly appreciated :) |
|
Previous and next spine item shortcut seem backward. IMO PageUp moves forward (previous) in the book and PageDown (next) seems correct. What is there now is the opposite of how I view this. |
|
Hello,
I have the alpha 426. I have the same problem. I insert a bookmark in a chapter somewhere, normally several heading s down. I then navigate away to a different chapter. I go to the bookmarks, and I get taken to the beginning of the chapter.
Best
George
From: Daniel Weck <notifications@github.com>
Sent: Wednesday, March 11, 2020 4:16 AM
To: readium/readium-desktop <readium-desktop@noreply.github.com>
Cc: George <kerscher@montana.com>; Manual <manual@noreply.github.com>
Subject: Re: [readium/readium-desktop] Keyboard shortcuts (#155)
…-Ctrl+B inserts a bookmark. When I go to that bookmark, I am at the beginning of the spine item where I left the bookmark.
I'm not sure which revision of Thorium you used, but there is a fix for this problem in the develop branch (therefore available in the automated releases https://github.com/readium/readium-desktop/releases ).
This fix is actually a pretty big leap forward, because it applies to any kind of content navigation, e.g. TOC or bookmark links from the navigation panel (Thorium's GUI), but also hyperlinks clicked directly from within EPUB documents, etc.
The fix is actually a workaround which consists in "instructing" the screen reader to focus on a particular HTML element even if this element is not focusable, let alone keyboard-tabbable (note to developers: this is achieved using tabindex with -1 value, as well as a temporary visual clue to indicate link destination, much like CSS :target pseudo-class).
Now, the caveat is that because EPUB HTML documents are rendered within their own sandboxed webview / frame, the screen reader doesn't necessarily follows deep into the content. For example, Voice Over remains outside the frame container (just "above" it, where the "main" landmark is), whereas NVDA pauses but then automatically dives into the linked content (which is neat!).
So, for Voice Over, and just for general usability, there is now a special link inserted right at the beginning of EPUB HTML documents, which (much like the "skip to content" link in the GUI) acts as a redirector to area of interest, in this case: the currently-linked anchor in EPUB documents (for example, the last TOC destination that was clicked, or bookmark, or current reading location, or followed hyperlink within HTML documents).
In other words, the UX with VoiceOver is to activate a TOC or bookmark link, then to wait briefly for the keyboard focus to be automatically placed immediately before the frame container (at which point NVDA kindly dives deep into the content), and as Voice Over stays there, simply tab once in order to get access inside the frame, directly on the first hyperlink which points to the exact link location (e.g. a particular chosen section from the TOC).
Please try and let me know how it goes. This is a pretty heavyweight screen reader workaround, but so far the best I have found using trial and error (the main issue to solve being the transition from GUI to EPUB content inside the frame).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#155> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABW4OSBCBRRVCPBKC74DH4DRG5QFVANCNFSM4FCS2VSA> .
|
No problems, I will swap them around. |
Ah, yes, this is a tricky general problem which is currently unresolved. Basically, a screen reader moves its "focus" (i.e. reading location) outside of the visible viewport of the HTML document, but unfortunately the DOM does not receive notifications (e.g. such as "scroll" events) that would allow the application to track the screen reader's reading position, which would then enable the application to bring the correct HTML elements into view (i.e. to synchronize the application's own record of the reading location, based on what is visually shown on the screen, either in paginated mode or via a more traditional scroll view). George, using your screen reader, are you able to generate a mouse click inside the currently-narrated HTML element? If so, then Thorium should be able to detect this "virtual" mouse click, which will then set the reading location to this exact spot. Then (after a few milliseconds), just hit |
|
Regarding placing the mouse cursor and then clicking onto the HTML element that the screen reader is currently reading aloud, I tested on Mac OS with Voice Over, using the default VO "activation key" which is
Unfortunately, the problem remains, because the click may in fact occur in an unexpected / incorrect area of the application user interface, due to the webview not scrolling automatically to where the screen reader is currently talking. The same problem exists in a regular web browser, in cases where a few pixels of the paragraph being read are visible, but overall the text content is hidden / overflows beyond the visible viewport. The net result is that the "click on HTML element" technique cannot be reliably used to set a bookmark on an accurate location in the publication document. |
|
Hello,
What about highlighting some text and even copying it to the clipboard? This might be more like an annotation, but if it gives us focus, that could work. This may have an added benefit of the bookmarks getting text associated with it instead of just a number, which is difficult to track if you have a bunch.
Best
George
From: Daniel Weck <notifications@github.com>
Sent: Thursday, March 12, 2020 2:24 AM
To: readium/readium-desktop <readium-desktop@noreply.github.com>
Cc: George <kerscher@montana.com>; Manual <manual@noreply.github.com>
Subject: Re: [readium/readium-desktop] Keyboard shortcuts (#155)
I insert a bookmark in a chapter somewhere, normally several heading s down. I then navigate away to a different chapter. I go to the bookmarks, and I get taken to the beginning of the chapter.
Ah, yes, this is a tricky general problem which is currently unresolved. Basically, a screen reader moves its "focus" (i.e. reading location) outside of the visible viewport of the HTML document, but unfortunately the DOM does not receive notifications (e.g. such as "scroll" events) that would allow the application to track the screen reader's reading position, which would then enable the application to bring the correct HTML elements into view (i.e. to synchronize the application's own record of the reading location, based on what is visually shown on the screen, either in paginated mode or via a more traditional scroll view).
George, using your screen reader, are you able to generate a mouse click inside the currently-narrated HTML element? If so, then Thorium should be able to detect this "virtual" mouse click, which will then set the reading location to this exact spot. Then (after a few milliseconds), just hit CTRL + b in order to place a bookmark there.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#155 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABW4OSHYM6UZSWIZNWZVQCDRHCL3LANCNFSM4FCS2VSA> .
|
OS: Windows 10
Assistive technology: NVDA 2018.1.1
It is quite difficult to move in the UI between panels (TOC, pages, content, header): it would be very useful to implement the keyboard shortcut F6, that is "native" in Windows.
The text was updated successfully, but these errors were encountered: