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 👍