-
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's zoom a brainstorm? JupyterLab keyboard navigation and usage #210
Comments
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗 |
Hi! I'm tagging you on this issue because I have reason to believe that you might be interested (because of work on keyboard issues, or accessibility, or windowed rendering). I'm sure I missed someone, so please please please tag anyone else you think might be interested! cc @andrii-i, @t03857785, @isabela-pf, @trallard, @afshin, @fcollonval, @krassowski, @SylvainCorlay, @tonyfast, @ohrely, @marthacryan, @g547315, @vidartf, @scmmmh, @jasongrout, @GabrielaVives, @HaudinFlorence |
I am interested! Let me know how I can be of help. |
I am interested to participate as well. Also wanted to link outcomes of workshop on keyboard shortcuts hosted by @GabrielaVives and @HaudinFlorence: jupyterlab/jupyterlab#14240. |
Nice @gabalafou, I'm am also interested to participate. |
Definitely interested in joining this, if you agree a meeting I will do my best to join |
Interest here as well, so please invite. |
I'll try to join too. |
Hi friends, I'm so excited to see so much interest! The next step is to figure out a time:
Please vote for your preferred time(s) using the emoji reactions. And if you think there's a better time, please don't hesitate to suggest it and explain why, thanks! |
I am interested to join with a preference for August 30th. |
Okay, great! Let's do August 30th! I asked to block out 90 minutes following the JupyterLab team call, but we don't have to use all 90 minutes. |
Thanks for setting this up! I'll join as well. |
We will be using HackMD, in addition to Zoom, to help guide discussion and take notes. |
Closing issue because the meeting happened :) |
Some of you might remember yesterday that there was a moment when I mentioned that keyboard navigation for screen reader users is probably a better story than keyboard navigation with just a keyboard and no screen reader. I was going to try to screen-share demo what I meant, but it was a little too much for me at that moment to try to attend to the call while simultaneously running VoiceOver. But this same topic came up in a pull request, and I left a comment there with a screenshot that explains what I was referring to yesterday in the call. |
yea, i was lost when this hasty comment was made. the screen reader navigation of lab and notebook is not better, it is more confusing and reveals more WCAG failures. the best we can say at this point is the figure above shows landmarks in lab with multiple notebooks open. the accNames for the regions are non-unique and failure WCAG. which notebooks cells? do i navigate to the toolbar directly? what can i interact with in the status bar that just called information? what is the main region? there is nothing interactive there. the repetitive, ambiguous naming should be considered for an assistive landmark navigation experience in lab. in notebook, the main region is apparent. we can't have landmarks to multiple documents, document nagivation is handled by tabs in the browser. below demonstrates how the notebooks for all project is hoping to test to the assistiveness of including cells as landmarks for screen reader users. further, we'd want to consider headings as another way to navigate the document. currently, lab with multiple notebooks open will fail WCAG because there are multiple h1s. Screen readers organize the headers by level and will make obscure navigation experiences in multi document mode. Headings, in single document, make A LOT of sense, and even including code objects in the heading/landmark navigation could improve the developer experience and embrace the literate programming qualities of the notebook. a focused event on landmarks, heading, and screen reader navigation might be a good workshop. accessibility bookmarklets could allow non screen reader users to understand these navigation pattern. this event would spend a lot of time considering the roles of elements, their accName, and their accDesc. understanding these relationships will improve the quality of the jupyter experience for everyone. |
Edit: this meeting took place, notes from the meeting are in HackMD
Who?
Anyone interested!
In particular, end-users who care about keyboard-related issues in JupyterLab (shortcuts, tab-navigation, etc.) and anyone who has worked on these issues (designers, developers, etc.).
What?
A one-time Zoom meeting for people to join and brainstorm ideas around keyboard navigation in JupyterLab.
The meeting will be about generating ideas, not reaching decisions.
When?
August 30, 2023 at 17:00 UTC (click link for the time in your time zone)
90 minutes (but we don't have to use all 90 minutes)
Where?
Zoom! Zoom link in calendar event
Why?
jupyterlab
repo, such as but not limited to the following:I will provide a bit more context later. But I wanted to get this up before the end of the week!
Notebook 7 or JupyterLab?
Both! I will provide more context later, but I want to encourage people to think about both Notebook 7 and JupyterLab when generating ideas to solve the keyboard navigation issues.
Notification plan
Closing this issue
I will close this issue if any of the following have happened:
The text was updated successfully, but these errors were encountered: