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 https://github.com/jupyter/accessibility/issues/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… :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?

• Max

  • accesible slider Widget
  • PR: https://github.com/jupyterlab/jupyterlab/pull/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 https://github.com/jupyterlab/jupyterlab/issues/8832

Next steps

• Do we want to share these notes somewhere (team-compass)?
• Martha and Max working on UI components (LabButton?)
  • Alek might help too!
• Spend an hour introducing everyone to JupyterLab UI so we understand what we are working with and start identifying places to work with it. (Do this later when people have done some exploration first)
• Removing UI components based on blueprint
• Reach out to Chris Holgraf, Tania Allard, and Jason Grout about contacts we've made in this area already (tony)
• Find and share resources (everyone)
• Settings UI (Alex). Will start after JupyterCon. Needs accessibility reveiw for the design.
• Meet every other week (twice a month).

[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: https://github.com/jupyter/accessibility/issues/14
• Keyboard accessibility.
• Closing accessibility issues that already exist. There's already been work pointing out some of the issues (like here https://github.com/jupyterlab/jupyterlab/issues?q=is%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

• https://github.com/phosphorjs/phosphor/pull/404
• https://github.com/phosphorjs/phosphor/pull/405
• https://github.com/phosphorjs/phosphor/pull/406
• https://github.com/jupyter/accessibility/issues/11
• https://inclusive-components.design
• https://github.com/jupyterlab/lumino/issues/81
• https://github.com/phosphorjs/phosphor/pull/406
• https://github.com/jupyterlab/jupyterlab/issues/911#issuecomment-562304755
• https://github.com/jupyter/accessibility
• https://github.com/phosphorjs/phosphor/pull/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 #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 #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
  • 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? https://github.com/jupyterlab/jupyterlab/issues/6575
  • https://github.com/jupyterlab/jupyterlab/pull/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
  • https://github.com/jupyterlab/lumino/pull/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.

[manfromjupyter]

Regarding one of the discussions brought up today, wanted to catalog the different groups or issue topics that users may be concerned about that may not know accessibility or are not paid to work exclusively on accessibility that we could get buy in from to work on accessibility fixes and still have their orgs, companies, etc support it/fund them doing so. May not be a complete list, just a handful I could think of and briefly saw when looking at the project chart.

Accessibility Work and other issues it could fix:

• All Low vision work – also helps make the product mobile-responsive (and vis a versa)
• The following are would help with SEO (Search engine optimization) both in ranking and visibility if a user or company is using their jupyter in a way where they make it open to organic traffic on the web.
  • Alt text on images
  • Adding content regions (landmarks)
  • Using appropriately formatted tables
  • Rendering without a single horizontal scroll bar on mobile and having the viewport metadata (which for the latter JupyterLab may already have, but just mentioning it).
  • Marking links as external if they external.
  • The proposed table fixes
  • (Maybe) Placeholder labels on fields
  • Search fields needs role=”search”. On a google snippet or other browser snippet would allow you to search on the site within the google result.
• The following are also general UX fixes that would benefit everyone as they enable a better and easier user journey.
  • Contrast issue fixes
  • The proposed table fixes
  • Verify errors provide suggestions on fixing the error
  • Adding/auditing keyboard shortcuts are general Visual indication and programmatic exposition of keyboard focus helps UX as well letting users know that an element is clickable and will have some kind of action.
  • Placeholder labels on fields
  • Consistent keybinding ticket (all buttons and action when focused will trigger on both a Enter and Spacebar press). Although most users don’t do this, it does affect everyone.
  • Make modals accessible by keeping focus contained within the modal (done simply by adding a role="modal" attribute). This is to prevent user from doing tasks and other actions outside of the modal resulting in the page changing without their real knowledge but the modal still remaining up.
  • Increasing UI font size button does not increase all UI font size.
  • Make links visually distinct from text so users know which is which.
  • Make visual cue in command palette is given when a command is run
• Better support for themes and extensions both in the product and in the browser.
  • Adjustable text spacing sub-ticket.

Changes solely affecting Accessibility

As per the accessibility only buy-in work needed, have included information of what requires a screenreader or not - as this also came up in the meeting today. All issues above do not require a screenreader, but for contrast fixes for example, or labeling below (instead of a screenreader), user might find it easier to develop and test with the Tota11y toolbar (https://khan.github.io/tota11y/) instead because it's stupid easy and will expose labels of contrast ratio, header number, and aria label directly on the screen. Hopefully this will decrease the analysis paralysis and barrier to entry for developers to begin working on these issues and get their feet wet if they're new to accessibility before jumping into the screenreader issues, or else we can/should encourage them to jump straight to these.

Does NOT require Screenreader to Develop/Test

• Focus moves in a logical order/site can be rendered without a stylesheet (may dabble into SEO and UX but not enough to really get buy in from those potential groups).
• Adding a skip link (first tab for users with and without screenreads open lowers submenu that lets you jump to subsections (or just notebook)).

Screenreader Required to Develop/Test

• Proposed Notebook Editor fixes
• Adding aria-labels to elements
• Adding aria-expandable and aria-haspopup on dropdowns and expandable menus
• User feedback is provided when content changes or an error/success message appear.
• Provided feedback on a long wait time so user does not try quitting or restarting their computer (Extra credit)

[isabela-pf]

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!

[isabela-pf]

01.13.21 Meeting Minutes

Attendees

Max @telamonian Thomas @manfromjupyter Martha @marthacryan Jason @jasongrout Tony @tonyfast Isabela @isabela-pf Darian @afshin
Alex @ajbozarth

Happy new year!

Hooray for JupyterLab 3.0! Congrats and kudos who everyone who worked hard on it.

What are people working on?

Go around the meeting area and ask.

• Martha

  • #149 - Realized I needed to add more to lumino and not jupyter lab for the toggleable stuff
  • Tota11y toolbar (recommended by Thomas) is a potential tool for testing this.
  • https://khan.github.io/tota11y/
  • How does a labeling something as a checkbox with ARIA roles differ from using a true HTML checkbox? Using HTML as intended usually works better, and screen readers will comment which one it is.

• Tony

  • Needs help with setting up linked lumino JLab set up to test the work around roles that need to be assigned in lumino.
  • Everytime you make a change in lumino, rebuild lumino before JLab.
  • Going through #9491
  • Interest in creating a binder that also reflects changes in Lumino to help each other testing all these things.
  • Other times to pair program on this?

• Max

  • how to work on both lumino and JLab at once: https://github.com/jupyterlab/jupyterlab/blob/master/docs/source/developer/contributing.rst#testing-changes-to-external-packages
  • in progress lumino PR for ARIA roles for tabs: https://github.com/jupyterlab/lumino/pull/132
  • Martha may review?

• Thomas

  • Willing to provide support.
  • Posted https://github.com/jupyterlab/team-compass/issues/98#issuecomment-752748519 (thank you!)
  • If someone wants something to do that won’t step on other people’s toes, lot of elements need either to be hidden or revealed. Card: https://github.com/orgs/jupyterlab/projects/1#card-50646346 as part of #9399. I included a bunch of screenshots if you wanted to started working through it or section by section? https://imgur.com/a/6HvOcYK

• Isabela

  • WIP color contrast at #8832 and related PR #9335. Will help address sections of #911 and #9399 (since both note color contrast concerns).

• Jason: not actively working on something here specifically, but still available for questions and discussion

• Alex and Darian: not actively working on something here, but want to keep track and stay part of the discussion.

What we need to work on

We need to take stock of what's being worked on and split up the work we know we need to do.

• Here is the project for tracking accessibility (should have all issues and PRs we know of)(can be reorganized if we have different needs for sorting).
• First priorities include:
• #9491 This will make it possible to evaluate JupyterLab with a screenreader so we can both be aware of more problems and actually check that fixes are working.
• #9399 (broken up into steps on the project, click on card to make issue when we are ready to work on it). WCAG 2.1 specifications.
• Editor? Is #4878 a first priority right now?
• Right to left (RTL) language support?
  • We will likely be working in areas where these changes need to be made for labeling reasons, so we may want to see if we can include this support at the same time. Especially now that we have RTL language transalations for JLab to test it with (Gonzalo knows more). More info in issues #3046 and #1163.

Other Notes

• Feedback on accessibility event funding.
  • Update: Probably shouldn't rely on it. It's status isn't certain with the pandemic.

[choldgraf]

Hey all - another thought that may be worth considering. I opened up this issue in @jtpio's jupyterlab-classic repo: https://github.com/jtpio/jupyterlab-classic/issues/80

the gist is: I wonder if getting jupyterlab-classic to be more a11y-friendly would be an easier path than getting JupyterLab to be fully ally-friendly. Perhaps we should start off with making improvements to jupyterlab-classic (which will probably benefit JupyterLab more generally anyway) to make some quick progress.

[manfromjupyter]

@choldgraf, if there are changes that can be received to improve both, I'm in favor. As per making it the precedent for making it fully compliant, I think is counter productive.

I am not a key contributor or in any of the inner groups, but it's my understanding that Jupyter Classic is deprecated and in a mere maintenance state until it can be decommissioned (JupyterLab would then become the new home page on initial load). Given that JupyterLab is the future and we can guarantee we'd get approval to make said changes unlike classic for the fixes that wouldn't affect both, I feel we shouldn't touch classic (unless changes affect both). The only other exception would be if its deprecation status was premature and for example they're not decommissioning for another 10 years. Elsewise it just seems like an uphill battle for something that may soon go away anyway.

It is true that Classic is more accessible (almost already supporting low vision users entirely, and header/settings more accessible to screenreaders the one times I look) and I agree in that it would require less work, but because it's deprecated, I and I imagine others can't get any sign off to work or even test something that's just going to go away some day soon. We need mobile and tablet support on JupyterLab, that'll make it fully accessibly for low vision users. Rest are just general UX fixes that JupyterLab needs anyway. What remains it is even less than what would take Jupyter Classic to be fully WCAG 2.0 or 2.1 compliant.

[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 notifications@github.com 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 https://github.com/jupyterlab/team-compass/issues/98#issuecomment-763752573, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGXUD2G53UHFEYKYVYGTTS237I5ANCNFSM4R7J3OPQ .

-- Brian E. Granger

Principal Technical Program Manager, AWS AI Platform (brgrange@amazon.com) 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 https://github.com/jupyterlab/jupyterlab/issues/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 :upside_down_face:
• 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! :tada:
• Max merged lumino #150! :confetti_ball:
• Isabela merged jupyterlab #9335! :sunflower:

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 #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 https://github.com/jupyterlab/jupyterlab/issues/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 (https://github.com/jupyterlab/jupyterlab/issues/9686).
• [ ] Alt Text/Labels and making decorative elements for screenreaders (https://github.com/jupyterlab/jupyterlab/issues/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. (https://github.com/jupyterlab/jupyterlab/issues/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 (https://github.com/jupyterlab/jupyterlab/issues/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 (https://github.com/jupyterlab/jupyterlab/issues/10004)
• [ ] Full Colorblindness Support - only CSS needed (https://github.com/jupyterlab/jupyterlab/issues/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) https://github.com/jupyterlab/jupyterlab/issues/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:

  • https://github.com/jpmorganchase/regular-table/issues/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 https://github.com/jupyterlab/jupyterlab/pull/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! :tada: 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 https://github.com/jupyterlab/jupyterlab/issues/9686 i am having a hard time understanding what happens to the focus on the sidebar.
    • look at https://github.com/jupyterlab/jupyterlab/pull/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). https://github.com/jupyterlab/jupyterlab/issues/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: https://github.com/jupyterlab/team-compass/issues/98#issuecomment-768800666

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.