Accessibility Meetings Minutes

[isabela-pf]

We've decided to meet and discuss plans for a coordinated effort to make JupyterLab more accessible. This issue records meeting minutes for easy and public tracking.

These are open meetings, but since we don't have a schedule yet there is not public link to join. If you want to get involved with these meetings, let me know!

Previous meetings

• 3-10-21
• 2-24-21
• 2-10-21
• 1-27-21
• 1-13-21
• 12-30-20
• 12-16-20
• 12-02-20
• 11-18-20
• 11-04-20
• 10-26-20
• 10-21-20
• 9-30-20

[choldgraf]

Just a note that you may wanna ping the folks over in jupyter/accessibility#11 as they are all very keen on improving a11y across the Jupyter ecosystem

[isabela-pf]

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… 👀)
• 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?

• Max

  • accesible slider Widget
    • PR: followup #9100: made sdm switch pretty, accessible jupyterlab#9104
    • probably a one-off, not really reusable in current form
  • LabButton
    • fully accesible replacement for current blueprint-based Button in @jupyterlab/ui-components
    • working on PR, hopefully have an initial stab done by the meeting
    • based on
      • https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role
      • https://www.w3.org/TR/wai-aria-practices-1.1/examples/button/button.html
      • https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Accessibility_concerns
    • tricky part: the button text

      • the reccommendation: always use an HTML button element, always label like text

      • for icon buttons (eg all of our toolbar buttons), the suggestion is to hide the text using CSS

      • example 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 components
  • bigger 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 Update UI with accessible color contrast jupyterlab#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).

[choldgraf]

also pinging @manfromjupyter who mentioned they might be interested in joining in on accessibility conversations!

[telamonian]

At @choldgraf's suggestion, I'm pinging all of the participants from jupyter/accessibility#11, ie the folks who would have been jupyter a11y workshop attendees, had the workshop happened:

@sinabahram
@zorkow
@ellisonbg
@clapierre
@trallard
@jasongrout

As we try to renew the push on making jlab accessible, your involvement in the working group would be most welcome. We've got plenty of enthusiasm and jlab know-how, but we are critically short of actual a11y expertise. Any input would be greatly appreciated.

In addition to the meetings, the working group has also been chatting a lot on gitter: https://gitter.im/jupytercalpoly/accessibility. The gitter channel is where we've actually been arranging the meeting times and rooms.

[lresende]

@marthacryan

[clapierre]

tricky part: the button text
the reccommendation: always use an HTML button element, always label like text
for icon buttons (eg all of our toolbar buttons), the suggestion is to hide the text using CSS

That doesn't seem right. I would think that the using aria-label would be the ideal solution here. Not sure why you would need to hide the text of an icon button off-screen that seems ludicrous to me. @sinabahram don't you agree?

[sinabahram]

A few things.

First, putting text inside the button could be thought of as preferred over using ARIA, and yes, the appropriate way to do that is with an sr-only class on the inner text. This follows the principle often quoted as "The first rule of ARIA is not to use ARIA", and you obviously do not "need" ARIA to label a button.

Having said the above, I'm unaware right now of any lack of support of aria-label amongst the popular screen reader/browser combinations, so this is a trivial issue, and please feel free to use aria-label to label the buttons.

Next, this touches on the point I was trying to make earlier. I think attacking low hanging fruit like unlabeled buttons is wonderful. It will have real impact for sure, but it is a small fraction of a fraction of what is required to actually make significant progress towards an accessible experience. To that end, I suggest that you need a strategy for these various patterns, be it unlabeled controls, grouping techniques, container semantics, heading semantics, traversal patterns with alt+shift+f6 and alt+f6 (you can't use f6 alone because that will conflict with browser's native f6 implementation), image descriptions, when to have automatic announcements, and so forth.

None of the above tackles the trickier issues around content editable, mode toggling, and code-related features, all of which need their own conversations of course.

Moving beyond the above tactical issues into matters more strategic around accessibility, there need to be several conversations around how these semantics are conveyed and reasoned about within the system. It's been a while since I've been in the code, but I remember a dedicated UI library happening via Phosphor or something like that, along with certain assumptions about functionality and accessibility mappings therein being made at various places up/down the stack. Some of these decisions will need to be revisited with an eye towards accessibility because the approaches/patterns I reference above, once agreed upon, can then be templatized in a way that doesn't require doing a ton of work every single time we want to create a button, add it to a toolbar, etc. Same goes for menu options and much more.

I hope this helps a bit, and I'm happy to find time to hop on a synchronous call to discuss further.

[manfromjupyter]

