Blog post on the recent improvements to the keyboard navigation in JupyterLab #142
Comments
|
thanks for sharing. i would encourage y'all to confer with jupyter/notebook#6800 jupyterlab/jupyterlab#9399 to see if there are any specific long standing issues that you may have sorted especially any with specific impact to notebook. it would be good to know where progress was made on these official audits. |
@tonyfast I added a comment to update the issue jupyterlab/jupyterlab#9399 (comment) |
|
Quick update: We have created a draft post for the Jupyter blog. The link to the draft is https://blog.jupyter.org/keyboard-only-jupyter-4df32f97628d. Private notes can be added by users authenticated on Medium. |
|
"notebook tap traps" looks like it should be a title but got lost. same with the "feedback" title. |
|
the title says "Keyboard-only Jupyter" and major improvements. while this may be the case, is possible to set keyboard users up for failure if we aren't sure that they can enjoy the entire experience of jupyter? how sure are we that keyboard users can succeed at using jupyter? have we tested the experience after the changes? for example, if i am a keyboard user who needs custom settings, i still can not easily change settings. |
Good catch, this is now fixed in the draft and issue. |
Major blockers for using the notebook UI with the keyboard have been resolved, and we are definitely in a better place now than before! However, as you point out, there are parts of the Jupyter UI that still need to be improved in this regard. |
|
i agree that foundational blockers have been resolved. i agree we are better than before. from the advocacy side, we should be cautious of creating inaccessibility by over-promising and under-delivering to disabled users. we do not know if we are providing sufficient access to keyboard users. effected users have not been able to provide feedback. i see this work as offering an opportunity for community action. strong messaging about impact of 3 PRs could indicate access where there may not be. it seems more consistent for jupyter's accessibility efforts to message progress rather than access. we should be realistic about the access we and are not providing. for example, screen reader and keyboard users will encounter access challenges. |
Maybe we should just restrict a bit more the title, by putting all together, like Major improvements for keyboard-only Jupyter. |
Are you sure about this? I logged on to Medium and I can't figure out how to do anything other than view the draft. I will make some edits to the Google Doc. As for the formatting of the Medium draft, could we make my profile photo smaller? I'm uncomfortable with it taking up so much space. I get that it's important to put a human face on these things, but author avatars on blogs are usually much smaller |
Thank you for going over this. I have updated the top comment of the issue with all the changes that were merged on the Google doc - and I am doing the same with the draft post on medium. |
I reduced the size to 200x200px. |
Would it be possible to schedule a review of the keyboard navigation issues in the next accessibility meeting ? It would bring some visibility on remaining issues before posting the blog post. |
|
My initial reaction was similar to that of @tonyfast - the first thing any reader will see is "Keyboard-only Jupyter", and while there have been considerable improvements in keyboard navigation, we are far from providing sufficient access to keyboard-only users, and that is something we have to be clear and transparent about this. In that regard, I'd suggest using a more fitting title that indicates progress without misleading potential readers (something like "Recent keyboard navigation improvements in Jupyter" 🤷🏻♀️) Other comments and suggestions below:
I know this specifically points/refers to the keyboard audit run by Isabela. Still, over the years, there have been other audits and issue reporting by several contributors highlighting many accessibility issues (including keyboard navigation), so I'd prefer if these contributions are also acknowledged.
I share the sentiment, but this opens several questions for me like who will do this? And even if an audit happens, who will fix these issues? Is this within the scope of Jupyter accessibility? - again, I am trying to be cautious and conscious that most plotting libraries are hugely inaccessible right now, and the Jupyter accessibility team has their hands more than full with Jupyter-related accessibility work. This is another potentially misleading sentence (i.e. saying that we will somehow take on this action) or, at best, unclear.
Wearing my external reader hat - it is unclear who "us" refers to.
For consistency across authors, perhaps this should also mention that Gabriel is a JupyterLab core team member too. |
|
I have updated the post in the first issue comment to reflect the last included changes. |
|
yes! i really like this version. it is tempered and demonstrates a lot of concern for this accessibility work. thanks for working with us on this y'all. |
|
Ditto - this version feels much more honest and signals openness to improvements and a strong commitment towards accessibility Thanks all |
The first version was also definitely honest. But I am happy we get to a text that everybody likes. |
zero need for this. this is disrespectful of the time you asked of people to review. it undermines the emotional labor that is necessary to review and give feedback about accessibility and disability inclusion. i really appreciate the effort of everyone working on these fixes. these wins should be celebratory events. instead, for the second time, blog posts have been divisive. that harms a community we work very hard to protect. accessibility advocates will become less eager to review these posts. please recognize there is significant labor and experience required to produce inclusive messaging. it was important to get accessibility 👀 on this post because we were able to remove some internalized ableism that was coded in the original post. now, as a collective effort, we have more equitable and inclusive messaging. its a great post. it has excellent calls to action. it does not dismiss the lived experience of disabled people. it is a great collective work. glad we could vet it. so thank you all to the candor of the original authors in allowing us to provide feedback. hopefully we can turn these events in community wins rather than division. |
Dear Tony, please remain civil. The last time I connected to the public accessibility meeting, you shouted at me five minutes into the call because you had not seen the content of the text that I had come to present beforehand. You also made accusations of backchanneling because we had requested permission to include someone's name before presenting the draft to the complete crowd.
While I appreciate that we've come to a conclusion, the last two messages embed serious accusations (being dishonest, now ableism). Two weeks ago, it was backchanneling (literally when I came to propose collaboration on a blog post). Being shouted at, accused of all kinds of misdeed, is indeed not the most pleasant experience. |
|
internalized ableism is a subconscious experience where we make assumptions based on a dominant ableist culture. it takes a critical lens to understand what internalized assumptions we have about people's lived experiences. part of accessibility work is using that critical lens to discover these assumptions and revise them. accessibility revisions came last each time we've worked on public content together. when this happens, accessibility appears to be a barrier to publishing work and creates an defensive posture. in our last confrontation, from a very defensive posture, i admitted speaking ill towards you and apologized publicly. i stand by my accessibility advocacy work. that work means advocating for the jupyter accessibility community and making sure that people not in the room are included. you can take this personally or consider how this advocacy revised the original content. successful inclusive design efforts will lead with accessibility. it takes time to make the a11y caboose the engine, but we are actively work on it right now! when accessibility is included sooner we have more time and space to put on our critical lens to have dialogues about who we include and who we exclude. sometimes, i really wish you could appreciate the power you have as a CEO in this community. i don't understand why you have to put effort towards antagonizing a volunteer who is personally invested in disability inclusion. seems misplaced when there is other work to do. |
|
@SylvainCorlay - I must ask you to treat other contributors here respectfully. Calling others out, putting others down, and/or similar attitudes/behaviours is not something we do here (Jupyter accessibility or Jupyter altogether). This is unnecessary extra emotional labour I am doing. Still, I will do it nonetheless because I acknowledge that written communication can be nuanced. And because I care about this community and the safe and welcoming space we have worked hard collectively to build.
I never mentioned dishonesty nor accused anyone, but I said the post felt "more honest" in the sense of being sincere and truthful about acknowledging and celebrating how far we have come while recognising there is still much to be done. We are being forthcoming about the tools' limitations and current status. In the future I will make sure to not write rushed comments or better chose my words to avoid misinterpretation. On the matter of internalised ableism I will reference Tony's message:
Internalised ableism is but a result of repeatedly experiencing or witnessing mistreatment and oppression of oneself (as a disabled individual) and others over time. It doesn’t mean you are ableist towards others or lack compassion for others. Acknowledging, identifying, and overcoming internalised ableism is a long and arduous process that requires loads of support, compassion and a safe environment. Unfortunately, attitudes and situations like the ones above threaten this safe space we have created for those of us working towards disability inclusion and disabled community members and leave a sour taste when we should be celebrating an incredible amount of collective work and care. |
I don't think I put down anyone. Quite the contrary. As soon as I proposed this collaboration, I was interrupted and shouted at in a public meeting, which is a clear violation of the Jupyter code of Conduct. I took it upon myself, and decided to continue the collaboration because I care deeply about the subject. My message to Tony is specifically asking him to remain civil.
Okay. I understand you did not mean I was being dishonest. I may also not have taken it this way without the earlier context.
I agree that there is a terrible climate. |
|
I am closing this issue since we have finalised the blog post. |
This comment was marked as resolved.
This comment was marked as resolved.
|
Hi, the code of conduct says that any community member may act to defuse a situation. So, as a community member, noticing that it's gotten a little heated on this thread, I am asking on behalf of the code of conduct, which we are all expected to uphold, to bring the temperature down. As a community member, I am asking us to remember the CoC values: friendly and patient, welcoming, considerate, respectful, careful in words, moderating expectations, trying to understand where others are coming from, quick to apologize. As such, I believe the right course of action right now is to hide the previous message and lock the thread. I also want to be very clear that I am not directing this message at one person but to all of us in the community. Thank you. |
Hello everyone,
In our last public meeting, I presented a draft article that we proposed to publish on the Jupyter blog. The post covers the recent improvements to the keyboard navigation in JupyterLab and in the notebook user interface.
These improvements are the result of the collaborative effort of multiple contributors. Notably, substantial contributions were made by @gabalafou from @Quansight (supported by CZI through an EOSS grant) and @brichet from @QuantStack (supported by @InseeFr).
In our discussion, we proposed publishing the article through the Jupyter medium account, with representatives from both organizations co-signing it.
We welcome your input and invite you to provide suggestions to enhance the proposed article's content. If you have any additions or modifications in mind, please share them. As emphasized during the meeting, if you believe there are individuals deserving of co-authorship or acknowledgment in the article, we encourage you to put forth their names.
Regarding the timeline, my suggestion is to allocate approximately one week for gathering feedback and suggestions on the article. Ideally, we aim to finalize and release the article just before the year-end holidays.
Current state of the draft
Recent keyboard navigation improvements in Jupyter
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.
Keyboard navigation in JupyterLab
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:
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.
The text was updated successfully, but these errors were encountered: