Jupyter Blog - accessibility

Recent keyboard navigation improvements in Jupyter

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

Towards a more accessible Jupyter Notebook

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.

Desktop GIS software in the cloud with JupyterHub: A QGreenland workshop success story

2023-08-02T16:23:00+00:00

👋 We are Trey Stafford and Matt Fisher, co-authors of the QGreenland data package’s source code. This year, we had the pleasure of running a hands-on geospatial data and open science QGreenland Researcher Workshop. It was important for attendees to participate in the workshop in a hands-on way while minimizing the negative impacts of installing software, requiring expensive personal computers, and troubleshooting unique computer configurations. We felt a JupyterHub was a good fit for our workshop for this reason, if it could accommodate our need for running QGIS — a desktop application.

In this blog post, we will introduce QGreenland, describe our experience using JupyterHub in the cloud for our workshop’s computing environment, and discuss challenges we overcame to enable our attendees to use QGIS in a cloud graphical desktop environment. Finally, we will highlight some workshop outcomes and discuss opportunities for enhancement based on new developments in the Jupyter ecosystem.

In our workshop, 25–30 international learners (including from Germany, India, France, Canada, Poland, and the United States) used QGIS in a JupyterHub’s browser-based Linux desktop environment to collaboratively test, explore, visualize, and process Earth science data simultaneously with the same user experience they expect from using QGIS on their personal computers! Better yet, getting started was as simple as logging in. Our workshop was a success story not just in education, but also in open source and collaborative development, and we want to share what we learned.

Note the browser tabs at the top of this screenshot; this is a full desktop-based GIS environment running QGreenland in the cloud!

The JupyterHub used by the QGreenland 2023 Researcher Workshop was generously provided by the NASA CryoCloud team, whose mission is to help researchers transition to cloud-based collaboration.

About QGreenland

QGreenland is an open-source Greenland-focused geospatial data package for QGIS, a community-owned graphical Geographic Information System (GIS) platform. Researchers and members of the public leverage QGreenland’s ready-to-use interdisciplinary datasets to do field planning, teach about glaciers, and much more.

QGreenland’s MIT-licensed source code uses community-maintained open software like GDAL and PyQGIS to automate data normalization and populate the QGIS project with important information like data provenance and the order of layers in the QGIS Layers Panel. Check out our documentation to learn more! QGreenland also has a YouTube channel with tutorials produced by CIRES Education and Outreach.

Once QGIS is installed, opening QGreenland is as easy as double-clicking the included “.qgs” file. Here, a representative view of QGreenland v3 alpha in QGIS is displayed with newly updated layers: Arctic sea routes (National Geospatial Intelligence Agency), bathymetric depth (General Bathymetric Chart of the Oceans (GEBCO)), and ice thickness (IceBridge BedMachine Greenland v5) layers.

Based on user research, QGreenland has enabled:

the public to more easily access data gathered by researchers visiting Greenland: “In Greenland, people are often asking, ‘how can we find the data the foreign scientists bring back from Greenland?’ Now we can directly utilize much of it.”
researchers to plan field work: “Being able to use QGreenland at our field station was critical to our research process!”
educators to develop interactive lessons about Greenland and climate change: “…using QGreenland for presentations because it is presentation quality already.”

QGreenland’s 2023 researcher workshop

One of the QGreenland team’s most important forms of direct user interaction and support is facilitating workshops. Most recently, we hosted a 3-day (total of 9 hours) virtual workshop for researchers focused on working with geospatial data in an open science framework. All of the materials covered in the workshop were built using open-source tools and are MIT-licensed and published on GitHub.

A “personal computer” in the cloud

We decided early on that we wanted to use JupyterHub to solve the diverse problems that come with “bring your own device” workshops. We experimented with administering our own JupyterHub on Kubernetes, but the setup overhead was too high for our short workshop. CryoCloud’s JupyterHub enabled us to avoid this overhead and focus on serving our participants. Because the software that comprises CryoCloud is open-source and developed in collaboration with the communities CryoCloud serves, we could directly contribute to curating a computing environment ideal for our participants.

