Jupyter accessibility meetings 2022#

1.12.22 Meeting Minutes#

Attendees#

  • tony

  • Ely

  • Mike

  • Frederic

  • Gabriel

  • Martha

  • Jason

  • Nick

  • Matthew

  • Chadi

What are people working on?#

  • Isabela

    • Jupyter accessibility workshops are upcoming on January 15, January 22, and two events in March.

    • Find all up-to-date links on the Jupyter blog announcement post

  • Gabriel

    • Mapping out and comparing frontend of JupyterLab and RetroLab

  • Chadi

  • Nick

    • exploring robotframework-axelibrary as a thing to add to JupyterLibrary

      • should be possible to e.g. configure Test Teardown to Collect Accessibility Violations

        • …and when error conditions arise

      • tag with violations which would bubble up to

    • potentially blocked by limited maintainer effort on upstreams

    • also have some data analysis tools for long-term ingest of many robot reports

    • both could be injected into e.g. robotkernel

Some links in chat:

1.26.22 Meeting Minutes#

Attendees#

  • Isabela

  • Frederic

  • Ely

  • Jason

  • Darian

  • Gabriel

  • Nick

  • Patrick

  • Tony

What are people working on?#

  • Tony https://github.com/jupyter/accessibility/issues/67

    • What jupyter/accessibility has been so far: kind of a cross-project team compass

    • This PR discusses ways to make it a more resource-focused and active repo. Also to help people actually start using Jupyter tools (that’s been a popular ask)

  • Patrick

    • Could anyone give an update on how things are currently working, perhaps both high level and in the code?

    • People are interested! We need to follow up and connect these communities

    • Are these communities also willing to giving feedback on how to make better experiences (not just be WCAG compliant) based on how they use these tools?

  • Isabela

  • Gabriel

    • Does the JupyterLab settings UI PR add accessibility features/is that a place they could go in the future?

    • Right now? That’s not the focus. It could be added in the future.

Next steps#

  • Discuss jupyter/accessibility reorganization (open for commenting to everyone!)

  • Follow up on cross-community collaboration (Isabela, Jenn, Tony, Patrick)

  • Remove hardcoded css colors to improve the extensibility of the these (maybe Nick?)

2.09.22 Meeting Minutes#

Attendees#

  • Nick

  • Tony

  • Martha

  • Ely

  • Frederic

  • Thomas

  • Chadi

  • Isabela

What are people working on#

2.23.22 Meeting Minutes#

Attendees#

  • Tony

  • Ely

  • Gabriel

  • Martha

  • Nick

  • Jason

notes#

What are people working on#

  • @tonyfast

    • reusable tasks for building jupyterlab, retrolab, lumino combinations.

    • turning jupyter/accessibility into a js/py packages

3.9.22 Meeting Minutes#

Attendees#

  • Martha

  • Tony

  • Jason W

  • Jenn

  • Isabela

  • Gabriel

Agenda#

3.23.22 Meeting Minutes#

Attendees#

  • Mike

  • Ely

  • Martha

  • Jenn

  • Gabriel

  • Tania

  • Isabela

Agenda#

Jupyter accessibility workshop resources! (First two events are up, but the last ones are pending. They will all link here.) Jupyter accessibility workshops repo

Mike:

  • progressbar aria https://github.com/jupyterlab/jupyterlab/pull/12238

    • An addition based on review on a prior pull request.

    • This is something worth testing! Open invite for people to give it a try.

    • Prompted a discussion around what/how can we test these things going forward. Do we have several accessibility fixes we’d like tested where it’s worth actively reaching out to people?

    • Similar, but separate from discussion around regular user feedback surveys timed with JupyterLab releases.

Tania: Jupyter governance and jupyter/accessibility. A discussion around what’s happening and where the community thinks we belong!

Next steps#

  • TODO: open an issue on jupyter/accessibility and use it as a RFD (request for discussion)/lazy voting and revisit in 2-4 weeks?

  • Isabela to follow up with Mike on asking the community for feedback on existing accessibility fixes.

4.6.22 Meeting Minutes#

Attendees#

  • Frederic

  • Nick

  • Jason

  • Darian

  • Martha

  • Ely

  • Gabriel

  • Mike

  • Preston

  • Tom

  • Rohit

  • Pooja

  • Isabela

What are people working on?#

  • Preston

    • Contributing guide questions https://github.com/jupyter/accessibility/issues/47

    • Should this be specific to the repo (not general jupyter contrib)

    • CI. what’s the status (based on jupyterlab benchmarks repo)

    • things that don’t exist (another issue or what’s happening?)

    • Follow up on issue with some of these specifics.

  • Tom

  • Gabriel

  • Darian

  • Isabela

    • Open question from me, what do you all want me to work on next?

      • From notebook call: nbgrader importance; could use my attention

      • “It just can’t be worse than the existing nbgrader” :laughing:

    • If nothing else, can we go through the JupyterLab accessibility project board?

    • tag people not necessarily accessibility involved if they know what’s up

    • ask it in jupyterlab

