First of all, the accessibility work done on Joplin is really amazing, I'm a blind user, I have been playing with the apps in the recent days and I'm genuinely impressed. Awesome work! Thank you so much for doing this! I absolutely love it.
To the point. Would it be possible to add a shortcut which would focus into the displayed note content area? Sort of like the "Jump to the text" link you usually see on various news websites, just in form of a shortcut.
Currently, we have one for jumping into the note list, the notebook tree, and the note content is the last missing piece.
There is a shortcut for focusing the editor, which is good when I want to edit the note, but for just reading, the rendered area is the place to use.
Right now, I include a level 1 heading in my notes and afterwards jump to them using the screenreader's command for focusing level 1 headings. But this only works if I add the heading when creating the note as mentioned. A dedicated command would be a more universal solution, and would allign with having shortcuts for focusing the important Joplin panels.
Yes, this is a brilliant idea! I would certainly use this as well. Joplin is my new favorite notetaking app! I wish I knew about it when I was in college.
For now, here are two keyboard shortcuts that should do similar things:
1. Changing focus with esc-tab
In the Markdown editor, pressing escape, then tab moves focus to the next item ā pressing escape prevents the next tab press from indenting. By default, the viewer is the item in the focus order after the editor.
Note: In the latest pre-release ctrl-m (cmd-m on MacOS) toggles whether pressing tab indents or moves focus. This might be more convenient than pressing escape then tab to move focus.
2. Hiding the Markdown editor
By default, ctrl-l (I think this is cmd-l on MacOS) cycles through a few different layouts for the editor/viewer region
(Caution: At present, not all of these state changes are announced by screen readers):
Editor and viewer visible.
Viewer hidden, editor visible.
Note: If the editor was previously focused, this state change is not currently announced by screen readers.
Viewer visible, editor hidden.
Editor and viewer visible.
Note: If the viewer was previously focused, this state change is not currently announced by screen readers.
The viewer area is not actually a focusable object for the tab navigation, which is correct, because it's not an interactable component. So the user as of now needs to press Orca+A / Escape to switch the screenreader to browsing mode, and then either arrow down to the viewer, or find the first element the user knows is present in the note.
Additionally, most of the time the user will need to jump into the viewer from the note list, where there are (rightfully) quite a few objects in the way.
That's why having a separate shortcut would not just speed things up, but also make the screenreader able to automatically switch between the focus / browse mode of interaction and thus spare the user some Orca+A / Escape key presses.
Thanks! The Ctrl+L shortcut makes the trick quite well, although it needs to be pressed twice to reach the note viewer from the editor. But it properly switches you back well to the editor from the note viewer.
You may reduce the number of shortcut presses by choosing only 2 screens you need. Follow Joplin menu, then View, then Layout button sequence, then choose "Editor / Viewer"
Actually, most of the jumps into the viewer are made from the note list, since for a blind person that is the equivalent of moving the eyes from choosing the note they're interested in into the content they're interested in.
Changing the layout is a nice and clever hack, but only for moving between the editor and the viewer, and it's sort of like rearranging the walls of a building every time you want to move from one room to another.
So, for covering the most common use-case and polishing the editing experience, the shortcut would be an ideal solution.
Would it be useful for the shortcut to jump to (roughly) the editor location in the viewer? (Or just the top?)
For example, if I had the following note:
...a large amount of text...
1. This is a numbered list.
2. Suppose the cursor is in this list item.
...more text...
where the editor cursor is somewhere in item 2, would it make sense for the shortcut to jump to item 2 in the viewer? (Or should focus jump to the top?)
Personally, I think bringing the focus directly to the viewer at the same location as the cursor in the editor could indeed be an advantage. Then, we could choose ourselves whether we want to scroll all the way up or not.
That's a good question. I think the ideal solution would be to roughly follow what the app does. I.E. if the viewer copies the position of the cursor in the editor for the sighted users, and Joplin does have the technical means to identify the rendered element corresponding to the current cursor position, then it sounds great to auto-send the focus into that specific area. On the other hand, when the app displays the note on its start, like if the user opens up a note from the note list, then the blind users would likely also expect landing on the beginning of the content.
In other words, if it's reasonable, you can simply copy what Joplin already does for the sighted.
If there were obstacles, like not having the API for calculating MD -> HTML relations, jumping simply to the start would also be a significant improvement. As I mentioned before, people will likely most commonly jump between the note list and the note, where I think landing on the start is the expected behavior, which is much simpler to implement.
I agree with your comments.
Iām experiencing a focus issue using the current pre-release with the VoiceOver screen reader on MacOS. If I use the keyboard shortcut to jump to the notes list and then use the up or down arrow keys to move through the list I can only move to the previous or next item in the list and the focus jumps to the note body. This is unexpected behavior and a major efficiency frustration since there is a keyboard shortcut to jump to the note body when desired.
For sighted users, Joplin syncs the scroll position between the editor and viewer. Making it possible to do something similar with a screen reader would indeed make sense.
I'm linking a draft implementation of a "Focus > note viewer" menu item that moves focus to the note viewer (edit: pull request). The line in the note viewer that receives focus is based on where the cursor is in the note editor.
The implementation needs a few changes before I'm comfortable opening a pull request. At present:
The draft "focus note viewer" command does nothing if the note viewer isn't currently visible. I think either:
the command should be disabled (and marked as such) in this case,
the note viewer should be shown, then focused, or
the editor should be focused instead. This third option is similar to what the current "focus editor" command does when the editor is not visible ā it focuses the note viewer.
The "focus note viewer" command doesn't have a default assigned keyboard shortcut, though one can be assigned in settings.
Thanks for mentioning this! I've noticed a few things while testing:
On Fedora 41 Linux with Orca, the viewer does seem to be in the tab focus order, but only if it has enough content to visually scroll.
On Windows 11 with NVDA, pressing m (next frame) jumps focus to the note viewer. I'm unaware of the equivalent shortcut for the Orca screen reader.
@mjanusauskas Thank you for reporting this! It's possible this is being caused by a plugin. Certain Joplin commands automatically move focus to the note editor. If a plugin is running one of these commands when Joplin switches notes, this could cause focus to jump from the note list to the editor.
Does this still happen with all plugins disabled (see the "plugins" tab in settings)? (Be sure to quit, then re-launch Joplin after disabling plugins)
It seems to be working better after disabling the freehand drawing plugin, so perhaps that was causing the issue? If so it will be a problem since it is enabled by default.
This change is included in the v3.3.3 pre-release. At present, there's no default keyboard shortcut for the menu item, but one can be assigned in settings > keyboard shortcuts.
Thank you for reporting this! I haven't noticed this issue with the Freehand Drawing plugin enabled on Linux or Windows (so perhaps it's MacOS-specific?).
First of all, truly amazing work @personalizedrefriger! I've completely forgot that GitHub does not display pre-releases on the main repo page, so I've been waiting when the 3.3.3 comes out.
Anyway, I've just tested it and it works great, especially the position syncing, this is really cool!
One thing I would perhaps reconsider is the action taken when no position is active in the editor i.e. the user freshly selects a note from the note list and wants to jump into the viewer.
currently, quite logically, the viewer as an object is focused. However, for some reason, the screenreader does not consider it to be a browsable content, and does not automatically turn off the focus mode, which was active in the list. Would it perhaps be possible to jump to the first line / element in the note instead? When the note editor has a caret position and jumping into viewer focuses a specific element, this works perfectly.
Note these observations are made on Ubuntu Mate 22.04 with Orca 44.2, which is few years old, so if anyone could verify this on anything more recent, that would be great.
I was successfully using Joplin under slint 15.0 & somehow, enabled large text which completely broke Orca's ability to navigate the JopLin UI.
does anyone know how I can revert this change?
Was enabling large text something that was done within Joplin (or within the slint 15 settings)? Is Orca still able to access the Joplin menubar (does pressing alt cause Orca to read an item in the menubar)?
If Orca is still able to access Joplin's menubar, I suggest trying the following:
Check whether Joplin works in safe mode (menu bar > help > toggle safe mode). Safe mode disables all plugins and switches to a more basic text editor.
If Joplin does work in safe mode, go to settings, disable all plugins, then disable safe mode and restart Joplin.