JupyterHub is known for providing access to Jupyter Notebooks via JupyterLab, but it turns out it can also be used to host pretty much any interactive web based application! The jupyter-server-proxy project enables this, and there are additional packages that make running specific applications easier. jupyter-rsession-proxy makes it easy to run RStudio inside JupyterHub, jupyter-vscode-proxy allows running code-server (fully open source self-hosted version of Visual Studio Code) inside a JupyterHub, etc. Pertinent to our use case is jupyter-remote-desktop-proxy, which lets you run a complete Linux desktop environment inside your JupyterHub! This was critical for our workshop, as it allowed us to use QGIS — purely desktop software, not adapted for the web — from inside a web browser. Workshop participants did not need to install anything. This enabled participants to focus on the content of our workshop rather than the logistics of setting up and debugging tools on their varied machines.

The CryoCloud JupyterHub enabled each of our workshop participants to provision their own compute environment (JupyterLab + Linux Desktop) with all of our workshop’s dependencies pre-installed. It also set everyone on equitable footing — someone accessing the workshop on a 10 year old laptop would get the same computing resources as someone on a brand new MacBook Pro.

Challenges scaling QGreenland

The CryoCloud JupyterHub already had jupyter-remote-desktop-proxy and QGIS installed, so we could validate this approach to our workshop quickly. However, to use QGreenland at this scale, we needed to solve a couple of usability problems. The first issue was a user experience problem: the operating system did not have appropriate file type associations for QGIS, so files like the QGreenland project file would not open in QGIS when double-clicked in the desktop file browser. We quickly discovered a solution and integrated it with a simple pull request to the Docker image we were using.

The second problem was a performance problem: QGIS would take several minutes to open QGreenland from the hub’s shared storage drive. After some investigation, it turned out this was due to us loading multiple GB of data from an NFS share! While a long term solution might involve getting QGIS to load data directly from cloud object storage (like S3), we instead decided to go a different route — provision each user a small, fast and temporary Elastic Block Store disk. At the start of the workshop, we provided all users a small script that would copy the dataset from NFS to this faster disk once, and this drastically reduced load times from about 5 minutes to under 3 seconds! You can follow our debugging process on this issue, and find the JupyterHub config used to provision these disks here.

By overcoming these challenges, we created a smooth, intuitive, and performant computing experience for all of our participants, most of whom had never been exposed to this sort of collaborative computing environment.

Outcomes

The workshop participants engaged in small group work to complete various exercises, group discussions, and data scenarios. Each group produced Jupyter Notebooks and GitHub Discussions posts as deliverables. We created an outcomes webpage to summarize our participants’ accomplishments. One highlight was participants’ insightful commentary on FAIR & CARE principles.

Based on these outcomes, we consider our workshop a success. While we put in a significant amount of time creating our materials, CryoCloud’s cloud costs and our time investment in preparing computing resources were relatively small. For approximately 25 people, our cloud costs break down to roughly $1/person/day!

Conclusion

The CryoCloud JupyterHub met our workshop needs and provided a delightful experience for administrators and participants alike, and we are excited for what’s next. JupyterLab 4 and jupyter_collaboration v1.0.0, a real-time collaboration extension, were just announced, and the CryoCloud team is currently working to integrate these new releases into their hub. Real-time collaboration will enable exciting cloud use cases, like small groups working together on the same notebook without a screen share, or organizers providing technical support in a live notebook. We anticipate running this workshop again. We are excited to use JupyterHub again and look forward to experimenting with these new features!

Acknowledgements

Reviewers

In alphabetical order, thanks to Twila Moon, Yuvi Panda, Tasha Snow, and Alyse Thurber for their time contributing to this post!

CryoCloud

Snow, Tasha, Millstein, Joanna, Scheick, Jessica, Sauthoff, Wilson, Leong, Wei Ji, Colliander, James, Pérez, Fernando, James Munroe, Felikson, Denis, Sutterley, Tyler, & Siegfried, Matthew. (2023). CryoCloud JupyterBook (2023.01.26). Zenodo.https://doi.org/10.5281/zenodo.7576602