Going to second what @sinabahram said. It is the best practice to inject hidden text to the elements over aria-ing if you can.

• For screenreaders, not all handle it the same way and some read it instead of the element, some read it after, and some don't read it at all (if I recall correctly from my usage of it).
• For non-screenreaders users that still have accessibility needs, having hidden text is still very important. One example coming to mind is low vision users and users with color blindness, if the contrast is too much or too busy for them, some have tools or will attempt to render pages without the stylesheet to pull up a text-only version of the site. If a button is an image or it's an icon, it will not appear because it's merely a: "" (not even a space character) even with aria-labels. If there is sr-only text in there though, it will suddenly be readable with maximum contrast (black text on white background or the opposite if they configured their computer, browser, or site themes to do). In my experience, I have only ever used aria-labels for non-decorative images to fully describe what it happening or external links that require explanation so users know they will be leaving the site, what it's for, and what to expect.

[isabela-pf]

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: Which screen reader(s) should we focus on for initial development of JupyterLab accessibility? jupyter/accessibility#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%3Aissue+is%3Aopen+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%3Aopen+is%3Aissue+label%3Atag%3AAccessibility
  • Jupyter Notebook accessibility issue label https://github.com/jupyter/notebook/labels/tag%3AAccessibility
  • 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.

[isabela-pf]

Following up on some of the next steps from the 10.21.20 meeting minutes, here's what's next in terms of meetings.

On Monday (Oct 26) 1:00pm Pacific @jasongrout will guide us through some of the accessibility work started at the root of JupyterLab in Phosphor. Meeting on Zoom.

We also agreed on a time to schedule these recurring meetings so that we can post a link publicly. For now, we will meet every other Wednesday at 10:15am Pacific (right after the JupyterLab weekly team meeting ends). That means the next meeting is November 4 at 10:15am Pacific. Meeting on Zoom.

[choldgraf]

thanks for posting these notes online! If we decide to make a push on getting funding to hire developers for accessibility work, this is something I am happy to help with 👍

[isabela-pf]

These notes are from a supplementary meeting to the regular and more general JupyterLab accessibility meetings we've been holding. It was lead by @jasongrout.

Walkthrough Phosphor Accessibility PRs Meeting Notes (10.26.2020)

Attendees

Jason Grout @jasongrout
Martha @marthacryan
Alex @ajbozarth
Karla @karlaspuldaro
Alek @biniona
Gonzalo @goanpeca
Isabela @isabela-pf

Context

This is related to the Web4All Hackathon on Jupyter from 2019 at the LightHouse SF.

Accessibility standards tend to be written based on HTML forms or similar standard web use cases. Sometimes it's difficult to figure out how that impacts JupyterLab since we use lots of things in ways that weren't intended in the design of such standards.

Some people worked on the "low-hanging fruit" in JupyterLab (like dialogs) and some people started working on Phosphor since it makes architectural decisions that interfere accessibility higher up.

• Menus and tabs are the main focuses of the Phosphor work

  • Menus use virtual DOM
  • Menus have been relatively straightforward
  • Tabs have caused some more difficulty

• In menus right now, any menu items can be "checked," but you don't have any indication of which menu items can be checked or not, it is inferred from the context. Whether or not something can have these different states is not accessible information.

  • This is probably the least controversial change because:
    • It's backwards compatible
    • Makes sensible defaults
    • Small PR
    • Incremental PR
  • This might be a good place to start merging.
  • Should these be the goals we reach for (when relevant) to be able to make progress in this area?
    Trying to understand ARIA standards. If/when we talk to experts, asking them which tutorials/docs to use (to avoid deprecated ones) is a good question.

• There seem to be a few main types of work needed:

  • Additive accessibility work. For example, add ARIA attribute and any needed infrastructure to make it possible or consistent to call whatever is needed.
  • Reworking existing structure. This tends to be harder and create more difficult to resolve discussions.
  • Figuring out what has not been found as an issue yet. Exploring other problems.

WIP Repos

Where a lot of this work lives. Closed issues were pulled upstream. Open issues hold discussions and work that still needs to be done.

• https://github.com/diagram-codesprint/Web4AllHackathon2019
• https://github.com/diagram-codesprint/jupyterlab
• https://github.com/diagram-codesprint/phosphor

Relevant PRs and Issues

• Add isToggleable command state phosphorjs/phosphor#404
• Add ARIA types to VDOM and add ARIA roles to menus phosphorjs/phosphor#405
• Add ARIA roles to tabs phosphorjs/phosphor#406
• Jupyter Community Workshop on accessibility jupyter/accessibility#11
• https://inclusive-components.design
• Accessibility Enhancements lumino#81
• Add ARIA roles to tabs phosphorjs/phosphor#406
• Accessibility audit jupyterlab#911 (comment)
• https://github.com/jupyter/accessibility
• Steps to adding accessibility to Phosphor phosphorjs/phosphor#392

Miscellaneous Notes

• Lumino needs to be really stable, so will probably need to collect changes for a big release to make changes there.
• Things to check:
  • Does this follow Sina's outline of what we need to do?
  • Is this still what we need to do? Has ARIA or other standards progressed where we need to reasses?
• When the DOM can reflect what is currently visible on the screen, that tends to be a good thing.
  • If your DOM had an iframe, it used to break enough that it made people ask "Maybe we shouldn't be messing with the DOM all the time?"" So it was rewrittem the way this works as a flat structure. This is terrible for accessibility since there is no longer clear indication of what is controlling what.
  • Semantic versus physical DOM. We're using a semantic DOM to address this flat DOM issue.
• Other discussions about tables. DOM as table? Notebooks as tables? This would make it easier for screen readers to jump around the structure. We don't know where this discussion is right now.

Next steps?

• Split existing PRs between people so that we can make progress on problems we already know we have
  • Get these to be merged or at a state where they could be merged and get review from experts/other relevant community buy-in
• Get up to speed enough that discussions with experts will not waste their time
• Show energy, commitment, and active development on our side so that we can gain momentum.
• Collect the lists of issues that have already been found so we know what we can d
• Do some reading on relevant standards (ARIA) so we have the knoweledge to have meaningful conversations
• Move Phosphor PRs over to Lumino
• Walk through Phosphor https://www.youtube.com/watch?v=GCp4lxOblxg&list=PLFx5GKe0BTjQyCKtiK9TI-ekSuSn_8a3J&index=1

• Is there a way that we can set up a binder image with one of these PRs so that it can be easier to help community and/or accessibility experts jump in more easily?
• Move all issues we find into the jupyer/accessibility repo so that we have an easier list to revisit as we work. https://github.com/jupyter/accessibility/

[isabela-pf]

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

[isabela-pf]

These meetings will now be on the main Jupyter (jovyan) Zoom channel and are on the JupyterLab Community Calendar! Up to date info will be on the calendar.

I will continue posting meeting minutes here, and will note if that is to change. Thanks for everyone's continued interest and work. 🌻

[telamonian]

It looks like we now have all 3 of the old phosphor a11y PRs redone as lumino PRs:

jupyterlab/lumino#129
jupyterlab/lumino#131
jupyterlab/lumino#132

The first two have already been merged, jupyterlab/lumino#132 still needs review/merging. Way to go @marthacryan

[isabela-pf]

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

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

[choldgraf]

This is really exciting to see all of this progress - thank you @isabela-pf for posting these notes, I really appreciate it as somebody who is dealing with a 3 month old and thus cannot make these meetings!

Excited to see what an audit comes up with in JupyterLab :-)

Two quick points:

1. 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?
2. I see that the plan is to consolidate a11y issues in either Lumino or JupyterLab. I think that's reasonable given that the major improvements to make are there - though just want to note that there are other places in Jupyter that could use a11y improvements too! (e.g. JupyterHub / Binder, Jupyter Book, etc)

[manfromjupyter]

@tony, per your comment in the meeting about what tools were used, here is exactly what I used to do everything.

For Contrast, Heading structure/ordering, and Landmark usage, I use https://khan.github.io/tota11y/. Simply add the link at the very button of it (detailed in directions) to your browser bookmarks and it creates a pure JS overlay that tests all of those things and very well. No extensions needed. Using the tota11y tool:

Or if you don't trust extensions of foreign JS you can do it manually to each element in question with the Chrome Inspect element which for the last ~8-10 versions has done this. It's pretty cool and works most of the time.

For Screenreading, I tried NVDA this time but disliked it. Just having to push a key at the same time I am also tabbing, arrow keying, jumping to different headers or tables, etc just was annoying and didn't seem to even work half of the time (very possible I just don't know the software fully). Have and will continue to use the JAWS application. It is unfortunately no longer free (as of June 2020), but for people that don't own it, each time you restart your computer you can use it for free for 40 minutes.

For the paragraph, character, font-size, and line-height spacing test, I just manually input the CSS as there are so many different extensions that could be added that it just seems more consistent to do it manually. Just add the following CSS styles to your inspect element for the site you're testing on. No extensions needed.

* {
    line-height: 1.5 !important;
    letter-spacing: 0.12em !important;
    word-spacing: 0.16em !important;
}
p {
    margin-bottom: 2em !important;
}

For the Rendering without a Stylesheet test/tab ordering flow is logical test, as tedious as it is, I just manually delete all of the <stylesheet> style elements in the <head> section of the HTML. That's how I got it to look the screenshot below. There is probably a better way to do it but that's just what I've been doing. In my defense the web best practice is to use a single stylesheet for all styling, not 50+ that JLab currently uses (just the out of the box product, no JLAB extensions). Anyway no special tools or browser extensions needed to test this.

For Testing Low Vision just magnify your browser to 400% zoom for AA (WCAG version 2.0) support or 500% for AAA (WCAG version 2.1) support for these users (if I remember correctly). For the mobile/tablet tasks I either do the same or open the inspect element > device toolbar emulator. No extensions needed.

And that's it. No extensions needed for anything, just some JS code bookmarked, your screenreader app, and some in-app manipulations you do to the styling. :)

[jasongrout]

In my defense the web best practice is to use a single stylesheet for all styling, not 50+ that JLab currently uses (just the out of the box product, no JLAB extensions)

FYI, the design of JupyterLab is ~50-100 discrete "extensions" that all work together, and each have their own stylesheet to load.

[manfromjupyter]

Hahahaha, touché. Makes sense.

[isabela-pf]

Responding to @choldgraf. I'm glad the meeting notes are helpful! Thanks for your continued feedback on them.

1. 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?

Thanks for the reminder! I put it on the agenda to bring up in the next meeting since I'm not sure how we might be interested in using it.

2. I see that the plan is to consolidate a11y issues in either Lumino or JupyterLab. I think that's reasonable given that the major improvements to make are there - though just want to note that there are other places in Jupyter that could use a11y improvements too! (e.g. JupyterHub / Binder, Jupyter Book, etc)

You are absolutely right that there are other places that I'm sure could also use accessibility improvements. Right now we made the choice to limit our scope in order to make goals that are reasonable for the number of people we have working on it, the time each can devote to this work, and the fact that we all have been working on JupyterLab lately. I agree though that the ideal case would be to continue building a community around this to work on the whole ecosystem.

[isabela-pf]

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.

  • #6577
  • #6578
  • #6579
  • #6580
  • #6581
  • #6582
  • #9365 Follow up for jupyterlab/lumino Transfer jupyterlab-dynext to the JupyterLab org #129 that applies isToggleable to JLab now that it is possible with Lumino (Martha started this!)

• Issues Isabela wants to look into more

  • JLab #6575 (update of diagram-codesprint/jupyterlab JupyterLab Pull Requests Extension #8) Has merged PR #6359, but didn’t close the issue.
  • JLab #6576 (update of diagram-codesprint/jupyterlab Move the roadmap here #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
  • 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)

[manfromjupyter]

Regarding the last-minute push we talked about that we could rush into JupyterLab 3.0, here is where I filed it (https://github.com/jupyterlab/team-compass/issues/114) . Looks like it's 24 lines of code instead of 8 hahaaha, so apologies for that. Didn't expect some other things that needing addressing. Each of the sections within these landmarks need improving, sure, but provides 85% of the aria landmarks needed and upon deciding on a solution for the header part for screenreader users to parse through them, will make it accessible to them. So users may not be able to parse through the header or sidebar with this alone, but they can get to the container and see if any combination of tabs, arrows, or "screereader start reading here" will let them parse through it. If it's too much of a lift before the release, no worries, just wanted to throw it out there.

P.S. Apologies in advance for screenreader users for the ticket. Included quite a bit of text in images and color-coded them to make them easier to understand because of the rushed situation. If you would like clarity on specifics of the proposed changes just let me know.

[choldgraf]

@manfromjupyter that "low hanging fruit" diagnosis is awesome, thanks for that :-)

[isabela-pf]

Thanks for everyone's patience with me posting this week's notes. We had a really active discussion so the notes needed some organization to make them better match the meeting (and easier to read later).

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 and https://github.com/pandas-dev/pydata-sphinx-theme/runs/1507397117?check_suite_focus=true
  • 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? Make the terminal accessible jupyterlab#6575
  • Turn on accessibility in xterm.js jupyterlab#6359
• some old audits
  • https://docs.google.com/document/d/1oSHOqmtua_3vdoJddvo4u3na71cIZlpEgP73w-0uXFU/edit#heading=h.umcyl9debp28
  • https://docs.google.com/spreadsheets/d/1RWEtBtXEF5vQf_vJzqtGWnPbT0VZI_RZ_H7RWHmgyGs/edit#gid=0
• 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?)

1. 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
    • Basic Touch Events lumino#123

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)

[SamKacer]

I just wanted to add a small note. Just so that it is explicitly noted, the WAI-ARIA Authoring Practises are directly useful for the points on the screen reader accessibility of the menu bar.

The Menu bar section:

• lists the expected keyboard interaction
• relevant aria attributes to apply
• reference implementation

Further, the section on keyboard navigation inside components describes how to manage the focus inside a composite component such as the menu bar. This is critical for screen reader users, as without it the screen reader can't let the user know where they are located in the menu bar! This section describes two ways to achieve this. Either one works well. I would expect the aria-activedescendant method might be easier though in the jupyter instance.

[goanpeca]

@manfromjupyter JupyterLab Classic is a new project https://github.com/jtpio/jupyterlab-classic, basically provide the classic notebook experience but using all the JupyterLab components.

Jupyter Notebook Classic != JupyterLAB Classic :)

[choldgraf]

Yes! Sorry for not making that clearer - the point of jupyterlab-classic is to use jupyterlab components to re-build the notebook interface. I think that all a11y improvements for jupyterlab-classic would happen in the form of upstream improvements to JupyterLab components. I'm just saying that it might be worth prioritizing the jupyterlab-classic components first, as it might be a shorter path to having a notebook interface that is more a11y-friendly.

[manfromjupyter]

@choldgraf Oh I misread, forgive me

[ellisonbg]

Because of the scale of JupyterLab's usage, I believe we should focus on work that helps JupyterLab itself to become more accessible. Obviously, jupyterlab-classic will benefit from that, which is also a good thing.

…

On Wed, Jan 20, 2021 at 8:21 AM Man from Jupyter ***@***.***> wrote: @choldgraf <https://github.com/choldgraf> Oh I misread, forgive me — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUD2G53UHFEYKYVYGTTS237I5ANCNFSM4R7J3OPQ> .

-- Brian E. Granger Principal Technical Program Manager, AWS AI Platform ([email protected]) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[choldgraf]

Again my point is not to work on jupyterlab-classic instead of JupyterLab, my point is that there are likely many things to do in JupyterLab itself to make it more a11y-friendly, and we'll need to prioritize which things to work on. I'd recommend prioritizing the things that are also used in jupyterlab-classic if it means that there is a shorter pathway to getting an a11y-friendly interface.

Basically I'm suggesting that jupyterlab-classic could be a quick win on the way to making JupyterLab in general more a11y-friendly.

The reason I say this is because particularly in the educational space, many many people will prefer a streamlined notebook interface (they're still using the "old" classic notebook interface), and having an interface that:

• Looks like the Jupyter Notebook interface
• Uses JupyterLab components and can use lab extensions
• Is a11y-friendly

Would greatly increase the likelihood that they would switch.

[tonyfast]

The trouble with focusing on jupyterlab classic specific changes is that we only have audits and specifications for jupyterlab itself. If there were an audit and specifications for improving classic specific, i think we could move on this idea. without an audit like jupyterlab/jupyterlab#9399 it is hard to know what takes action.

[manfromjupyter]

Maybe somebody else can review jupyterlab-classic for that (if we get there and/or like the idea) but because it is not part of the out-of-the-box experience of jupyterlab I personally am just not authorized to work on it/test it, so I can't be the one to do it.

[choldgraf]

I'll let y'all discuss whether to take this approach or not, I'm just a fan of quick wins and iterative progress wherever possible :-)

[jtpio]

I'd recommend prioritizing the things that are also used in jupyterlab-classic if it means that there is a shorter pathway to getting an a11y-friendly interface.

I think what this means is focusing on components such as the notebook, file browser and terminal first, since they are also used in JupyterLab Classic.

Instead of the code consoles, status bar and other components in upstream JupyterLab only.

[SamKacer]

if jupyter lab classic consists of a strict subset of components from jupyter lab, then it makes sense to prioritize components in such a order that jupyter lab only components are prioritized after the ones in classic, since then we would get to some fully accessible version of jupyter lab the most efficiently.

in either case, I think the next priority component, at least for screen reader accessibility is the menu bar, code editor and file browser.

[isabela-pf]

01.27.21 Meeting Minutes

Attendees

(oops! No one signed in today so I gave my best guess.)
Max @telamonian
Thomas @manfromjupyter
Martha @marthacryan
Jason @jasongrout
Tony @tonyfast
Alex @ajbozarth
Karla @karlasupldaro
Isabela @isabela-pf

What are people working on?

• How is everyone doing?
  • Come up with different intro questions 🙃
• Does it make sense to have these meeting notes documented outside an issue? I think there's enough content there that it's hard to navigate if you aren't just looking for the first or last comment.
  • Yes! Let's propose a place in the Jupyter accessibility repo.
• Can we make an issue about adding accessibility tests to the JupyterLab development process?
  • I was reminded by the discussion started on JupyterLab Classic #80.
  • I've also listed some existing tests. We should review these to see if they could work or give us a baseline for working with lumino or jupyterlab components.
    • squizlabs / HTML_CodeSniffer
    • IBM's accessibility-checker
    • AccessLint / accesslint.js
    • pa11y / pa11y
    • dequelabs / axe-core
• Should we also make an issue reminding us to make accessibility docs as we make all the WCAG and other changes?
• Check in! In the JLab team meeting, we have accessibility listed as an issue people are working on within the JLab 4.0 timeline. What scope do we want to report? Are we working on #9339 and #9491 only right now, or is someone planning to work on the editor?
  • #9339 and #9491 for sure. Editor changes are still being researched so mark it as possible but uncertain.
• Max started working on #9491
  • Probably JupyterLab and not lumino level fixes.
• Martha
  • #9622 blocked by small translation issue
  • Needs review or advice how to proceed.
  • Otherwise ready to merge (Thomas tested it!)
  • #149 Merged!
• Tony
  • #9648
  • With Max's PR, this should cover #9491!
  • Tony's PR should cover all landmarks.
  • Only thing left is making it so screen readers can access those different labels.
  • How does this interact with JLab themes? We need to test what this PR means visually.

Other Notes

• Spatial experience and vision
  • Thomas says you are generally not supposed to label things that will be accessed via screen reader with left, right, here, so on because it doesn't really mean anything to those users.
  • In CSS classes or other areas not accessed by a screen reader, this is okay.
• Tab index convention
  • Seems like the main recommendation is to set everything to tabindex 0 (because it defaults to the browser).
  • Does this work for JupyterLab?
  • -1 means you aren't going to see it. For example a is a tab and buttons are tabbed, so there is possibility for things being tabbed twice. So sometimes -1 is to avoid redundancy.
  • Tabs are only for people to jump to those regions. They do not define the region or header/hierarchy. But tab puts you in those places to then announce the region or header.

Merged PRs (let's celebrate!)

• Martha merged lumino #149! 🎉
• Max merged lumino #150! 🎊
• Isabela merged jupyterlab #9335! 🌻

Next steps

• Isabela
  • Propose moving accessibility meeting notes to the accessibility repo so they are easier to search.
  • Follow up on test/CI ideas
  • Update accessibility project with merged PRs
  • Start issue for adding accessibility page to docs
  • Add resources to contributing guidelines encouraging people to read up on accessibility.
• Thomas
  • Will note the next five steps they recommend focusing on and make relevant issues.
• Martha
  • Work on #9622
• Max
  • Review Martha's Package location of document models #149 PR
  • Work on PR for #9491
• Tony
  • Continue on #9648 reviewing visual impact and with a JupyterLab-style class name.

[manfromjupyter]

Thank you/great work again Martha and Tony for getting us to that finish line for landmarks. Super awesome!

Given the discussion earlier about some different sections that are top priority that can/should be worked on that will enable other efforts that all can be worked, here's a list I was able to add a lot of detail too and should hopefully be easy. Can all be done at the same time without affecting each other next that aren’t already being looked at:

• Enable header nav dropdowns to be accessed via screenreader (Final section of Quick easy landmark fixes plus 1 that's not jupyterlab#9491).
  a. Side note for this: I know I said I wouldn’t make paragraphs, sorry, I have a problem. Anyway, you will find that the text element move upward one element may not be enough or won’t fix it. Because it’s an li/div and not an element that responds to “enters” or “spaces” on a keyboard it may just be the way this was coded. Think we need to go to where the click code is for said element to add functionality to enable both a space and enter key presses to open these because it might purely respond to “on click”. In addition, if we could add a tabindex=”0” on the element that we end up putting the text on, that would satisfy another requirement (and would make it so you can test it easily without needed a screenreader).
• Make Sidebars completely accessible (Make Side Bars completely accessible jupyterlab#9686).
• Alt Text/Labels and making decorative elements for screenreaders (Alt Text and Marking Elements Decorative jupyterlab#9682) – being worked on by @isabela-pf but can/should be split up or perhaps pair programmed with because there’s a lot there (it is technically 3 subsections/tickets in one, but all related). Justignore the 5-6 sidebar labels of the hundred fixes detailed in the screenshots in the picture because that will be fixed in the previously listed bullet point above (issue 9686)
• Add Skip Links and Add landmark for the left and right (primary/secondary) stack panels. Sorry, thought we got all the landmarks in the earlier tickets but realize these are important too. I explain more and why these are related in the ticket. (Add Skip Link to All Regions and Add Region Aria-Role to Panels jupyterlab#9688). If @marthacryan isn't don't yet with landmarks, could add it to #9622 but honestly it could easily be done in this ticket instead so no biggie either way.
• Move header region and the dropdowns to the place in the DOM listed on the ticket. Satisfies entire requirement as far as I can tell on having content in a logical and intuitive order (Place region of elements in a logical reading order jupyterlab#9696). This also fixes the issue why users before the regions couldn't tab to get to the header (because every other panel was placed before it in the DOM except the footer).
• Full Low Vision (Mobile/Tablet Responsiveness) Support - only CSS needed for 90-100% of it (Full Low Vision Support (400% zoom) (Mobile/Tablet-Responsive Support) jupyterlab#10004)
• Full Colorblindness Support - only CSS needed (Full Colorblindness Support jupyterlab#10008)

One that is less important because it's a WCAG 2.1 requirement not WCAG 2.0 requirement but could be done at any time for non-typescript people that just just know CSS:

• Adjustable Text Spacing (low priority as only a WCAG 2.1 requirement, not a WCAG 2.0 one) Adjustable Text Spacing (low priority) jupyterlab#9684

[SamKacer]

@manfromjupyter I am not completely sure, but I think officially HTML elements are only supposed to receive keyboard events if they have a tabindex. So, elements without one that have a onclick handler, might not reliably respond to spacebar or enter from a screen reader. Unfortunately, I don't have any time to contribute, but just wanted to say it might be worth adding a tabindex to these clickable elements and see if that resolves the issue.

[manfromjupyter]

@SamKacer I think users just can't get focus on those nontraditional actionable elements to begin with, but you can gain focus technically anywhere (with JS or on any element you can get to with a screenreader). You may very well be right though and definitely worth doing first to see if it works on it's own. Either way, we need to add the tabindex="0" on there anyway to complete another requirement (and did include that in the info under point number 1).

I just wanted to bring up that the lift is slightly higher than anticipated because even when making that change in my tests it doesn't expand the dropdowns. The script may need manipulation. But yeah, definitely start with a tabindex="0" to see if that makes it work.

[isabela-pf]

02.10.21 Meeting minutes

Attendees

• Max @telamonian
• Tony @tonyfast
• Alex @ajbozarth
• Martha @marthacryan
• Jason @jasongrout
• Isabela @isabela-pf
• Nick @bollwyvl
• Thomas @manfromjupyter

What are people working on?

• Keyboard shortcuts and default keyboard navigation with assistive devices. This Came up with this PR JLab #9031 but it seems like it could be a bigger discussion for understanding how these things interact now and in the future.

  • Thanks to Thomas for replying here!

• Max has been working on a new filebrowser. Trying to bake accessibility in on a low level. Issue with notes:

  • Make the regular-table element accessible by default finos/regular-table#114
  • Using the WAI ARIA spec for grid and table properties. These not only need regular labels, but also descriptions for how they are nested and a flag for the position.
  • Max would like feedback/for someone to test it with a screenreader.
  • This is a really helpful exploration that should help us with other tables used in JupyterLab. Further references with a treegrid example are here.

• Question on Max's lumino PR conflicts with Add aria roles and labels jupyterlab#9622

  • Martha reviewed it and is clarifying what labels they are using across PRs so that they are consistent.

• Martha's PR at #9622 is ready for final review and to be merged after one more commit to match labels across PRs.

• Nick

  • For testing: pa11y -s, --standard the accessibility standard to use: Section508 (U.S. focused), WCAG2A, WCAG2AA (default), WCAG2AAA – only used by htmlcs runner
  • numfocus GSoC team would be a solid team for working on accessibility docs

Other Notes

• Isabela opened
  • #9742 because I've had some people asking me about accessibility tests elsewhere and I wanted a place to collect the discussion as it relates to JLab.
  • an issue on the accessibility repo about best practices for accessibility docs
• As a last check, remember to ask yourself if things need to be translated.
  • ARIA values usually need it
  • Table headers might need to be translated? This is worth further research.
  • Data in a table does not need to be.
• Funding discussion
  • Possible Canadian grant: https://accessible.canada.ca/advancing-accessibility-standards-research/funding
  • NSF, NIH, DoE (both of them) NSF future of work https://www.nsf.gov/pubs/2021/nsf21548/nsf21548.htm
  • Does documentation seem like a good project to get outside help on?
• Accessibility workshop updates! There isn't something we can share now, but people are working on it and there should be updates in the next few weeks.

Merged PRs (let's celebrate!)

• Tony merged #9648! 🎉 Thanks to Thomas, Martha, and Max for reviewing it! Congrats, all!

[Zsailer]

Updated the top comment with links to each individual meeting's notes. I find this useful when trying to jump down to previous notes. Feel free to remove if you don't want it :)

[fcollonval]

Not sure it is the best place. But here is a talk by CodeMirror author on accessibility with CodeMirror 6 (FOSDEM 2021): http://bofh.nikhef.nl/events/FOSDEM/2021/D.javascript/codemirror.webm

[isabela-pf]

02.24.21 Meeting Minutes

Attendees

• Jason Grout @jasongrout
• Saul Shanabrook @saulshanabrook
• Tony @tonyfast
• Isabela @isabela-pf
• Alex @ajbozarth
• Max @telamonian
• Martha @marthacryan
• Adam @adpatter
• Thomas @manfromjupyter
• And more!

What are people working on?

• Isabela
  • Should I mention people for feedback on the meeting minutes PR? It isn't urgent, but I don't know who would be good to ask.
• Tony
  • codemirror 6 talk about accessebility: http://bofh.nikhef.nl/events/FOSDEM/2021/D.javascript/codemirror.webm
  • tabindex was not that hard, but the rest is hard.
  • working on Make Side Bars completely accessible jupyterlab#9686 i am having a hard time understanding what happens to the focus on the sidebar.
    • look at Add aria roles and labels jupyterlab#9622
  • it is an li with div's inside, replacing with anchors doesnt ever seem to find focus
  • linking setup example https://jupyterlab.readthedocs.io/en/latest/developer/contributing.html#testing-changes-to-external-packages
  • • Probably should add a very concrete example of linking the Lumino packages to develop Lumino and test against JupyterLab
• Saul
  • Learning to code through working on JupyterLab accessability? Good first issues?
    • currently organized issues https://github.com/orgs/jupyterlab/projects/1
    • Thomas's issues are a good (Thanks Thomas!)
    • This is the issue that covers what we need to do to be able to meet WCAG 2.1 standards. We are breaking it up into other issues to work on bit by bit as well (scroll to the bottom of the issue). Accessibility Issues Needing Addressing for WCAG 2.1 compliance (As of Version 2.2.6) jupyterlab#9399
• Max
  • possible scipy 2021 talk
    • talk notes: https://github.com/telamonian/tree-finder/tree/scipy-2021-talk-proposal/docs/scipy_2021
    • collaborators welcome
• Thomas
  • How can we support the work for tablists at #9622
  • Martha replies that that it needs to be rebased from Max's lumino PR and then it will be ready.
  • For the typescript gods, next priority imo for accessibility are the list items from this comment: Accessibility Meetings Minutes #98 (comment)

Other notes

• Follow up on accessibility workshop status?
  • Having a meeting later today
• lumino + jlab dev notes: https://jupyterlab.readthedocs.io/en/latest/developer/contributing.html#testing-changes-to-external-packages

  • Saul was working on a binder here that links all lumino packages to juptyerlab: https://github.com/saulshanabrook/binder-jupyterlab-dev/blob/master/binder/postBuild
• setup an intermediate meeting for learning about accessibility and contributing to jupyterlab.

Next Steps

• Set up binder to show lumino changes instanly for development testing. (Tony, Martha, maybe Max)
• Get merge rights for accessibility repo (Isabela)
• Gather a set of resources/guides to help start up our newcomers.(Isabela)
• Add specific example to lumino development docs that shows how to link it up to JupyterLab (?)
• Rebase #9622 to have it ready for review (Martha)
• Next week meeting to get people up to speed on accessibility efforts (Isabela, Tony, Saul)
• Review #9399 so you get context for what we are doing and we have a good place to start talking (Anyone trying to catch up on our current work)

[isabela-pf]

In case anyone missed it, meeting minutes will be moving to jupyter/accessibility for (hopefully) easier to navigate and more centralized knowledge. I won't close this issue right away, but I don't think an issue like this is the best choice for long term note storage.

[isabela-pf]

As promised, this week's (March 10) meeting minutes are in jupyter/accessibility. You can find them in this PR.

I will post an update here for the next meeting in two weeks and then close this issue. Thanks so much for everyone's support! Please keep following progress and join the discussion on the accessibility repo!

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/how-do-i-get-started-contributing-to-jupyter/8551/1

[isabela-pf]

Accessibility meeting minutes have been in jupyter/accessibility for a little while now, so I'm closing this issue. Hope to have you all join in over on their new home!