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:)

  • https://design.chicago.gov/accessibility/tools/

  • 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?#

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.

What are people working on?#

Isabela

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

  • Max

  • Isabela

    • PR for JupyterLab color contrast updates at #9335. This means it has a binder to test. Original issue is #8832

    • Started sorting through the web of repos where accessibility work was started as issues (based on Phosphor Walkthrough meeting notes). Nothing to show yet.

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

    • #6573 NVDA tests on JLab. (Not explicitly tied to Hack4All, but seems like it was part of it.)

    • #4878 Older screen reader evaluation with good discussion. Has been mentioned in a few issues and PRs so it would probably be good to brush up on.

What are people working on?#

  • Max and Jason

  • 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#

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!