set role="application" on toolbar and sidebar to force screen readers to use focus mode in those areas since reading mode is not applicable here and one should not have to manually switch to focus mode
made outline values visible to screen readers
improved aria-live message announced during search navigation to include the page number as well as the snippet of the result
added role="navigation" to start containers of epub ranges so that screen readers indicate when one moves to a new page. It also enabled navigation via d/shift-d for NVDA and r/shift-r for JAWS to go to next/previous page as with PDFs.
added a state variable a11yVirtualCursorTarget to record which node the screen readers should place its virtual cursor on next time the focus enters the reader. It forces virtual cursor to be moved onto that node, as opposed to landing in the beginning of the document. It is currently used to make sure screen readers begin reading the chapter/section selected in the outline, as well as to place virtual cursor on the last search result. On scroll, a11yVirtualCursorTarget is cleared to not interfere with mouse navigation.
Example of the virtual cursor jumping to the top (still this PR but without virtual cursor handling): recording
Current behavior: recording. Notice how the screen reader does read roughly where we left off in the search and where the chapter begins after outline navigation.
I think this already would be a bit improvement for the usability issues described in https://forums.zotero.org/discussion/comment/469784/#Comment_469784. There are a few other instances when it might be good to explicitly tell screen readers where to place the virtual cursor, such as when the page input is changes and when we move to the beginning/end of the document with Home/End shortcuts. But I wanted to check in to make sure this is on the right track.
@AbeJellinek, @mrtcode let me know what you think!
a11yVirtualCursorTargetto record which node the screen readers should place its virtual cursor on next time the focus enters the reader. It forces virtual cursor to be moved onto that node, as opposed to landing in the beginning of the document. It is currently used to make sure screen readers begin reading the chapter/section selected in the outline, as well as to place virtual cursor on the last search result. On scroll, a11yVirtualCursorTarget is cleared to not interfere with mouse navigation.Example of the virtual cursor jumping to the top (still this PR but without virtual cursor handling): recording
Current behavior: recording. Notice how the screen reader does read roughly where we left off in the search and where the chapter begins after outline navigation.
I think this already would be a bit improvement for the usability issues described in https://forums.zotero.org/discussion/comment/469784/#Comment_469784. There are a few other instances when it might be good to explicitly tell screen readers where to place the virtual cursor, such as when the page input is changes and when we move to the beginning/end of the document with Home/End shortcuts. But I wanted to check in to make sure this is on the right track.
@AbeJellinek, @mrtcode let me know what you think!
Fixes: https://github.com/zotero/zotero/issues/4515