Next steps#

  • Follow up on accessibility fixes survey/feedback request (Isabela to Mike)

  • Follow up with Tania about last meeting’s governance discussion (Isabela to Tania)

  • Three options for governance next steps and have people involved come to consensus (Isabela to create and tag people)

4.20.22 Meeting Minutes#

Attendees#

  • Gabriel F.

  • Nick

  • Isabela

What are people working on?#

5.04.22 Meeting Minutes#

Attendees#

  • Martha

  • Isabela

  • Gabriel

What are people working on?#

Next steps#

  • The dream: updated galata documentation.😊

  • Follow up about governance status (Isabela)

6.1.22 Meeting Minutes#

Attendees#

  • Tony

  • Mike

  • Ely

  • Gabriela

  • Isabela

  • Nikhil

What are people working on?#

  • Intros for newcomers!

  • Tony

    • jupyter/accessibility #90 automated accessibility testing efforts

    • Automated testing is known to catch only a percentage of known accessibility problems (usually WCAG, which is the minimum itself). How/are there plans to include disabled user testing?

      • Because of open source we need solutions that aren’t only tied to people (espcially individuals). But we also agree we need this input. It’s been a combo of getting funding (to pay people for their expertise) and some parts of JupyterLab are so inaccessible that we need to fix areas before we can get good feedback.

      • How does this fit with the extension-cookiecutter?

  • Voice navigation in JupyterLab?

    • Where to start? Has there been existing work? Not as far as anyone here knows.

    • Having semantic HTML is probably the start, though, because it would allow other tools to hook into JupyterLab well.

    • Some resources on how this work might need to behave: Browsing with assistive tech - Tetralogical

  • Workshops mentioned in Lab call?

    • There’s no current plan from anyone here to submit for the next Community Workshop proposal cycle.

Next steps#

6.15.22 Meeting Minutes#

Attendees#

  • Tony

  • Gabriel

  • Mike

  • Adam

  • Martha

  • Isabela

What are people working on#

Next steps#

  • Follow up on subproject set up (Isabela)

6.29.22 Meeting Minutes#

Attendees#

  • Gabriel

  • Tony

  • Darian

  • Sylvain

  • Martha

  • Nikhil

  • Mike

  • Tania

What are people working on?#

  • Sylvain

    • Codemirror 6 migration is ready for testing, accessibility perspective and otherwise.

    • Please test it with the binder link in the PR! Feedback is extremely welcome! Please note CM6’s accessibility doesn’t seem to be clearly documented.

    • Known issues we will not be addressing: LaTeX syntax highlighting does not yet exist

  • Isabela

    • JupyterLab accessibility statement approach

    • I’m going to be working on theming soon. What are your dream themes? (ie. ideal accessible themes)

    • :bulb: colour-blind friendly - as many as possible?!, selective contrast, address Irlen syndrome needs, monochrome

  • Gabriel

    • I haven’t been doing much Jupyter-related accessibility work lately, but I have been trying to implement accessibility-related CI/CD for the upcoming new Quansight website (quansight.com and labs.quansight.org), and I have been a bit surprised (but not surprised) that some of this stuff isn’t more plug-and-play.

    • Quansight’s new website is statically generated with Vercel. You might think that there would be some ready drop-in solution to run pa11y-ci or axe-core against the pages in your site, but so far I haven’t found it.

  • Nikhil

  • Mike

Next steps#

  • Collect requests for notebook and visualization standards in JupyterLab to figure out where that info may be best stored (Isabela)

  • Create a list for requested JupyterLab accessible themes with status (Isabela)

  • Update on static website testing set up (Gabriel)

  • Watch the jupyter-lab-voice demo when it’s on YouTube!

7.13.22 Meeting Minutes#

Attendees#

  • Tony - QLabs

  • Balaji - Berkeley

  • Ryan - Berkeley

  • Allison - Berkeley

  • Paul - Berkeley

  • Sean - Berkeley

  • Tania - QLabs

  • Gabriel - QLabs

  • Richard - Berkeley

  • Isabela - QLabs

What are people working on?#

Next steps#

  • Update meeting notes in jupyter/accessibility (Isabela)

  • Bring up statement work with main JupyterLab team (Isabela)

  • Follow up on subproject next steps (Isabela)

    • (+1 Nikhil - would love to learn more!)

8.10.22 Meeting Minutes#

Attendees#

  • Gabriel F. - Quansight Labs

  • Ely - Bloomberg

  • Ryan

  • Martha

  • Balaji - UC Berkeley

  • Mike

  • Richard

  • Isabela

  • Darian

Agenda#

