Notebook 7 prerelease keyboard navigation review

[isabela-pf]

As a part of reviewing the prerelease of Notebook 7 for accessibility issues, we teamed up to run some manual keyboard navigation tests on this Notebook 7 binder.

Many thanks to @ohrely, @gabalafou, @krassowski, @vidartf, @steff456, and @afshin for authoring this review!

Please note that this format of reporting the full review via issue is new and possibly a little messy. Please let me know if there's anything that would make it easier to understand or manage. Thanks!

Takeaways

Based on the full review, I'm going to briefly issues that stood out.

Content order

In the file browser

• The full order of the content isn't clear because of limited visible focus styling.
• There are unknown focus areas where the user needs to use the tab key multiple times in a row to continue to the next section without visual feedback where they are. We're not sure if this will be solved by visible focus styling or if they content order is jumping somewhere we don't expect.
• Files tabs, Running tabs, and File sorting UI (like Name and Last Modified ordering) are skipped over with keyboard navigation.

Areas to navigate

• Navigating through the menu bar with a keyboard "leaves incorrect lm-mod-active class on last active item"
• Notebook toolbar excess items cannot be navigated to with a keyboard
• Leaving the active file editor with a keyboard must be done with the esc key. This isn't standard keyboard navigation behavior.
• JupyterLab cannot switch between split areas Keyboard shortcuts for navigating panes jupyterlab/jupyterlab#4407

Keyboard/tab traps

• Terminal is a major tab trap. Could only escape by using the command palette shortcut.
• Notebook editor (like other file editors) and consoles must be exited with the esc key. This isn't standard keyboard navigation behavior.
• Could not open new terminal with the Running tab using the keyboard. Only expands and collapses.
• "If I hide the header (command palette, untoggle "Show Header"), I still tab through the hidden element?"
• "Please check focus reset after Command Palette -> Find... -> Escape to exit out. I would expect focus to go back where I was prior to the command palette (e.g. in a specific cell editor)."

Skip links

• There does not appear to be a skip link in either the file tree page or the notebook page. There should be skip link(s) to skip over menu bar(s), straight to main page content

Focus

• There is visible focus in some areas, but it is not applied throughout. Some areas have blue outlines.
• Sometimes a user is able to see focus because of an area's hover state, but these areas need a true focus state additionally.
• "The behavior of hovering/colors/interactions is not the same doing it by the keyboard than doing it with the mouse." Meaning different interactive area states are not always triggered by keyboard focus?

Mixed input

In the file browser

• "Could not select/unselect file using only keyboard. Multi-select and unselect is also busted"

Keyboard shortcuts

• Shortcuts cannot be turned off
• Shortcuts cannot be remapped/configured (via the UI)

Full review

This is the full list of prompts and responses from our review session.

### Content order

When accessed via keyboard, the content order is logical. (WCAG 2.2 Focus order)

1. From the top of the page, press the Tab key repeatedly until reviewer reaches the end of content.
2. Reviewers will know it is the end because if they press Tab once more their keyboard focus will return to the browser.
3. If the reviewer cannot make it to the end of content, please take note of where the focus gets stuck.

Does the content order follow reviewer expectations based on reading the content?
Result: It goes from top to bottom and left to right, which makes sense for an English keyboard. I am able to loop from the end of the document back to the top, so that meets my expectations as well.

I cannot identify the content order in its entirety because of the lack of visible focus indicator (see below). The content order may make sense, but I cannot tell.

Does the content order make sense for interacting with the content?
Result: The content order on the file browser goes as follows: 5 unknowns, File, View, Settings, Help, Share, 3 unknowns, Upload, Refresh the file browser, Filter, File browser (can navigate list of files with arrow keys). This is a reading order that makes sense for the page. The main issues are the "unknowns" (where I had to use the tab key that number of times with no visible focus state in order to find myself on an interactive area again) and areas that are missed entirely.

Are any major content areas missed when navigating via keyboard?
Result: While the whole content order is not entirely clear based on this evaluation, we did notice areas missing in the file browser. Missing areas included

• Files and Running tabs
• File sorting UI (like Name and Last Modified ordering)

Are any interactive content areas missed when navigating via keyboard?
Result: See above.

Other notes or recommendations:

Areas to navigate

All areas of the tool can be accessed using keyboard navigation. (WCAG 2.2 Keyboard)

1. Navigate via the Tab key major content areas
2. Use the arrow keys to navigate within major content areas.