2i2c

2i2c is a non-profit organization that runs open-source infrastructure for collaborative computing, and maintains the CryoCloud JupyterHub used in this workshop. You can see the complete configuration of this JupyterHub in this public repository.

A theme editor for JupyterLab

2023-06-19T08:11:00+00:00

JupyterLab is a comprehensive web user interface for scientific and technical computing providing tools such as notebooks, text editors, consoles, and terminals. Like many similar tools, it allows users to choose from light or dark color themes. However, users may want to further adjust the looks of the interface, just for fun or for specific personal preferences or needs.

The ability to fine-tune contrast, color palettes, and fonts can be very useful for accessibility, an essential requirement for software to be usable by the whole community. There is an ongoing project-wide effort to improve accessibility in Jupyter. Choices of color palettes impact color-blind users while font choices can have a significant impact on people affected by dyslexia, or who suffer from migraines.

This diversity of requirements and preferences shows that end users should have the means to adjust parameters and tweak existing themes. Subtle differences can improve comfort significantly.

JupyterLab themes

Theming in JupyterLab is enabled by the fact that most of the layout and colors of the UI are defined by a set of CSS variables. There is no need for a complete stylesheet: one can set values for the base parameters from which the appearance of the user interface is derived. This system ensures a consistent look and feel throughout the application.

Custom themes provide a set of values for the base CSS variables and package the resulting CSS file in JupyterLab extensions. A search on GitHub returns 29 repositories defining such custom themes for JupyterLab.

Creating a theme requires implementing values for dozens of base CSS variables. This is often achieved by theme authors tweaking the values given in the default dark or light themes.

Generating a consistent palette, testing, and packaging the outcome in the form of a JupyterLab extension requires development skills and is neither direct nor trivial.

A new tool for authoring JupyterLab themes

To lower the bar for customizing JupyterLab we created a new tool providing a simple interface for tuning the JupyterLab appearance interactively, allowing theme authors to:

use the selected colors in their application and “pin down” the result in the configuration,
export the outcome in a form amenable to packaging into a new JupyterLab theme.

The theme editor extension is a theme prototyping tool, a sandbox to test changes in colors, font family and font size, and a configuration tool for end users. It displays a reduced set of parameters one can play with, allowing users to select:

colors through color pickers,
numerical values from sliders (for font size, border radius and width),
font families from a predefined dropdown list.

A screenshot of JupyterLab with the theme editor panel is displayed in Figure 1, with a notebook opened in light theme. Figure 2 shows different screenshots with different custom themes.

Figure 1: The theme editor extension in JupyterLab.

Figure 2: Examples of dynamically editing the color and fonts scheme of JupyterLab with the theme editor.

Color palettes

For all the colors (accent, brand, border, error, info, layout, success, warn), the same logic is applied. The user picks a base color and a palette is automatically calculated using Microsoft’s fast-colors library.

Let’s take the specific example of the layout colors impacting the background of most elements of the interface. They are defined using — jp-layout-colori CSS variables from white to light grays (for the light theme).

- jp-layout-color0: white;
 - jp-layout-color1: white;
 - jp-layout-color2: var(-md-grey-200);
 - jp-layout-color3: var(-md-grey-400);
 - jp-layout-color4: var(-md-grey-600);

The number of colors in the palette fits the number of colors in the CSS set of variables (here the palette contains 5 colors). There are different ways to define colors (hexadecimal, RGBA, HSLA). The latter format has the advantage of giving direct access to luminance L, a measure of the lightness of a given color.

An inverse layout palette is computed for use with most text elements. The luminance of the inverse layout color L’ is calculated as 1-L plus a correction depending on how 1-L is close to 0.5. There isn’t a general CSS rule in JupyterLab concerning elements on top of a background but some PRs were proposed to reinforce the coupling between inverse layout elements and layout backgrounds with the same color index. The contrast still needs to be improved though, by using other palettes or better corrections when defining the inverse layout colors.

The full process just described from picking a layout color to resulting palettes and the corresponding interface is illustrated in Figure 3.

Figure 3: From a color to the layout, and inverse layout palettes with the resulting interface.

Font size and font family

As mentioned previously, font size and font family can be tuned too. Let’s take the example of the — jp-ui-font-size[i] CSS variables defining the text size of most of the text elements in the interface:

- jp-ui-font-scale-factor: 1.2;
 - jp-ui-font-size0: 0.8333em;
 - jp-ui-font-size1: 13px;  /* Base font size */
 - jp-ui-font-size2: 1.2em;
 - jp-ui-font-size3: 1.44em;

A slider lets the user control the base font size associated with — jp-ui-font-size1. The other font sizes are then calculated by applying a scale factor to the base font.

Concerning font families, a non-exhaustive list is proposed (i.e., default browser fonts or Google fonts). It includes both standard accessible fonts (Arial, Courier, Helvetica, Sans Serif, system-ui, Times New Roman, Verdana) and less usual ones to create artistic or special interfaces with cursive fonts ( for instance Dancing Script or Single Day). Only 2 fonts are proposed for code: Space Mono and monospace.

Storing the new theme

Once satisfied with a new theme, users can export it using a button at the top of the theme editor panel. This creates a variable.css file that can be packaged in a theme extension (see the extension template). The new parameters are also synchronously saved in the settings editor and can be restored for the next JupyterLab opening if the boolean useSettings is set to true. If not, the interface will look like in Figure 1: with light theme default CSS values. Resetting useSettings to true will restore the formerly tuned parameters.

Future development

The look and feel of the theme editor UI still needs to be improved. We will work on unifying the styling of all interfaces making use of react-jsonschema-form. It is already used for the JupyterLab settings editor, the notebook metadata editor of JupyterLab 4.0, and several extensions.

Moreover, the current implementation is bound to fast-colors palettes and we may want to use a different approach, like decoupling the layout and inverse layout palettes to reach better contrasts or give more freedom in the color choices.

Any help (e.g., filling issues for bugs or enhancement requests, opening pull requests) to improve the extension is welcome.

Try it out

You can install the PyPI package by running:

pip install jupyter_theme_editor

You can also try the theme editor on Binder.

Aknowledgement

Many thanks to Isabel Paredes for drawing the palette icon!

About the authors

Florence Haudin is a scientific software developer at QuantStack. She contributes to JupyterLab and to ipyleaflet.

Frédéric Collonval supervised this work as a technical director at QuantStack. He is a member of the JupyterLab core team and authored several JupyterLab extensions.

Improving the accessibility of Jupyter

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

Towards a more accessible Jupyter notebook

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.

Introducing JupyterHub’s Outreachy interns! — December 2022 Cohort

2022-12-07T07:45:00+00:00

As part of the community strategic support project funded by CZI’s EOSS grant series, the JupyterHub sub-project has funding to support Outreachy interns through four cohorts over the next two years. We would like to introduce you to the first cohort and the projects they will be working on!

Ogoh Blessing Onyowoicho — Improve Accessibility in JupyterHub

Accessibility is the ability of tools (in our case web tools) to be used by a variety of communities with different disabilities. There are a variety of standards and tools for evaluating and ensuring that a web page can be used effectively by as many people as possible. Work by the Accessibility team is ongoing to define a set of standard tools to improve accessibility across the Jupyter ecosystem.

The JupyterHub project is working to improve the accessibility of its pages to ensure we are providing tools that are as useful as they can be to as many people as we can. During the internship, we will evaluate JupyterHub’s accessibility, find ways to improve it, and integrate accessibility testing into the development process, in collaboration with the Accessibility team, to ensure we do a better job going forward.

Ogoh Blessing says:

My name is Ogoh Blessing Onyowoicho. I am a self-taught Frontend developer based in Lagos, Nigeria and I am an Outreachy intern working on Improving the accessibility of JupyterHub.
I am excited to work on JupyterHub because it is giving me the opportunity to use skills that I have accrued over the years to proffer solutions to problems that affect people’s lives directly. On hearing accessibility, the first thought one has is that it involves building web products that people with special needs can use seamlessly. Though this is part of it, accessibility goes way beyond this. It involves building products that different users (e.g users at different locations, users with different devices etc) can use easily. The thought of contributing to improving the experience of so many people alone excites me.
In the coming months, I hope to learn and continue to hone my skills as I am guided by my mentors and members of the community I get to interact with.

