search

jupyter / notebook

Jupyter Interactive Notebook
https://jupyter-notebook.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
11.6k stars 4.86k forks source link

Notebook 7 prerelease keyboard navigation review #6595

Open isabela-pf opened 1 year ago

isabela-pf commented 1 year ago

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

Areas to navigate

Keyboard/tab traps

Skip links

Focus

Mixed input

In the file browser

Keyboard shortcuts

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](https://www.w3.org/TR/WCAG22/#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](https://www.w3.org/TR/WCAG22/#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 https://github.com/jupyterlab/jupyterlab/issues/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](https://www.w3.org/TR/WCAG22/#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. ![image](https://user-images.githubusercontent.com/510760/195416055-8ce1f436-d753-4593-8934-d20145204ff1.png) - 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](https://www.w3.org/TR/WCAG22/#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](https://www.w3.org/TR/WCAG22/#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](https://www.w3.org/TR/WCAG22/#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, image - 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](https://www.w3.org/TR/WCAG22/#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](https://www.w3.org/TR/WCAG22/#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 commented 1 year ago

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 https://github.com/jupyterlab/jupyterlab/pull/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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago
brichet commented 1 year ago

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.

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 commented 1 year ago

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?

image

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