Area	Able to navigate to the area (yes/no/not applicable)	Able to navigate fully within the area (yes/no/not applicable)	Able to navigate out of the area (yes/no/not applicable)
Menubar	yes	yes	yes but leaves incorrect lm-mod-active class on last active item
Files or Running panel in tree view	no	-	-
New/upload/refresh buttons	yes	yes	yes
Searchbar in tree view	yes	yes	yes
Breadcrumbs	-	-	-
Columns of the file browser	no	-	-
File browser	yes	yes	yes
Running panel	no	no (only the Shut Down All button)	yes
File editor	yes	-	yes (after pressing Esc)
Notebook toolbar excess items (see screenshot)	no	yes (after focusing with a click)	yes
Notebook cells	yes	yes	yes

Other notes by area:

• JupyterLab cannot switch between split areas Keyboard shortcuts for navigating panes jupyterlab/jupyterlab#4407

Keyboard/tab traps

When navigating via keyboard, there are no areas where keyboard focus can enter but not exit. The focus never gets "trapped." (WCAG 2.2 No keyboard trap)

From the above section (Areas to navigate), please list all areas where the reviewer could not navigate out of using the keyboard. Notes are welcome!

Keyboard/tab traps:

• terminal seems like a really bad trap. Cannot get out with tab, shift tab, escape key, or Alt + D (shortcut to focus address bar in my browser - Firefox). I can escape by Ctrl + Shift + C (command palette) after which I can tab around again!
• file editor (text file): Cannot escape by using tab or shift + tab, but can escape with "Escape" key (after I can tab either forward or backward).
• Notebook editor: Code cell editor: Cannot escape by tab/shift+tab. Can escape with "Escape" key, but focus is put somewhere where the next focus item is the cell toolbar of the cell you just escaped, which is earlier in the tab order than the editor itself, so you cannot go past the editor. You can go backwards, but that starts from before the first cell, so it is impossible to tab to a cell in the middle of the notebook.
• Console: Same issue as Notebook editor where using "Escape" key to get out of editor will re-trap you when you hit continue tabbing. It does however seem to be the last element on the page, so probably not as bad of a problem.

Other notes or recommendations:

• Could not figure out how to open a running terminal from the "running tab", was only able to expand collapse sections...
• If I hide the header (command palette, untoggle "Show Header"), I still tab through the hidden element?
• In the terminal, I was able to tab into the codemirror editor for the previous cells somehow. Some of the things I did was: Turn on "Show all Kernel actrivity", enter Zen mode, open the palette and tab further. Somehow I was able to enter the CM editor and insert tabs. See screenshot below.
  
• Please check focus reset after Command Palette -> Find... -> Escape to exit out. I would expect focus to go back where I was prior to the command palette (e.g. in a specific cell editor).

Skip links

When using keyboard navigation, there is a link to switch keyboard focus directly to the tool's main content and skip header navigation or repeated content. (WCAG 2.2 Bypass Blocks)

1. From the top of the page, press the Tab key. If you have already been interacting with the page, reviewer may need to reload page and then press Tab.
2. Once focus is on the skip link, press Space or Enter to activate it.

Is there a skip link?
Result: There does not appear to be one in either the file tree page or the notebook page. I inspected html source in browser, but quick searches found nothing.

Is the skip link prompt visible?
Result: No visible prompt on pages tested.

What does the skip link prompt skip?
Result: N/A

Where does the skip link prompt move user focus to?
Result: N/A

Does the skip link behavior meet reviewer expectations?
Result: No; there should be skip link(s) to skip over menu bar(s), straight to main page content.

Other notes or recommendations: https://github.com/ offers a basic working example of skip links for comparison.

Interactive Areas

All buttons, links, form fields, or similar interactive areas can be both accessed and activated using only the keyboard. (WCAG 2.2 Keyboard)

1. Navigate via the Tab key to interactive areas.
2. Activate interactive areas using the Enter or Spacebar key.

Interactive area	Able to navigate to the area (yes/no/not applicable)	Able to input information (yes/no/not applicable)	Able to activate the area (yes/no/not applicable)
Button 1	a	b	c
Button 2	d	e	f
Button 3	g	h	i
Link 1	j	k	l
Link 2	m	n	o
Form field 1	p	q	r
Add table rows as needed!

Other notes by area:

Focus

There is a visible focus state for all content. It appears by default when navigating via keyboard. (WCAG 2.2 Focus visible)

1. From the top of the page, press the Tab key repeatedly until reviewer reaches the end of content.

Result: pressing the Tab key repeatedly moves the focus around the interface, but it doesn't give focus to all the elements of the UI. There's no focus to the sidebars items, though items inside the opened sidebar are getting focus.
2. If end of content cannot be reached, the reviewer may report on what they could interact with.

Result: The end content can be reached, and it will circle back to the starting point of the document.
3. If the reviewer is comfortable, they may also use the browser inspector to select an area and toggle focus per area.

Is there visible focus styling? If so, please briefly describe it.
Result:

