Create a source of truth for accessibility in JupyterHub

[choldgraf]

Problem Statement

A few user stories to consider:

• As a learner or researcher who requires assistive devices to do my data science work, I need interfaces that have been designed for these devices to interact with. (one could imagine a similar story for the many other ways in which people need perceptual assistance working in data science)
• As an administrator at an organization, I have a mandate to use technology that meets minimal criteria for accessibility for the user communities I must serve. I need a simple way to answer "is this technology accessible?"

Currently, there is no single place that is discoverable and explains all of the information somebody needs to understand the current state of accessibility in JupyterHub, and where to go for more information. This means people waste time digging into jupyterhub docs, go down rabbit holes because they have the wrong mental models for what jupyterhub does and doesn't do, and might choose not to use (or not to use) JupyterHub because of incorrect assumptions based on accessibility.

This is becoming a bigger problem as a11y is increasingly mandated by policy at public institutions (e.g. teaching institutions). There are also some formal practices for defining accessibility that might make this easier at a policy level.

Proposed Solution

Add a single "landing page" for JupyterHub to define it's high-level "accessibility story". Here are a few thoughts:

• Something that just speaks to whether our user interfaces (hub login etc) meet various definitions of accessibility. This would be a helpful resource for us to point to elsewhere, as users are increasingly interested in knowing they are using accessible tools.
• Explanation of what is in / out of scope for JupyterHub interfaces (e.g. we can't control the a11y of the interfaces you serve with JupyterHub, like JupyterLab or VSCode, but we can control a11y of hub's interfaces like the login screen)
• Ideally, a link to a VPAT for JupyterHub (ref: Provide guidance to subprojects for how to prepare VPAT for their technology jupyter/accessibility#155) but doesn't need to block this
  tudio / VSCode / MATLAB / Positron.
• Links to the other accessibility spaces in Jupyter to learn more, ref: Create an accessibility landing / routing page at jupyter.org/accessibility jupyter/accessibility#154

Proposed Implementation

I'd imagined any of the following places, and with minimal information and/or links to learn more deeply (e.g., a link to an accessibility github issue tag etc):

• A page tied to jupyterhub the app (e.g. jupyterhub.readthedocs.io/en/latest/accessibility
• A page tied to the jupyterhub project as a whole (e.g., hub.jupyter.org/accessibility
• A page on jupyter.org (e.g. jupyter.org/hub/accessibility)

Links to ongoing work to check and improve this

• Add accessibility testing to JupyterHub testing tools jupyterhub#4078

How will this fit in the ecosystem?

No response

Endorsements

[minrk]

If we decide to populate a 'project' landing side (hub.jupyter.org), I agree this would belong there. Since we haven't really done that yet, we could either:

1. use this as an opportunity to do that!
2. put it in jupyterhub docs for now as the logical central location. the jupyterhub package does contain almost all of the JuptyerHub UI (except for fancy profiles, pretty much, which 2i2c owns, not jupyterhub)

I'd love help on VPAT / accessibility testing. @bl-aire made a number of excellent accessibility improvements to JupyterHub pages, but we don't have accessibility testing to help us not backslide.

JupyterLab really is the biggest project that matters, since students hardly see JupyterHub UI. But that also means we should be able to easily meet high standards!

[minrk]

btw, I just learned about https://github.com/pamelafox/axe-playwright-python which was presented two years ago at https://northbaypython.org a truly excellent local event I was at just 3 days ago!

[bl-aire]

Hello @minrk @choldgraf,

With your guidance, I would like to work on this.
I can start by researching the current state of accessibility in JupyterHub and putting together a draft page along with some proposed next steps. The draft could include outlining what JupyterHub covers, what’s out of scope, and identifying gaps (like testing or VPAT). From there, I can open a PR or share a proposal for feedback.

Let me know if that sounds like a good approach.

[choldgraf]

IMO we definitely don't need anything too complex, because I agree with @minrk 's take here:

JupyterLab really is the biggest project that matters, since students hardly see JupyterHub UI. But that also means we should be able to easily meet high standards!

But I think there's still a lot of value in "saying this" as the JupyterHub project so that others can discover it and don't need to figure it out for themselves. We should also clarify that for any interface, JupyterHub doesn't have the ability to control a11y for it (e.g. if somebody runs VSCode on JupyterHub, a11y in VSCode isn't in hub's control. This is a pretty common point of confusion)

@bl-aire I would personally find that really helpful!

[minrk]

@bl-aire that would be great! Let me know if you need any support.

[bl-aire]

I will get to work then!
Thank you @minrk @choldgraf

[bl-aire]

Hello @minrk,

While setting up a development install of JupyterHub, I ran into a blocker that seemed related to event schema validation.

When I ran:
JupyterHub -f testing/jupyterhub_config.py

I got the following error:
jsonschema.exceptions.ValidationError: “1” is not of type “integer”

From the traceback, this appears to originate in the event logging setup via jupyter_events, where the schema defines "version": "1" (string) but the validator expects an integer.

I was able to work around it locally by changing version: “1” to version: 1 in event-schemas/v1.yaml but I wanted to confirm:

1. Is this a known issue with the dev branch?
2. Would you prefer a PR to update the schema ("version": 1) or that can come later?

[minrk]

Make sure to upgrade jupyter-events, the validator should expect a string. This changed in jupyter-events 0.11:

pip install --upgrade jupyter-events

[bl-aire]

Make sure to upgrade jupyter-events, the validator should expect a string. This changed in jupyter-events 0.11:

pip install --upgrade jupyter-events

Okay, I will.
Thanks

[bl-aire]

Hello @minrk,

I’ve created and shared an initial draft and added you as an editor on the Google document.

I’d appreciate any feedback or suggestions you may have.