Jupyter Blog - Nicolas Brichet

Recent keyboard navigation improvements in Jupyter

2023-12-16T09:48:00+00:00

Upcoming versions of JupyterLab (4.1.0) and Notebook (7.1.0) will include major keyboard accessibility fixes.

Keyboard accessibility is fundamental to overall app accessibility. Interactions that require pointing devices like mice or trackpads are usability barriers for many users across a wide spectrum of disabilities. Ensuring that all UI features are seamlessly accessible through keyboard-only navigation is imperative for an inclusive user experience.

A recent audit of the JupyterLab UI highlighted significant gaps in keyboard navigation, posing obstacles to usability and accessibility. One of the main obstacles to efficient keyboard navigation in JupyterLab is the number of UI items to skim through before being able to perform an action, such as typing in a document or creating a file. Indeed, as with any feature-rich application, the JupyterLab UI includes many menus, widgets, and inputs to interact with. The user interface is made of three main areas (left, center, and right), each one split into several panels. And most of these panels include toolbars with buttons to perform specific actions.

Improving this navigation required separate fixes for different elements of the page:

Menu bar (Lumino #465)
Tab bar (Lumino #612)
Toolbar (JupyterLab #15021)

All these changes follow the same logic: the Tab key is used to navigate between top-level elements (toolbar, menu, tab list), but not to navigate between items for which one should use arrow keys, nor to select an item for which one can use the Enter/Space keys. Most of these changes were actually applied to low-level components of JupyterLab, so that any JupyterLab extension built upon them will benefit from these improvements.

The changes to the toolbar make use of a new UI toolkit, based on web components, which natively includes these accessibility features, but also helps standardize the widgets used across the JupyterLab UI and JupyterLab extensions.

Notebook Tab Traps

Another blocker to keyboard navigation was the existence of “tab traps” or “focus traps” in the notebook widget. Tab traps occur when a user cannot move focus away from an interactive element with the Tab key.

The main problem was that, while the input area of each notebook cell could be reached by using the Tab key, the input area itself, which is a text editor, does not allow moving to the next item using the Tab key since the Tab key is used to insert spaces into the editor.

This has been fixed in JupyterLab PR #14115, by changing the tabbable items in the Notebook from the cell input to the cell itself. Now the Notebook follows the same logic mentioned above. Arrow keys are used to navigate the cells, whereas the Tab key is reserved mostly to navigate into and then back out of the Notebook. Entering or exiting the input element of the cell is done using the Enter and Escape keys, respectively.

These changes required a complete inversion in the way the keyboard events are handled in the notebook, especially with respect to keyboard shortcuts. These modifications were required to retain keyboard shortcuts in the output widget and at the notebook level, while changing the way element focus is managed in the notebook.

Future accessibility improvements

Accessibility work at Jupyter is grounded in the recommendations of the W3C Web Accessibility Initiative, in particular their standards for web content (WCAG), web apps (ARIA), and authoring tools (ATAG). There has been particular interest recently in addressing the authoring part of the equation.

That’s because a crucial aspect of the accessibility of notebooks lies in the content itself. It is imperative that Jupyter front ends actively support notebook authors in creating accessible content. This involves, for instance, prompting authors to include descriptive alt text for images, and issuing warnings when heading ranks are skipped. Skipping heading ranks can lead to difficulties in navigating the document outline, especially for users relying on screen readers. Such warnings could be brought through the language server protocol for markdown cells for example.

If your organization is interested in supporting such accessibility improvements, please reach out to the Jupyter accessibility team!

Feedback

Please try out the latest pre-release of JupyterLab 4.1. Try opening, editing, and saving a notebook without using your mouse or trackpad. Be aware that there are still areas of the UI as well as extensions that need fixing for mouseless use. We are keeping track of accessibility issues in a few places: JupyterLab GitHub accessibility label, Notebook 7 GitHub accessibility label, JupyterLab issue #9399. As you will find at those links, there’s still loads more to do. If you can help with either fixing those things or identifying other issues, please come help us, your contribution is valuable and you are welcome!

About the Authors

Nicolas Brichet is a scientific software developer at QuantStack, and a JupyterLab core team member. Prior to this work on keyboard navigation, Nicolas contributed to improving the accessibility of Jupyter by addressing the issues detected by the Axe accessibility testing engine.

Gabriel Fouasnon is a frontend developer at Quansight, a member of the Jupyter Software Steering Council representing the accessibility subproject, and a JupyterLab core team member.

Acknowledgments

This work on improving the keyboard navigation of JupyterLab was started with an audit of the keyboard navigation of the Jupyter Notebook v7 by Isabela Presedo-Floyd.

The work of Gabriel Fouasnon and Isabela Presedo-Floyd at Quansight on Jupyter accessibility was funded by the Chan Zuckerberg Initiative, through the “Essential Open Source Software for Science” (EOSS) grant program.

The work by Nicolas Brichet at QuantStack on the accessibility of Jupyter was funded by INSEE, the French National Institute of Statistics and Economic Studies.

We also want to acknowledge all of the members of the Jupyter Accessibility Council: Tania Allard, Alex Bozarth, Frédéric Collonval, Martha Cryan, Afshin T. Darian, R Ely, Tony Fast, Gabriel Fouasnon, Michał Krassowski, and Isabela Presedo-Floyd, without whom this work would not be possible.

Improving the accessibility of Jupyter

2023-02-24T11:11:00+00:00

The adoption of Jupyter has grown significantly in the past few years — especially in education contexts. The project has become a foundational component of our digital experience, from the first lines of code written by high-school students to the most advanced research and engineering use cases.

In this context of global adoption, it is even more important to ensure that as many people as possible can use the project. It is estimated that 15% of the population has a disability that may impair their ability to use online services. If we don’t want them to be excluded from learning sciences, technology, and engineering, we must improve the tools to make them usable by everyone…

To address this issue, a Jupyter accessibility working group formed and has now become an official Jupyter Subproject and received a grant from the Chan Zuckerberg Initiative.

Creating accessible user interfaces is a challenging task as it requires accommodating a broad range of disabilities, including vision, motor, and cognitive impairments. This article presents some of the recent accessibility improvements in the Jupyter Notebook codebase.

CodeMirror 6 and Notebook 7

Jupyter Notebook 7, which is the next major release of the Jupyter Notebook frontend, has been rebuilt with modern JupyterLab components and extensions while maintaining the classic Jupyter Notebook user experience. Notebook 7 will be released shortly after JupyterLab 4 and will take advantage of JupyterLab improvements.

Improving the accessibility of Jupyter had long been impeded by significant obstacles. The primary obstacle was that the text editor underlying the Jupyter Notebook (CodeMirror 5) had major accessibility issues.

Fortunately, this accessibility bottleneck has been unblocked as JupyterLab has been upgraded to use CodeMirror 6, a complete rewrite of the text editor with a strong focus on accessibility. Although this upgrade required extensive codebase modifications, the changes landed a few months ago and will be available with JupyterLab 4. Jupyter Notebook 7 will benefit from the CodeMirror 6 upgrade.

Initial accessibility audits

Shortly after the CodeMirror 6 migration landed, we made an automated audit of the accessibility of Notebook 7 with these changes, and found that the number of warnings and errors reported by Axe Auditor went down from several hundreds to a few dozen, most of which seemed fixable. Encouraged by these results, we decided to work on bringing that count to zero!

With a series of fixes ranging from simple changes to the DOM structure of components to fixing up base Lumino components (Lumino is a JavaScript framework that underlies a lot of the JupyterLab frontend architecture), we were able to make the Notebook 7 codebase pass the Axe Auditor tests with zero error or warning. While we have not reached that yet in JupyterLab, both JupyterLab and Jupyter Notebook benefit from these improvements made for Notebook 7 since they are built from the same components.

Axe Auditor output with the “classic” Notebook UI (v6) with a test notebook.

Axe Auditor output with the “next” Notebook UI (v7 alpha 13) with the same test notebook.

Similar results were achieved with the file explorer and text editor tabs of the application.

Beyond accessibility audits

Improving the accessibility of Jupyter requires more than just addressing issues flagged by automated audit tools and the Jupyter Accessibility Subproject is working on improving accessibility across the board in Project Jupyter. These results with the Notebook 7 codebase are very encouraging, but working with end-users and getting their feedback will also be necessary to make the user interface truly accessible.

To address the diversity of accessibility requirements, we will approach specific use cases separately (for example, users with screen readers, or users who can operate a keyboard but not a pointing device). While the resulting changes may improve usability for everyone, we need to learn from users who have specific needs to make meaningful improvements.

Finally, many of the accessibility challenges in Jupyter stem from the content of the notebooks, as notebook authors may not follow the best practices to make their content usable by everyone (such as adding alt text to images and figures, or properly using headings to communicate the organization of a notebook). To promote these best practices, Jupyter could provide linting tools that produce inline warnings and hints for notebooks that do not follow these guidelines.

Acknowledgements

The work by Johan Mabille at QuantStack on migrating JupyterLab to use CodeMirror 6 was funded by Two Sigma. This upgrade also enabled significant performance improvements in the rendering of Jupyter notebooks, as detailed in this earlier post by Frédéric Collonval.

We are grateful to members of the Jupyter Accessibility Subproject who produced a thorough review of the Notebook 7 UI with a focus on keyboard navigation. This is an example of an issue that cannot be easily detected by auditing tools.

About the Authors

Nicolas Brichet is a scientific software developer at QuantStack active in the Jupyter ecosystem. Among other things, Nicolas made significant contributions to the JupyterLab and Voilà projects, and worked on porting the nbgrader package to JupyterLab. Nicolas worked on accessibility improvements in the JupyterLab and Lumino packages.

Johan Mabille is a technical director at QuantStack. He was honored with the Distinguished Contributors award in 2020 for his contributions to the Jupyter project. Among other things, he is one of the main authors of the JupyterLab visual debugger, and the creator of Xeus, a C++ implementation of the Jupyter kernel protocol at the basis of many Jupyter kernels. Johan was responsible for the migration of JupyterLab to CodeMirror 6.

Jeremy Tuloup is a technical director at QuantStack, and a Jupyter Distinguished Contributor. He is a core maintainer of JupyterLab and Voilà, and the creator of the JupyterLite project. Jeremy is the main initiator of the Notebook 7 project.

Frédéric Collonval is a technical director at QuantStack, and a Jupyter Distinguished Contributor. He is a core maintainer of the JupyterLab project. Frédéric contributed to the CodeMirror 6 migration and helped numerous new contributors to get their enhancements accepted.

Sylvain Corlay is the founder and CEO of QuantStack, and a Jupyter Distinguished Contributor. He has worked on many areas of the Jupyter project, from interactive widgets to language kernels and other core components.

Upgrading Nbgrader

2022-09-15T07:51:00+00:00

Project Jupyter provides a broad collection of open-source tools for interactive computing that has become ubiquitous in data science and scientific computing, and is very popular in educational contexts.

Nbgrader, started by Jessica Hamrick in 2014, is an extension for creating notebook-based assignments, online courses, and for auto-grading these assignments. It is central to many Jupyter-based services used by teaching institutions.

As a large part of the Jupyter user base has adopted the JupyterLab frontend, most of the popular extensions to the classic notebook UI now have an equivalent in the JupyterLab world. Unfortunately, the nbgrader extension was still outstanding as it had not yet been ported to the JupyterLab extension system. Resolving this has become critical as it was recently decided in a Jupyter Enhancement Proposal (JEP) that the next major version of the Notebook package (v7) will be based on JupyterLab components, and will rely on the JupyterLab extension mechanism. As part of this JEP, it was decided that the release of Notebook 7 should be contingent on porting certain popular classic notebook extensions to JupyterLab, including nbgrader.

Upgrading nbgrader is an important step for the advancement of the Jupyter project!

Nbgrader 0.8

The port of nbgrader to JupyterLab is a longstanding request of the community. A lot of work had already been done on this front by contributors to the ngshare project (Kevin Rong, Abigail Almanza, Lawrence Lee, and Eric Li) who developed a large part of the JupyterLab-based UI, but did not finalize the migration due to lack of time. Fortunately, they made their work available to the community for others to complete the upgrade. This includes the development of the remaining elements of the UI, the adaptation of the server-side extension, and adding tests on the JupyterLab extensions to improve the CI. The nbgrader 0.8 release also includes other significant work items such as the upgrade to nbconvert 6, the switch from the notebook server to jupyter-server, and the adoption of the jupyter releaser.

Today, we are pleased to announce the release of nbgrader 0.8.0, the first release of the extension to support the JupyterLab frontend.

Creating an assignment

Teachers can create assignments directly in the notebook UI by setting the proper information for each cell, such as the cell type (whether it is a locked cell, a manually graded answer, or an automatically graded answer) and the number of points the answer is worth.

The UI for creating an assignment in the notebook (teachers).

Managing assignments on the teacher side

Formgrader is the part of the nbgrader UI for the teachers to manage the assignments.

From this UI, teachers will be able to:

generate assignments from a Notebook file
share assignments with students
fetch assignments after student submission
grade assignments
provide feedback to students

The Formgrader UI to manage assignments (teachers).

Managing assignments on the student side

The assignments list UI is used by students to fetch assignments released by the teacher, submit their answers, and benefit from the feedback after the evaluation by teachers.

The assignments list UI to fetch and submit assignments (students).

What about the future?

Creating and grading assignments in nbgrader uses the metadata of individual notebook cells. The current release of nbgrader provides a widget to interact with the corresponding metadata.

As other extensions need a similar functionality, we are expanding the generic cell metadata editor to address this requirement in a more generic and pluggable way. The new metadata editor allows any extension to create a specific form to interact with the relevant part of the metadata, specified with a JSON schema and rendered with react-jsonschema-form.

Nbgrader could take advantage of this improvement in a future release.

Try it online

Installation

You can install the latest version of nbgrader using pip:

pip install nbgrader

The GitHub repository can be found here.

Acknowledgements

This work at QuantStack was partly funded by Université Paris Cité in the context of the PlasmaBio project.

We are grateful to Jessica Hamrick, Jeremy Tuloup, and Ian Stuart for their help and code reviews during the upgrade to nbgrader 0.8.0.

About the Author

Nicolas Brichet is a scientific software developer at QuantStack active in the Jupyter ecosystem. In the past few months, he has been working on the Nbgrader extension, as well as other developments in core JupyterLab such as an improved notebook metadata editor. Before joining QuantStack, Nicolas was a software engineer at INRAE.

Jupyter Blog - Nicolas Brichet

Recent keyboard navigation improvements in Jupyter

Keyboard navigation in JupyterLab

Notebook Tab Traps

Future accessibility improvements

Feedback

About the Authors

Acknowledgments

Improving the accessibility of Jupyter

CodeMirror 6 and Notebook 7

Initial accessibility audits

Beyond accessibility audits

Acknowledgements

About the Authors

Upgrading Nbgrader

Nbgrader 0.8

Creating an assignment

Managing assignments on the teacher side

Managing assignments on the student side

What about the future?

Try it online

Installation

Acknowledgements

About the Author