• Jupyterlab main areas have a blue margin for the sidebar contents and links inside the notebook.
• Jupyterlab main menu has a hover color over the menu that is focused.
• The user is not able to change the files, and there's no way to have a visible way to see which one is selected. (When done with the mouse it does have a hover color)
• The menubar for the notebook has a hover color on the focused item.

Is the focus styling consistent throughout?
Result:

• In the menus, sidebar, lists and tree views it is pretty consistent. It has the same hover color and behavior throughout the interface
• The main content areas are not consistent in the blue margin, some items in the menus inside the sidebars have it,

- The behavior of hovering/colors/interactions is not the same doing it by the keyboard than doing it with the mouse. - There's a dialog that appears to go to the left sidebar, but I couldn't use it

Are there any areas without visible focus styling?
Result: The change from sidebar to the notebook and afterwards is tricky because there's no visible focus styling.

Was the reviewer ever unclear about where their keyboard focus was during the review? If so, please note where or why.
Result:

Some items are not focused because the user will not be able to make any action, but it makes the interaction weird. For example, the only item that you are able to get focus in the status bar is the first one (which is the only one that has an action associated). Also the focus changes in the different type of documents that you can open in the main content area.

Other notes or recommendations:

Mixed input

It is possible to complete tasks while switching between input mechanisms, for example using a keyboard and mouse and touch screen. (WCAG 2.2 Concurrent input mechanisms)

1. Locate an interactive area.
2. Complete the interaction using keyboard controls.
3. Complete the interaction using the mouse.
4. Complete the interaction using touch controls.
5. If the task has multiple steps, the reviewer can try using a different interaction for each step.
6. Repeat as needed across interactive areas.

• I only covered the first page of Notebook 7 (the one with the two tabs, Files and Running). I did not look into any open notebook files or other documents or parts of the UI.
• Need to do this part of the audit with an actual touch device and not just a simulator. My hope was that I could use the iOS simulator to audit the UI for touch interactions. But I was very surprised when I opened the iPad Air simulator today. It's been a while since I used the iPad simulator. I'm not sure, but I think that in the past the UX made it a bit more obvious that touch events were being simulated. What I remember is that in the past when you dragged your mouse over the simulator window, the mouse pointer icon changed from an arrow icon to a round circle. So I just wasn't sure if I was sending touch events or not. I noticed an option under I/O > Input > Send Pointer to Device. Documentation isn't great. I noticed that when I activate "Send Pointer to Device" then the Notebook UI is aware of where the pointer is (e.g., menus in the top menu bar open when I hover over them). So my guess is that "Send Pointer to Device" is to simulate when you connect an external mouse to the iPad (or use it as a second screen). But the overall takeaway for me is that next time I need to use an actual touch device rather than a simulator, because otherwise there's too much guesswork about what the simulator is actually doing.
• One bizarre thing I noticed is that when I turned on "Send Pointer to Device," I was unable to click between the Files and Running tabs.
• I could also not find a way to switch between those tabs using only the keyboard.
• I could not find a way to use the keyboard for: select all files, sort files by name, sort files by last modified.
• Could not select/unselect file using only keyboard. Multi-select and unselect is also busted.
• Can shutdown kernels from Running using only keyboard.
• Can expand/collapse sections under Running using only keyboard.

Task name + region

Does the task have multiple steps? If yes, please list them.
Result:

Can the task be completed with only keyboard controls?
Result:

Can the task be completed with only mouse controls?
Result:

Can the task be completed with only touch screen contorls?
Result:

Keyboard shortcuts

Keyboard shortcuts--key combinations that initiate an action-- may not inhibit keyboard navigation. Keyboard shortcuts also need to be configurable. (WCAG 2.2 Character key shortcuts)

List of shortcuts for this tool.

1. Search for where keyboard shortcut settings may be edited.
2. Review list of keyboard shortcuts.
3. Choose a shortcut and answer the prompts.
4. Repeat as needed.

Can shortcuts be turned off?
Result: Not in the file browser or notebook UI, we should add this feature

Can shortcuts be configured (remapped to different keys than the default)?
Result: Not in the file browser or notebook UI, we should add this feature

Do any shortcuts conflict with browser or operating system controls?
Result: Yes, but in relevant situations (e.g., for copy and paste), this seems okay

Other notes or recommendations:

Shortcut name

Shortcut keys:

How many keys are needed?
Result:

How close together are the keys?
Result:

Does the shortcut only activate when focus is on the related part of the interface?
Result:

Other notes or recommendations:

[SylvainCorlay]

Hello everyone, many thanks for @isabela-pf for providing the keyboard navigation review of Notebook 7!

I am happy to announce that we have received a development grant from @InseeFr for 8 weeks of work to address the keyboard navigation issues of the Jupyter notebook!

