Jupyter accessibility meetings 2020
Contents
Jupyter accessibility meetings 2020#
09.30.20 Meeting Minutes#
Attendees#
Martha (@marthacryan ) Max (@telamonian ) Karla (@karlaspuldaro) Alek tony (@tonyfast) Alex (@ajbozarth) Isabela (@isabela-pf)
Notes#
Say hello!#
Introduce yourself however you like. What do you want to get from this meeting?
Our group has limited experience with accessibility work previously. We are all learning. Hooray!
No one here uses a screen reader or other assistive software.
Should we do outreach to have people involved who use this? Probably. Find a way how.
Why this meeting? Why now?#
Multiple JupyterLab team meetings where we discuss people’s interest in making JupyterLab accessible, but those interested don’t know where to start (both in learning about accessibility and wrangling JupyterLab).
Let’s be resources for each other! Share skills, knowledge, and morale.
3.0 release plans to have a lot of added features, 4.0 might be a good time to push for improving what is already there.
yes definitely, no way is this getting in 3.0
What goals do we have?#
WCAG specifications. Let’s review them and figure out how to implement them. - https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines - We reviewed this document to start getting on the same page.
Get different people involved. Get people who actually use accessibility features/ screen readers/ assistive software. - Avoid single point of failure problems. Community engagement needs to be done together.
Are consoles a good place to start? Some older consoles are established and already have accessible affordances for us to start working with.
Another resource exploring what a typically inacessible experience (web comics) can be like with affordances.https://comica11y.humaan.com/ (comics use cells too… :eyes:)
Need a plan to reviewing/getting feedback on JupyterLab as is and the changes we make. Can’t just rely on accessing disability communities because it’s our responsibility to fix it.
What are people working on?#
Max
accesible slider Widget
probably a one-off, not really reusable in current form
LabButton
fully accesible replacement for current blueprint-based
Button
in @jupyterlab/ui-componentsworking on PR, hopefully have an initial stab done by the meeting
based on
tricky part: the button text
the reccommendation: always use an HTML button element, always label like
for icon buttons (eg all of our toolbar buttons), the suggestion is to hide the text using CSS
-
.hide { position: absolute !important; top: -9999px !important; left: -9999px !important; }
or
.visuallyhidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }
seems convoluted, can we just use
aria-label
(this is exactly what it’s for)? Opinions seem mixed
I need resources to finish hashing out the styling system for the
LabFoo
componentsbigger picture: as concrete problems arise (like the text vs aria-label thing for LabButton), we should use them as a jumping off point to seek outside expert opinion/help
Isabela (and tony, Gonzalo, Eric)
Color contrast https://github.com/jupyterlab/jupyterlab/issues/8832
Next steps#
Do we want to share these notes somewhere (team-compass)?
Martha and Max working on UI components (LabButton?)
Alek might help too!
Spend an hour introducing everyone to JupyterLab UI so we understand what we are working with and start identifying places to work with it. (Do this later when people have done some exploration first)
Removing UI components based on blueprint
Reach out to Chris Holgraf, Tania Allard, and Jason Grout about contacts we’ve made in this area already (tony)
Find and share resources (everyone)
Settings UI (Alex). Will start after JupyterCon. Needs accessibility reveiw for the design.
Meet every other week (twice a month).
10.21.20 Meeting Minutes#
Attendees#
Max @telamonian Isabela @isabela-pf Martha @marthacryan Alex @ajbozarth Jason Grout @jasongrout
Notes#
Logistic check in#
Does this time seem like it will keep working? Yes.
If so I’d rather schedule it further out and add it somewhere more public so people can drop in. I can bring this up in JLab team meeting too, if so.
Proposed Goals#
We’d like to propose concrete accessibility goals would be so that we can organize it into JupyterLab’s release cycle and encourage people to focus on them. These are some ideas of where to start.
Max brought up screen readers. Find most common and start from that paradigm.
discussion on github: https://github.com/jupyter/accessibility/issues/14
Keyboard accessibility.
Closing accessibility issues that already exist. There’s already been work pointing out some of the issues (like here https://github.com/jupyterlab/jupyterlab/issues?q=is:issue+is:open+web4all)
Can we produce guidelines/docs/resources (or something similar)? This might help other people get involved and make the effort more sustainable.
Creating an actionable plan and possibly getting some grant money/full time help
What are people working on?#
Isabela
Reached out to Tania Allard and Chris Holdgraf. They made point to keep all discussions online, so there shouldn’t be anything we are missing. Haven’t heard from Tania. This just means I’m trying to collect and understand what has already happened so we don’t redo or overlook existing work.
Here’s some common places these discussions live (in Jupyter):
Jupyter Discourse accessibility Category https://discourse.jupyter.org/c/special-topics/accessibility/29
Jupyter accessibility repo https://github.com/jupyter/accessibility
JupyterLab accessibility issue label https://github.com/jupyterlab/jupyterlab/issues?q=is:open+is:issue+label:tag:Accessibility
Jupyter Notebook accessibility issue label https://github.com/jupyter/notebook/labels/tag:Accessibility
JupyterHub accessibility issue label https://github.com/jupyterhub/jupyterhub/labels/accessibility
Accessibility resource doc. WIP. Please feel free to add so we can help each other learn. Don’t let it get in the way of doing other work, but add as you find useful things. https://docs.google.com/document/d/12cusZV0j91yZTty_BQndorwTIgRloKR7WEWP2aGNp5A/edit?usp=sharing
Next steps#
Install NVDA or JAWS and gain familiarity with screen readers in general as well as JupyterLab
Isabela needs to triage existing JupyterLab issues so we can assign/move forward with them
Try and reconvene hackathon group to make sure we are understanding the same issues and have proper context to move forward and not repeat work that’s already been started.
Explore Phosphor and Lumino accessibility issues and PRs. This might be the metaphorical root of a lot of our problems. - Big PRs in the DOM and menu system that started but did not get finished
Look for grants for funding a full-time accessibility dev
Schedule meeting with Jason catching us up on work that’s been done in Phosphor
Explore Firefox accessibility tools. They’ve been recommended as a good starting point.
11.04.20 Meeting Minutes#
Attendees#
Martha @marthacryan Max @telamonian Alex @ajbozarth Jason @jasongrout Isabela @isabela-pf
Notes#
If needed, recap/point to the notes and resources for our Phosphor PR meeting last Monday for people who weren’t able to make it.
Covered what decisions were made and our current goals (transfer the problems we already know about in Phosphor to Lumino and finish off what was originally Hack4All work).
Are these meetings something we’d want to have on the Jupyter community calendar?
Yes! It will be brought up in next week’s JupyterLab team meeting for approval/necessary steps.
Need to see if we can find or get data on what developers who use screen readers use in terms of OS
What are people working on?#
Martha: #129 - Moved PR from phosphor to lumino, reviewers?
Gonzalo: Following up on Phosphor tutorial videos. Confirmed we can repost them, but need to get license. - Also need a PR for Lumino docs once the videos get set up.
Next Steps#
Alex: Review #129 Add isToggleable command state.
Gonzalo: Get final info about reposting Phosphot tutorial videos for Lumino docs
Isabela: Move Phosphor issues to Lumino. Also consolidate issues from other repos where relevant so we don’t have to look for issues across as many repos anymore.
Goal
Once those three Phosphor PRs are fully up and ready to be reviewed/merged, then we can reach out to experts to talk more.
Potentially asking for a meeting where we watch experts test PRs so we can learn how to better test too (and not just rely on them).
11.18.20 Meeting Minutes#
Attendees#
Martha @marthacryan Karla @karlaspuldaro Alex @ajbozarth Max @telamonian Jason @jasongrout Thomas @manfromjupyter Isabela @isabela-pf
Notes#
Welcome Thomas!
What are people working on?#
Martha
PRs jupyterlab/lumino#129 and jupyterlab/lumino#131 merged! -Hooray for Martha! Great job getting that done!
Max
Requesting review on jupyterlab/lumino#132 rebasing for lumino.
Isabela
Next Steps#
Martha will test her PRs with NVDA.
Martha will make an issue for isToggleable additions to #9365. Will also start working on it.
Max will update jupyterlab/lumino#132 with the items on the checklist. - Also create a binder.
Thomas will review JupyterLab and perform an audit of all/most of the accessibility issues needing to be addressed to ensure an optimal user experience for all users with visual, auditory, ambulatory, or cognitive handicaps. Goal will be to uncover all that is needed to become fully WCAG 2.1 compliant. Will be using JAWS for the screenreader when a screenreader is necessary, but reported issues will be for all of them, not screenreader specific. - Setup following https://jupyterlab.readthedocs.io/en/latest/developer/contributing.html - maybe
pip install —pre jupyterlab
- Post issues to jupyterlab repo with accessibility label.Isabela will consolidate the accessibility issues across repos where appropriate (probably jupyterlab or lumino). Will bring the new issues for the next meeting so we can keep moving forward with the problems we already know about.
12.02.20 Meeting Minutes#
Attendees#
tony @tonyfast Max @telamonian Jason @jasongrout Alex @ajbozarth Karla @karlaspuldaro Gonzalo @goanpeca Martha @marthacryan Thomas @manfromjupyter Darian @afshin Isabela @isabela-pf
Notes#
There are overlap in infrastructure needs for an accessible JupyterLab and mobile/tablet support for JupyterLab. Maybe this is an opportunity to get more people involved in this work since there have been a lot of requests for mobile/tablet support.
Triage of existing accessibility issues This will be cross-referenced, updated with #9399, and stored in this project from here on out.
Reviewed from diagram-codesprint/phosphor, diagram-codesprint/jupyterlab, phosphorjs/phosphor, jupyterlab/lumino, and jupyterlab/jupyterlab (jupyter/accessibility has been more organizing focused).
Isabela proposes continuing to focus on what was found in Hack4All first.
Issues Isabela wants to look into more
JLab #6575 (update of diagram-codesprint/jupyterlab #8) Has merged PR #6359, but didn’t close the issue.
JLab #6576 (update of diagram-codesprint/jupyterlab #9) and #6404 Looks like a reference for UX of these accessibility changes and proposed solutions.
JLab #1095 Visual/additional/any cues for running commands (this was to be put to phosphor, review if it was already done or not)
JLab #911 An audit issue about what seems to be the first JLab accessibility review. I need to check if they are or need to be represented in other issues.
diagram-codesprint/phosphor #2 and #3 status. Did they get merged into Phosphor ever?
diagram-codesprint/jupyterlab #4 and #11 status. Did they ever get merged into JupyterLab?
Other issues
What are people working on?#
Max and Jason
jupyterlab/lumino#132 still needs review.
Thomas
Opened #9399
This is a full review of JupyterLab accessibility, can be broken up into other issues as we go.
Evaluation is on JLab v.2.26 This should catch a lot of what holds over to 3.0, but we will be facing new problems with virtual notebook.
We started discussing how we pull this apart to tackle it
Tabs/tab order are the blockers that prevent further evaluation, so they should be high up on our list
Order top to bottom should work in order of what are most critical and/or rely on one another
This is a great review! Thank you so much!
Isabela
Collecting and triaging existing issues as listed above.
Next Steps#
Max created a project to track JupyterLab accessibility work https://github.com/orgs/jupyterlab/projects/1. This will be how we organize and keep track of work in the future.
Isabela and Tony will compare and consolidate #9399 with pre-existing issues. - Isabela also needs to check for duplicate issues and close/update as needed. - Triage marking by WCAG standard and maybe level of complexity?
Martha #9365 applying isToggleable to JLab now that it is possible in Lumino is still happening. This will be her next step.
Time to reach out to experts and say we want to meet in the future (also gives us a deadline for some of the commitments)
12.16.20 Meeting Minutes#
Attendees#
Tony Fast @tonyfast
Jason Grout @jasongrout
Gonzalo Peña-Castellanos @goanpeca
Martha Cryan @marthacryan
Sam Kacer @SamKacer
Thomas @manfromjupyter
Alex @ajbozarth
Max @telamonian
Isabela @isabela-pf
Notes#
This is the project for tracking accessibility work. We are still figuring out permissions, and this is a work in progress pulling over the past triaging work. When 3.0 is out, we want to convert the cards into a concrete road map.
Recommended resource WAI ARIA authoring practices
Thomas thinks there are a magic few lines of code that would be easy to get in JupyterLab before 3.0 and could make a big difference. Posted (and linked above) at #9491 (formerly team-compass #114).
These discussions have identified four main accessibility needs for JupyterLab (can probably be extended to other Jupyter projects too)
Making JupyterLab accessible for a read-only type experience
This is the focus of the report on #9399
Making JupyterLab accessible for an interacting/coding experience
Adding JupyterLab docs for accessibility features
Sam gave an anecdote about help pages in docs that lists help and resources for screen reader users.
Adding CI or relevant accessibility tests to the JupyterLab contributing workflow ensure accessibility remains a priority - Referenced pydata-sphinx-theme #292
nteract has some kind of accessibility CI they use (probably focused on react)
JupyterLab Code Editor#
Our main focus today is the accessibility of JupyterLab’s code editor as discussed in #4878 and the comments of #9399.
What steps do we want to take?
We will be shipping jupyterlab 3 before the end of the year. Changing the default editor would be difficult before 4.0 because of the number of things that have started to rely on CodeMirror.
Start with an extension based approach. To take action now and eventually fit it in to the release cycle as a part of core.
What editor should we start working with?
Sam confirms codemirror 6 is working better so far, especially better than we have now.
Based on the JupyterLab Monaco Plugin, is it possible/relatively simple thing to bring that up to date and test how it would work with the editor now.
Sam still prefers monaco based on current usage.
Where does this fit on our priority list/who can work on this? One potential path: 1. Get monaco editor extension up to date. 2. Review how that works with screen readers in JLab now. 3. Set up a way to quickly and easily install the extension (link for screen readers at top of JupyterLab?) and immediately use it to test screen reader accessibility in JupyterLab. 4. Prepare the extension to be a part of core JupyterLab for the next release.
Sam’s next priority (after editor) would be the toolbar
Needs to conform to what user expect for menu bar interactions
Examples: alt focuses menu bar, move between top items with arrow keys.
Elements of the menu bar to be marked up with ARIA so it can be communicated via screen reader - This is brought up as a part of #9399
Jupyter Notebook is just a little more accessible than Lab. “Like you get in a car and everything is backwards.”
Agenda items not yet covered#
is this closed? can someone audit it? https://github.com/jupyterlab/jupyterlab/issues/6575
some old audits
Should these minutes be somewhere besides one long issue? Could the jupyter/accessibility repo (or another repo) hold minutes in a way that allows for more organization?
Agenda item from Chris Holdgraf (Did Max mention they had already been discussing this?)
Don’t forget that we have a little bit of funding from Bloomberg to run some kind of event around accessibility. I’m not sure how much flexibility we have with it, but perhaps it is worth discussing if / how this funding could be useful in a future meeting?
how should we handle touch events re accessibility?
PR for manually converting some touch events to mouse events
Next Steps#
Continue moving past triage work to the project for tracking (Isabela)
Follow up on necessary ARIA roles JupyterLab needs (a lumino PR already started labeling) (Martha)
Make issue about menu bar focus (no assignment?)
Update Monaco plugin for 3.0 (Max post-3.0)
3.0 Release! (Jason and Max)
Review Max’s PR (Martha)
Reach out to accessibility experts we’ve met with before (Isabela)
Check the status of #6575 (Isabela)
12.30.20 Meeting Minutes#
Attendees#
Gonzalo @goanpeca
Tony @tonyfast
Thomas @manfromjupyter
Isabela @isabela-pf
Notes#
From JupyterLab Team meeting 12.23.20 discussion
Is single-document mode the more accessible UI? [compared
to JupyterLab default]
Thomas says Classic is better, but since that’s not being updated we need to keep it relevant
Can’t move tabs on a screen reader
Focus on navbar and notebook. Will this help make jupyterlab and classic accessible together?
Having less things on screen could be helpful because it means you can focus on having those things being navigable, but it also can risk hiding functions and making things less usable.
jaws, nvda, focus on low vision ambulatory users because at the moment things are completely inaccessible to blind users and will keep being so until we fix these needs first.
project manager to get different places. need a foundation.
Can’t currently evaluate JLab well because you can’t even navigate it right now. Keyboard accessibility and tab order are key place to start.
Agenda item from Chris Holdgraf: “Don’t forget that we have a little bit of funding from Bloomberg to run some kind of event around accessibility.” - We agreed that we need to follow up on how much money this is to know what we want to do with it. - Parts of the work might be good/more contained project that we can get funding for. Maybe the accessible editor is an option?
What’s the strategy?
Thomas would like to see all #9399 and #9491 in next six months. These issues make JupyterLab navigable/readable so that it can be more finely evaluated and so that you can even reach the editor experience.
Currently can’t create new notebooks, or change kernel with keyboard alone?
6 months: everyone but blind users can use jupyter
12 months: everyone can use JupyterLab
Can we convince people to act by framing some of these things as helping multiple problems (like a better mobile experience)?
Would not recommend splitting the team up because we don’t have a lot of people who have an accessibility background, so it might be best to keep our knowledge together.
Goals for next JupyterLab release? What would we want to prioritize? - We think we can do it without formally being a part of the release schedule. See above for priorities. - Do the work, show it, and it is usually easier to get it incorporated.
Next steps#
Mark which things are we looking to work on first and make sure they are ready to be assigned next meeting (Isabela).
Look into having regular sprints or other group times to work so we can help learn from each other.
Have a happy new year!