Allan Wasega — Restructure and improve JupyterHub documentation by implementing the Diátaxis framework

JupyterHub has a range of documentation that covers both developer and user audiences in order to help them deploy, maintain, and use their own instance of a JupyterHub. The success of an open source software project to (i) be adopted by users, and (ii) receive meaningful contributions relies heavily on the quality, navigability and accessibility of documentation so that users and developers have all the information they need to achieve what they want to do.

A framework for organising technical documentation has arisen called diátaxis. It takes a systematic approach to understanding user requirements of documentation throughout the lifecycle of interaction with a product and posits that different user needs require different approaches in creation of the documentation, as well as a layout to navigate these different “modes” of documentation.

This project will focus on a refactoring of the documentation for the JupyterHub package. We will begin by performing a review of the present documentation, categorise these into the diataxis framework, and then restructure the documentation files in the repository. Once we have transformed the documentation into this framework, it will be much easier to identify missing and unclear documentation (those that were difficult to categorise). We can then begin to curate resources that can fill the gaps and improve documentation that is not specific enough.

Allan says:

I am Allan Wasega, from Nairobi, Kenya. Broadly, I like to describe myself as a researcher and a writer. Researcher because looking into things to find patterns or hidden information has always been of interest to me. Writer because I figured early on that words allow me to express myself and to communicate to a larger audience than that inside my head :). As a Computer Science student, I looked for ways to bring these two skills together within the realm of computing and that is how I found myself in the technical writing space.
As an undergraduate student, I used Jupyter Notebooks extensively for most of my programming assignments and projects. As a result, when making my Outreachy application, the JupyterHub project immediately piqued my interest because I did not know that there was a way to serve Jupyter Notebooks to multiple users, such as within a classroom setting. Presently, I serve as a mentor at KamiLimu, which is a mentorship program for students pursuing technology-aligned courses in tertiary institutions in Kenya. One of the objectives of KamiLimu is to introduce students to tech specializations such as Data Science and Machine Learning, which, from experience, uses Jupyter Notebooks! Therefore, I am excited to work on JupyterHub because I will be learning about and helping to improve a product I hold dear and which I can use to advance the skills of the next generation of computer technologists in Kenya.
First, I hope to gain a deep understanding of how JupyterHub works so as to spread the word about it and its functionalities. Second, I hope to apply and advance my technical writing skills. I encountered the Diataxis Framework earlier this year while working as a technical writer at Tingle Software, a Nairobi-based software company. I have also been following Daniele Procida (the author of the framework) on Twitter for a while now and his work has been quite inspiring. Through this project, I will apply the Diataxis Framework to restructure JupyterHub’s documentation and, in doing so, further my understanding of the framework. Finally, I am passionate about mentorship, especially in the tech field. Therefore, besides expanding my professional and personal networks, this project will enable me to learn how to conduct mentorship within a global setting, and I can, in turn, apply this knowledge within my local community.

Sheila Kahwai — Create a reusable JupyterHub pytest plugin

JupyterHub is a modular and extensible project, with parts, like the proxy, authenticator and spawner, that can be easily changed and extended. Testing the functionality of these components against JupyterHub is important and it requires various hub setups that can sometimes become complicated.

Currently, each of these hub components and the hub itself define their own testing infrastructure, building everything from the ground up using the pytest framework. But some of this complex work is either repetitive across JupyterHub sub-projects, or under-specified for some of them.

This project will abstract out these common parts into a separate testing framework. This framework should be a pip-installable pytest plugin that would provide various hub functionalities through pytest fixtures. These fixtures can then be re-used by JupyterHub and its components to bootstrap their own testing suite.

Integrating this plugin will drive some important refactoring work of the current testing architecture of JupyterHub and have a great impact in improving the overall test coverage, maintainability and continuity of the JupyterHub project.

Sheila says:

My name is Sheila Kahwai. I am a self-taught python developer from Nairobi, Kenya, working to specialize in back-end engineering.
I am excited to work on JupyterHub because it has made many products I have used throughout my learning journey. It is a privilege to work with a diverse community that has created products that are very useful to equally diverse users like myself.
While creating a reusable JupyterHub pytest plugin, I hope to gain more insight into creating plugins for massive codebases to improve maintainability and scalability with clean and reusable code. Through this project, I look forward to improving the overall testing infrastructure of the various JupyterHub components.

Welcome to the interns! We’re so excited to start working with you!

Jupyter Accessibility Workshops Wrap Up

2022-04-09T04:48:00+00:00

All good things must come to an end, and Jupyter accessibility workshops are no exception. While I may be sad that this series is over, there are many, many things to celebrate and more to look forward to! Let’s break it up into what we did, what we’ve learned, and what we’re going to do in the future.

A quick recap: Jupyter accessibility workshops were a series of events where we connected Jovyans, accessibility experts, and the wider open-source ecosystem for learning and practice in improving accessibility across Jupyter projects. For more specifics on the events individually, visit the January and March event announcements.

What we did

We gathered, we learned, we contributed fixes, all with a dose of laughter. Across three events, our attendees were small in number but mighty, greeting our corner of the internet with

1 fantastic captioner
2 expert accessibility talks from Frank Elavsky and Eric Bailey
3 Saturdays
4 first-time contributors to Jupyter projects
5 Jupyter projects discussed to better understand how we can support the ecosystem’s accessibility needs as a whole
6 hours of events
25 participants, with several friendly faces appearing for more than one event
88 image descriptions written (contributed between Juptyer documentation and Jupyter.org)
~1000 smiles

What a busy season!

We kicked off the events with the knowledge of Frank Elavsky. This included an energetic discussion around the ways that data visualization is already an accessibility accommodation, how to prioritize user feedback and needs, and how to repurpose or reconfigure what we already have to something accessible.

For the second event, our community contributed accessibility fixes to Jupyter projects in the form of image descriptions. This event not only introduces these descriptions — usually alt text — but gives participants a chance to try it out for themselves. Practice always leads to more questions and great conversations, like how to handle long documentation diagrams or when the documentation might benefit from removing an image.

We regrouped in March to learn from Eric Bailey’s vast accessibility experience and to better understand the discussion from a wider perspective. He gave us wonderful examples of accessibility efforts from history, as well as inspiration for how to continue our community’s efforts.

You can find all event resources by date at the following links:

What we learned

With such a rich mix of people and the spotlight on some wonderful speakers, these workshops were privy to discussions at the intersection of digital accessibility and open source. Here are the biggest themes that emerged across all the events.

Guidelines are the floor. not the ceiling. Creating a pleasant accessible experience will require more than sticking to guidelines.
Do it, don’t just read about it. Once we started trying to describe Jupyter images, the best questions and discussions appeared.
It’s all about context. What an image is communicates is determined by what is around it; use this to write good descriptions.
Don’t be afraid mistakes. Because accessibility still isn’t the norm in many open source spaces, expect to be trying, failing, and iterating.
Listen to community members first! If they say communicate accessibility failures that are blocking them, prioritize those efforts when you can.

What’s next

Accessibility in Jupyter spaces is far from over, and we’d love to have you find your new favorite place on the internet here. Just as Jupyter is not a single project, accessibility goes beyond what we covered in the workshops.

We started somewhere designed to be approachable for people of all experience levels, but the next major steps include prioritizing the feedback of disabled people in Jupyter, solving existing issues across projects, and creating methods for sustainable accessibility within our community. These problems won’t be solved with Jupyter knowledge alone, accessibility experience alone, code sorcery alone, documentation brilliance alone, or any other single skill set alone. But they can be solved together. Bring your skills with you, and we can find a place for you here!

If you’d like to get more involved with accessibility efforts, feel free to join our community via

• The jupyter/accessibility GitHub repository, a place for gathering cross-project on GitHub.

• Jupyter’s Discourse section for accessibility, a place for gathering cross-project separate from Jupyter codebases.

• Fortnightly JupyterLab accessibility meetings (found on the community calendar).

• For JupyterLab efforts, visit the JupyterLab accessibility GitHub project, where issues and pull requests for are listed.

• Open a GitHub issue to propose an accessibility change (please check if a similar issue already exists and add a comment to that one if possible).

Join us for the Jupyter Accessibility Workshops (Part 2)

2022-03-04T15:55:00+00:00

I’m happy to announce the next pair of Jupyter accessibility workshops happening this March! As a part of the third community workshop cycle, these workshops are designed to increase accessibility knowledge within the ecosystem and make Jupyter projects more usable for disabled people.

With community feedback as the inspiration, the following two events will open up discussions around general accessibility foundations and evaluating software with manual testing. If learning, contributing, and making connections in accessibility spaces sounds interesting to you, please join us. No previous experience needed.

What was part 1?

If you noticed the “Part 2” in the title, you might want to visit the blog post announcing the last two workshops for more context.

We also have resources from the last two events available!

What’s up next?

Part 2: March 12 and 19

On March 12, we’ll be joined by Eric Bailey as he introduces us to accessibility and inclusive design strategies. This event will provide some much-needed foundation and common language for our community as we continue to make accessibility a collective priority. People have often asked me how to get started in considering accessibility in their day-to-day work, so we are extremely fortunate to learn from one of the best!

On March 19, it’s sprint time. For this event, we’ll be focused on learning how to manually audit software for accessibility. This skill is great no matter what you spend your time on, whether testing your own work, reviewing someone else’s, or understanding expected accessibility experiences. We’ll practice testing methods as a group before contributing our review to projects across the Jupyter ecosystem. Don’t be intimidated, though, all are welcome at this event; no prior Git or GitHub knowledge is necessary!

To find these events in your timezone, please visit the Jupyter community calendar.

Who can attend these events?

As with the last two, Jupyter accessibility workshops are open to everyone! These events are also entirely remote, so all you need is to be online. Each event is stand-alone, so you can sign up to attend one or all depending on your availability and interest.

Ideally, these events will be attended by a mix of

Jupyter contributors to provide specific insight about the community and projects
People with accessibility skills to advise on the knowledge areas the Jupyter community currently lacks
Newcomers willing to learn and give us feedback on how to make these learning curves better for everyone

Please consider attending if any of these descriptions sound like you!

You can sign up for a Jupyter accessibility workshop individually. You are welcome to attend both events, though you will need to sign up on both forms. Please note that attendance is limited to about 40 attendees per event to make sure we can provide a quality experience with a small event team. (But don’t despair! Recordings of speaking events and notes for all events will be available to all afterwards.)

Where can I get more information?

These events are planned publicly on GitHub; you can explore the accessibility workshop planning repository for more information.

Thanks!

Once again, these events would not be possible without a number of people across the Jupyter community. My thanks wouldn’t be complete without acknowledgement for all Jovyans who have already joined in accessibility efforts, like our wonderful attendees from the last two events whose spirit keeps me inspired every day!

Of course, many thanks to the Jupyter Community Building Committee for supporting funded community events and being a constant presence throughout all our planning adventures. And thank you to the original team that proposed these workshops and made them possible.

Join us for the Jupyter Accessibility Workshops (Part 1)

2022-01-06T18:30:00+00:00

At long last, Jupyter accessibility workshops are here! This is a series of Jupyter community workshops aimed at increasing accessibility awareness within the ecosystem and making Jupyter projects more usable for disabled people.

The goal is to make existing accessibility efforts more prominent across the many Jupyter projects. Much of what we discuss will relate to the Web Content Accessibility Guidelines and how to apply them in open source, scientific spaces where this work has historically been neglected.

These workshops are a series of events proposed for and supported by the third community workshop cycle.

What are these events?

These workshops are a series of four virtual events alternating between learning from experts and contributing to projects.

They’ve been designed by listening to community requests and combining event types to include people of different skills and across communities. In total, they combine Jupyter experts and accessibility experts, learning and action, and working with old friends and making new connections.

Part 1: January 15 and 22

On January 15 we’ll be hearing from Frank Elavsky about how to build inclusive data representations. You can learn more about this work at Chartability, a framework for creating enjoyable and accessible data visualization experiences. I’ve heard so many questions from the community about how to author more accessible content in notebooks and otherwise, so I’m personally thrilled to announce this speaker. (Check the event time in your timezone.)

On January 22 we’ll host a sprint to learn how to write image descriptions and practice by contributing as a team to Jupyter documentation. Image descriptions, usually alt text, are a great place to make use of different skills and learn from one another. Whether you’re a Jupyter community member who wants to learn about accessibility, an accessibility expert who wants to learn about Jupyter, or someone new to both, all are welcome at this event. No prior git or GitHub knowledge necessary! (Check the event time in your timezone.)

Part 2: March

Two more events — a speaker and sprint event — are scheduled in March 2022. Mark your calendars and get excited for more details after the first two events.

Who can attend these events?

Jupyter accessibility workshops are open to everyone! These events are also entirely remote, so all you need is to be online. Each event is stand-alone, so you can sign up to attend one or all depending on your availability and interest.

Ideally, these events will be attended by a mix of

Jupyter contributors to provide specific insight about the community and projects
People with accessibility skills to advise on the knowledge areas the Jupyter community currently lacks
Newcomers willing to learn and give us feedback on how to make these learning curves better for everyone

Please consider attending if any of these descriptions sound like you!

Some events may be more useful to you if you already have certain skills, so be sure to review the sign up forms per-event for specific details.

You can sign up for a Jupyter accessibility workshop per-event. Please note that attendance is limited to about 40 attendees per event to make sure we can provide a quality experience with a small event team. (But don’t despair! Recordings of speaking events and notes for all events will be available to all post-event.)

Where can I get more information?

These events are planned in public on GitHub; you can explore the accessibility workshop planning repository for more information.

You can also read the agendas for the first two events:

Thanks

I want to take a moment to thank some of the many people that have helped make these events happen.

First off, thanks to the Jupyter Community Building Committee for encouraging and supporting the logistics of this and other community workshops. Thank you to the original team that proposed an accessibility workshop for their hard work and help in keeping the proposal going. And, of course, thanks to everyone in the Jupyter ecosystem who have already been committed to accessibility efforts. None of this would be possible alone.

Jupyter Blog - accessibility

Recent keyboard navigation improvements in Jupyter

Keyboard navigation in JupyterLab

Notebook Tab Traps

Future accessibility improvements

Feedback

About the Authors

Acknowledgments

Desktop GIS software in the cloud with JupyterHub: A QGreenland workshop success story

About QGreenland

QGreenland’s 2023 researcher workshop

A “personal computer” in the cloud

Challenges scaling QGreenland

Outcomes

Conclusion

Acknowledgements

Reviewers

CryoCloud

2i2c

A theme editor for JupyterLab

Improving the accessibility of Jupyter

CodeMirror 6 and Notebook 7

Initial accessibility audits

Beyond accessibility audits

Acknowledgements

About the Authors

Introducing JupyterHub’s Outreachy interns! — December 2022 Cohort

Ogoh Blessing Onyowoicho — Improve Accessibility in JupyterHub

Ogoh Blessing says:

Allan Wasega — Restructure and improve JupyterHub documentation by implementing the Diátaxis framework

Allan says:

Sheila Kahwai — Create a reusable JupyterHub pytest plugin

Sheila says:

Jupyter Accessibility Workshops Wrap Up

What we did

What we learned

What’s next

Join us for the Jupyter Accessibility Workshops (Part 2)

What was part 1?

What’s up next?

Part 2: March 12 and 19

Who can attend these events?

How do I sign up?

Where can I get more information?

Thanks!

Join us for the Jupyter Accessibility Workshops (Part 1)

What are these events?

Part 1: January 15 and 22

Part 2: March

Who can attend these events?

How do I sign up?

Where can I get more information?

Thanks