Hopefully, we will be able to resolve most (or all) of the issues that were discovered by Isabela as part of this review. On a separate note, we are aware of the work that @gabalafou has already done on fixing the tab traps in the JupyterLab repository at jupyterlab/jupyterlab#14115. If this PR has not been merged when we start working on this assignment, it will definitely be a priority to help get this work integrated in JupyterLab (review, debugging, etc).

Upon finishing this assignment, we would love to connect with you on the possibility of writing a joint blog post showing progress on these subjects, the multi-stakeholder effort on accessibility, and crediting the audit done by Isabela.

[gabalafou]

@SylvainCorlay wonderful news! Does the 8 weeks mean that there's a specific start date or deadline on the work or a specific timeframe in which it has to be done? Just wondering in terms of planning.

[SylvainCorlay]

@SylvainCorlay wonderful news! Does the 8 weeks mean that there's a specific start date or deadline on the work or a specific timeframe in which it has to be done? Just wondering in terms of planning.

We have to spend this budget before the end of December.

EDIT: but I think we will start earlier.

[tonyfast]

• mark skip link as completed by Fix skiplink and add placeholder for additional skiplinks jupyterlab/jupyterlab#14597 which leaves extra space for me skip links
• tab traps will be fixed by Fix tab trap notebook cells jupyterlab/jupyterlab#14115
• using aria authoring practice guide recommendations Using Toolbar Patterns from the ARIA Authoring Practices Guide for Better Assistive Experience #6935 addresses:
  • tab component problems and being able to navigate tabs
  • menubar and toolbar problems
• visible focus is referenced in tens of issues and pull requests. it is a keyboard issue that would fix a quite a few concerned users.
• the file editor navigation and sorting UI could be fixed by using ARIA APG table practices. there is a recommendation in Accessibility Issues Needing Addressing for WCAG 2.1 compliance (As of Version 7.0.0a15) #6800 to make the file browser a table. implementing the recommendation tab patterns then table patterns would sort out of a lot of inconsistencies.

[brichet]

Thanks @isabela-pf for reporting this.

• The full order of the content isn't clear because of limited visible focus styling.
• There are unknown focus areas where the user needs to use the tab key multiple times in a row to continue to the next section without visual feedback where they are. We're not sure if this will be solved by visible focus styling or if they content order is jumping somewhere we don't expect.

Is this still the case ? On my side the focus can be seen every time, in the file browser or the Notebook view.
Nevertheless, focusing styles differ according to the elements involved (black outlines, blue outlines, grayed background, blue background). Is this the issue here or are there some items without focus at all ?

• Leaving the active file editor with a keyboard must be done with the esc key. This isn't standard keyboard navigation behavior.
• Notebook editor (like other file editors) and consoles must be exited with the esc key. This isn't standard keyboard navigation behavior.

Do you know if there are suggestions about this when using inline editors ? I think the standard navigation keys are tab, arrows, enter and space, but all of them have a function in an editor.

• JupyterLab cannot switch between split areas Keyboard shortcuts for navigating panes jupyterlab/jupyterlab#4407

Does it also concern Notebook 7 or only Jupyterlab ? Don't know if we can split the main area in Notebook, and if it is expected.

• "If I hide the header (command palette, untoggle "Show Header"), I still tab through the hidden element?"

I can't reproduce it, on my side there is no "unknow" tab, even when the header is hidden.

[tonyfast]

I can't reproduce it, on my side there is no "unknow" tab, even when the header is hidden.

the tab order doesn't take me to any hidden elements either. maybe something got fixed?

Does it also concern Notebook 7 or only Jupyterlab ? Don't know if we can split the main area in Notebook, and if it is expected.

there is a splitter region in the current notebook main area for extensions. the ARIA authoring practice guide has recommendations for implementing a window splitter. the one splitter in notebook is probably requires different considerations than window splitters in lab.

Do you know if there are suggestions about this when using inline editors ? I think the standard navigation keys are tab, arrows, enter and space, but all of them have a function in an editor.

lots of scope creep can happen at the intersection of authoring (ATAG) and WCAG. some inline widgets with features like autocomplete recommend esc implementations. the closest APG pattern would be to think about the notebook or file editor interfaces as part of a complex grid layout interface. in this pattern, Escape: restores grid navigation. If content was being edited, it may also undo edits. so for terminal, file editor, and notebook cells we should restore grid navigation.

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)

Is this still the case ? On my side the focus can be seen every time, in the file browser or the Notebook view.

i was able to find focus each time, too. maybe its all good at the moment.

Nevertheless, focusing styles differ according to the elements involved (black outlines, blue outlines, grayed background, blue background). Is this the issue here or are there some items without focus at all ?

the inconsistent focus is confusing when navigating around the headers. this is likely a big meta issue. theres a lot of different focus treatments across the interface. testing for focus is likely something we could do though. this would be a good piece of automation. sara soueidan's focus indicators post is always worth mentioning when discussing focus