Do not jump to the first cell if pressing tab in notebook

[krassowski]

Problem

• I'm always frustrated when I accidentally press Tab when focused on a notebook rather than on a cell (which happens if I click on cell output or cell collapser area) because:
  • the cell appears to be focused as indicated by the blue bar and all other keyboard events are directed to it
  • it results in the focus/selection jumping to the very first cell
  • which is especially annoying in long notebooks because navigating back to where I was takes me a long time and I often loose focus/forget what I was doing

Proposed Solution

• I would like it if instead pressing Tab focused the next cell and pressing Shift + Tab focused the previous cell.
  • please note that for accessibility reasons there should be no cycling, i.e. pressing Tab in the last cell should not go to the first cell but just proceed to the next focus-able element

Context

• tagging it as accessibility because users having difficulty clicking precisely on the cell are likely to be affected
• tagging it UX as the problem of navigating in long notebooks came up repeatedly in survey and feedback

[krassowski]

Cross-referencing #9399

[krassowski]

Would the proposed behaviour be ok with you @manfromjupyter @SamKacer (and anyone else interested)?

[manfromjupyter]

I like your gif, thank you for that. A screenreader user won't be clicking to the below tab. I understand your pain, but focus is still remaining in the cell, there is just a widget that highlights other thins you click on while focus still remains so users do not lose their train of thought. User may want to be typing things or copy something from another cell, reorder the cells below, use the editor toolbar tools, open header dropdowns, etc, and still be able to paste or continue typing in the original cell after. This seems by design to me and not something that should be fixed. If you escaped from a cell, I can agree that tabbing then should jump to the below cells but not while already actively within a cell editing. If you wanted to jump to the cell below and edit that one, you should just click be clicking on the cell content, not the outer cell element. Screenreaders and Ambulatory users need to ESC then tab or arrow to it (and won't be using a mouse in the first place) so this edge case doesn't affect them.

[SamKacer]

As a disclaimer I haven't used jupyter lab in some time.

To me it would make sense for the cells to be a single compound component as defined in WAI ARIA Authoring Practises 1.1, so when tabbing back to it would focus the cell that was focused last and has the visual styling to indicate it is the active cell instead of the first cell being focused.

As @manfromjupyter pointed out, this is unlikely to affect keyboard-only users like screen reader users, since they won't click out of the cells, however I can imagine there could possibly be some edge cases of how a keyboard only user could move their system focus outside of the cells and then perhaps tab back to the cells, in which case the active cell should be focused instead of the first one. This is how it works for other compound components like tree views.

So essentially if we take this simplified htl structure to represent the cells:

<div id="cells">
  <div class="cell"></div>
  <div class="cell" id="active"></div>
  ...
</div>

When #cells receives system focus (is tabbed to), #active should be the focused cell, not the first one.

Those are my thoughts going off the context I've gotten from this thread. Apologies if I've misinterpreted anything due to not being a current user of jupyter lab.

[krassowski]

Thank you both for the feedback, I think I get what you say.

I can imagine there could possibly be some edge cases of how a keyboard only user could move their system focus outside of the cells and then perhaps tab back to the cells, in which case the active cell should be focused instead of the first one.

Yes, lets consider the following scenario:

1. user is editing a cell deep in the notebook
2. user presses Esc out of habit
3. user uses a keyboard shortcut to open file browser; by default it is Ctrl + Shift + F which may not be as handy for users of specific devices/assistive technologies but it is customisable (and there are many users who just prefer keyboard only navigation, and some have difficulty using mouse so prefer not to use it)
4. user wants to jump back to the cell they were editing so presses Tab
5. user finds themselves at the beginning of the notebook, so their flow is disrupted

As it is easier to navigate to the first cell (e.g. by pressing Home once or by pressing up arrow continuously) than to the exact cells that was edited in a long notebook it seems that adding a special case of Tab focusing the previously active cell will be beneficial to many users (even if this is an edge case and happens rarely).

I think that this should be implemented with a lot of caution and only override the current Tab behaviour when pressed outside of notebook in such a circumstance that would currently lead to focusing the first cell (to avoid conflicts when leaving the notebook area, or when indenting code in editor).

[SamKacer]

I think that this should be implemented with a lot of caution and only override the current Tab behaviour when pressed outside of notebook in such a circumstance that would currently lead to focusing the first cell (to avoid conflicts when leaving the notebook area, or when indenting code in editor).

I don't think this would need to be overriden by changing the behavior of pressing the tab key. I think this could be just as a onfocus handler for the cell area specifically. just track active cell and onfocus, put focus on the active cell. Also better to do as onfocus instead of onkeydown tab since screen reader users have other ways to focus an element other than just tabbing to it.

[willemavjc]

I'm in for the idea of having a TAB command focusing on the next cell actually focused rather than the very first one. To be honest, the scenario described by @krassowski on the first post happens to me ...everyday; because every other app tends to work that way when it implements a TAB shifting feature.

[krassowski]

Closing as this was fixed in JupyterLab 4.1.0 by #14115

[krassowski]

Note: there is still some potentially unexpected jumping when pressing Tab if notebook contains links in markdown cells.