Next steps#

  • Circle back on next steps for our subproject status: start a council (Isabela)

  • from Ryan “should there be a github issue in lab to measure/describe a11y issues with it’s current use of canvas?” Yes! (Isabela)

  • Review DataGrid specifically to understand the work that would be needed to make it more accessible (start with a complicated component)

8.24.22 Meeting Minutes#

Attendees#

  • Darian

  • Tony

  • Gabriel

  • Ryan

  • Martha

  • Isabela

  • Allison

Agenda#

  • Rendered notebook user testing has started! You can track that work-in-progress on the iota-school/notebooks-for-all repo

  • Lumino 2.0 accessibility

    • Relevant links lumino #341 and jupyterlab #12992 and lumino examples and Section 508

    • This is in alpha release at this point.

    • Lumino provides the top level menus, the command palette and search, the keyboard shortcut system, the dock panel (sidebars), and Widgets (a lot like react components but with different life cycle; more like building UI in Qt).

    • Some changes are low-level changes, like making sure that keyboard navigation is not inhibited. Lumino doesn’t have a concept of the content in these widgets, so some changes that are content-specific do not belong there.

    • What’s the status of where we are in evaluating any API-breaking changes or other issues?

      • DataGrids still seems the most potentially suspect. It does impact certain cell outputs, too, so this could be critical.

        • Probably the most sure-fire choice would be to provide an option to turn this off and render as a table.

        • Maybe it’s easier to review on Notebook and then we find those issues and then can evaluate wheter or not they are Lumino.

      • Where do ARIA labels or similar tags align with this work?

  • Gabriel

Next steps#

  • Review Notebook 7 for accessibility as means of identifying Lumino changes and more. (Isabela + anyone interested) (most recent review is)

9.07.22 Meeting Minutes#

Attendees#

  • Darian

  • Ryan

  • Gabriel

  • Martha

  • Isabela

  • Ely

Agenda#

  • How do we want to set up the council? Background: the governance bootstrapping docs don’t account for the fact that we became a software project later and did not have existing steering council members to start our council process. We also need to have a council soon to nominate our representative to the new SSC soon.

    • Some options to create the starter group:

      • Add who has already voted in our most recent votes as the starter group.

      • Add whoever is in the GitHub organization as the starter group.

      • Add meeting attendees over a certain list of recent months as the starter group.

        • Maybe a number of regular attendance? But this shouldn’t be the only thing because there are many valuable asynch contributions.

      • Darian: “has attended x number of times out of y number last meetings OR has voted in https://github.com/jupyter/accessibility/issues/81”

    • More setting up council to dos:

      • Council team compass

      • Github team

      • Mailing list (if wanted)

      • SSC representative

      • two-factor authentication

  • Isabela

    • Reflow and Lumino?

Next steps#

  • Isabela to set up starter group list for the council. Reach out to list of individuals.

  • Isabela to post an issue about how we determine this starter group for transparency.

  • Add PR to jupyter/accessibility when this starter group is formed. Then we can have the discussion about where things go without blocking this process.

9.21.22#

Attendees#

  • Darian

  • Tania

  • Gabriel

  • Ryan

  • Ely

Agenda#

October 5 2022#

Attendees#

  • Jeremy (might not be able to attend)

  • Frederic

  • Mike

  • Gabriel

  • Isabela

  • Allison

  • Darian

  • Frederic

  • Martha

  • Detroit

  • Balaji

  • Ryan

Agenda#

Next steps#

  • Shadow DOM needs more research and/or a binder to test it in

  • Explore Notebook 7. Report Notebook 7 issues.

  • Add “office hours” help for under agenda and make a queue of issues to pull from

October 19 2022#

Attendees#

  • Mike

  • Isabela

  • Gabriel

  • Stephannie

  • Martha

  • GĂŠrard

  • Tania

  • Ryan

  • Balaji

  • Kseniya

  • Israel

Agenda#

  • Isabela

    • Discussion on directions for high browser zoom and JupyterLab at jupyterlab/jupyterlab #10004. Please weigh in!

      • Mike: Another approach would be to have UI and document zoom approached separately since it is possible they are different use cases.

      • Mike: “A datapoint for previous discussion: in VScode the default is to zoom everything and user needs to enable document zooming manually though they divide ctrl + scroll as it seems.”

    • For anyone curious, here is what we did on the collaborative keyboard navigation review for the Notebook 7 prerelease. It will become an issue elsewhere.

  • Gabriel

    • Sneak peek on some of the work I’m doing. tl;dr– Run accessibility regression tests via GitHub Actions against a JupyterLab PR, showing if it breaks (or fixes) any regression tests.

  • Copy this to next meeting’s agenda: For the remainining meeting time, can we open up and dig into CodeMirror? -Gabriel [name=Tania] I am interested in this, mostly how can we “test” for the newly introduced accessibility features

November 2 2022#

Attendees#

  • Darian

  • Gabriel

  • Stephannie

  • Isabela

  • Martha

  • Ely

  • Ryan

  • Mike

  • Kseniya

  • Balaji

  • Tania

Agenda#

  • Isabela

    • Update on Space Telescope user testing results. This resources PR provides all info used to plan the tests so far and script, notebook used, and takeaways from the first round of tests.

  • Mike

    • nbdime? Keep an eye out for any PRs here because this could relate to the inaccessibility of the space. We should review any PRs with this in mind.

  • Darian

    • Rick mentioned someone from UC Berkeley might contact us re: accessibility for Jupyter tools deployed there

    • Jupyter Executive Council election

  • For the remainining meeting time, can we open up and dig into CodeMirror? -Gabriel [name=Tania] I am interested in this, mostly how can we “test” for the newly introduced accessibility features

November 16 2022#

Attendees#

  • Darian

  • Gabriel

  • Stephannie

  • Isabela

  • Tania

  • Mark

  • Detroit

  • Ryan

  • tf

  • Sylvain

  • Ely

Agenda#

  • Special guest appearance: Katie [name=Tania]- Since Darian mentioned an audit (potential) it would be definitely good to keep in sync and find a way to standardise our auditing processes in Jupyter-world

  • Isabela

    • Update on Space Telescope user testing results. We have more complete takeaways from the first round of tests. If there’s any interest in me sharing the results or answering questions, let me know!

    • For desired reflow in JupyterLab, please feel free to weigh in on jupyterlab/jupyterlab #10004. I’m trying to keep this moving forward and would like if we can get to a decided direction.

    • Regarding reflow Darian/Sylvain does any of you have ideas/suggestions on moving this forward and help land on a decision/path forward

      • [name=Gabriel] In response to this question, there was discussion and questions around Notebook 7 vs JupyterLab

  • Sylvain

    • Notebook v7 audit by Balaji at UC Berkeley

November 30 2022#

Attendees#

  • Mark

  • Martha

  • Gabriel

  • JooYoung

  • Tony

  • Stephannie

  • Mike

  • Tania

Agenda#

  • Gabriel

    • Discuss: “Jupyter Accessibility”:

      1. Group exercise: open your favorite search engine, type “Jupyter Accessibility”… where does it take you? what is the first thing you see?

      2. Are we happy with this?

      3. If not, what do we need to do? [name=Tania] - we need docs like https://code.visualstudio.com/docs/editor/accessibility for Lab and friends [name=Mike] - Collect a list of extensions and themes for accessibility features see https://jupyter-accessibility.readthedocs.io/en/latest/#using-jupyter-software-with-assistive-technology Comments included that we don’t have user-focused documentation to point to. Even if they live on a per project basis, it makes sense to also have them here.

    • Some take-aways:

      1. Keep jupyter/accessibility as one repo. Don’t split into two repos (one for user-facing docs, one for team compass)

      2. Put sign posts for end users in jupyter/accessibility repo and website.

      3. Try to add accessibility docs to jupyter.org and/or JupyterLab ReadTheDocs

      4. Push forward the work done on the Accessibility statement, with an eye to providing useful info for disabled users.

      5. Think about restructuring current docs so that they address different users: contributors, end users, maintainers, and such.

      6. Repos that use the keyword accessibility but are incomplete or works in progress sohuld probably have some kind of WIP label and preamble.

    • Links:

  • Isabela

December 14 2022#

Attendees#

  • Min

  • Darian

  • Ryan

  • tonyfast

  • Blessing Ogoh

  • Gabriel

  • Isabela

Agenda#

  • Isabela

    • Calendar check. Is this our last meeting of the year?

      • [name=Gabriel] FYI, the JupyterLab team meeting on Dec 28 that precedes this one was cancelled.

    • Want to fix the broken link to our old meeting notes? Help with jupyter/accessibility #113 is welcome!

    • I want to review and (if needed) update the accessibility project board soon. Is anyone interested in giving this a review as well? We can split issues up to save time.

  • Gabriel

    • In the meeting before this one, Florence from QuantStack demo’d a JupyterLab extension to edit the look and feel of JupyterLab.

    • [name=Ryan] Sounds like it could lead to accessible themes or maybe more accessible defaults

    • [name=Gabriel] Yes! but for me the key thing that interests me here in terms of accessibility for end users is empowering end users to customize the UI to their particular accessibility needs (high contrast, color blindness, large font, etc.)

  • Min

    • Connecting Blessing, Outreachy intern working on accessibility in JupyterHub

    • Authentication, Spawning, Admin pages

    • Wave exposing existing color/contrast issues

      • How to make intentional design decisions

  • Darian

  • tony

    • Progress on navigating static notebooks after a recent round of tests.