Skip to content
This repository has been archived by the owner on Feb 16, 2023. It is now read-only.

Run an accessibility audit on this UI #80

Closed
choldgraf opened this issue Jan 19, 2021 · 12 comments
Closed

Run an accessibility audit on this UI #80

choldgraf opened this issue Jan 19, 2021 · 12 comments

Comments

@choldgraf
Copy link

We've had a lot of trouble over the years in building accessible interfaces. Jupyterlab itself is not very accessible and will require a ton of work to get there because of its complexity.

I wonder if this UI is an opportunity to make more near-term progress on accessibility since it is much more streamlined. Perhaps we could run an audit on "classic with lab" and see what needs to be done?

@jtpio
Copy link
Member

jtpio commented Jan 20, 2021

Since JupyterLab Classic reuses most upstream lab and Lumino components as-is, it looks like it might be simpler to work on the upstream components, and then update classic to the new versions?

In a way, JupyterLab Classic should benefit from all the accessibility work without too much effort.

That said, there could of course be an accessibility audit done on JupyterLab Classic too, just to double check how it compares to JupyterLab. Would be interesting to see the outcome!

@choldgraf
Copy link
Author

choldgraf commented Jan 20, 2021

For sure - I'd hope that making the "JupyterLab-Classic" UI more a11y-friendly would just mean making upstream improvements in JupyterLab components. I'm just saying that if we prioritized the components that this distribution of JupyterLab uses, we might get to at ~100% a11y-friendly notebook UI faster.

@willingc
Copy link

@choldgraf Do you have a sense if it is more colors or reading of tags are more the issue with the accessibility?

@choldgraf
Copy link
Author

No I'm not sure, we were planning to map all of this out last year in the a11y planning meeting, and then COVID happened :-/ but I think there is momentum building behind this again (due in no small part to @isabela-pf's leadership here) and I'm hopeful we can make progress!

@isabela-pf
Copy link
Contributor

Hi all! I've been summoned by the magical @ and now I'll give you my best guess of where JupyterLab Classic is based on what we've been working on with JuptyerLab. Keep in mind I'm not an expert on this at all.

The biggest problems we've been facing with JupyterLab right now is that it is so inaccessible we can't even get a full review yet because it basically can't be navigated. Sometimes, you can't even get into open notebooks from my understanding. This is down to the foundational Lumino level in many cases. So like what @jtpio said, many of the changes we are making now should help with Classic as well. The reason I bring this is up is that even though I agree it would be helpful to audit JupyterLab Classic, I think it's likely it has the same base problem as we are having in JupyterLab and an audit won't be able to provide helpful direction yet. It could still be good to check, but it also might make sense to check once some if not all the WCAG standards (especially labels, tab order, and keyboard controls three of our biggest blockers for more in depth review) have been met since I can't imagine those not influencing Classic.

Since I think it will affect both interfaces, if people want to work work on making JupyterLab Classic more accessible it might make sense to collaborate and unite energy towards the shared parts first so that we can get a better audit to provide specific accessibility needs for Classic sooner rather than later.

@willingc
Copy link

@isabela-pf Thanks for sharing your experience :D Are you aware of any tools that could be run on a regular basis (perhaps even CI) to report on accessibility compliance? It would be great to have a baseline so that future decisions in UI take into accessibility. It would also be interesting to track progress over time. Also, IIRC, open edx has a library of react components that are accessible.

@isabela-pf
Copy link
Contributor

This is a priority we've discussed a few times without making significant progress on yet. But I think we would be basically wasting all effort to start this work and not make it a part of the regular development process (I'm still figuring out the design side).

I'm looking into tools (mostly on CI because I think that's the best way to get this team running tests regularly) and will need feedback from people with knowledge of the code base that I don't have to verify what might work best for JupyterLab components. But I'm happy to share some of the resources I've been looking at so far!

The most extensive resource I've found for various test is from the W3C. This is the overview and this is a list of specific tools. Be aware not all these tools seem totally free, and some have been deprecated. It's still one of the better collections I've found.

From the above link, I've noted the following for a further check:

@willingc
Copy link

@isabela-pf Great resources. The best resource that I have seen are the ones that were curated by 18F. Some friends worked at 18F and made resources for the US government agencies' use. https://accessibility.18f.gov/

@trallard
Copy link

Hoping in here!

Based on @jtpio answer above ( re classic reusing JLab components) I would suggest looking into the JLab audit first and carry over to Jlab classic.

Re automated CI I would be glad to help with a PR (maybe joint with @isabela-pf) I have used pally and accesslint.js within other CI workflows before. This way we could start with the baseline

@jtpio
Copy link
Member

jtpio commented Apr 27, 2022

hey folks,

Is there any more action to take here? Should further discussions be happening in the https://github.com/jupyter/accessibility repo?

RetroLab development has now moved to https://github.com/jupyter/notebook. So we can continue to work there instead and close this issue?

@bollwyvl
Copy link
Contributor

As designed, the idea would be:

  • in the repos.toml
    • get the right git refs for notebook, jupyterlab and lumino repos
  • in the dodo.py
    • determine the docs build requirements
    • determine the set of yarn link steps that need to occur to get access to the lab/lumino
    • start some basic actions that exercise the pages

However, it looks like all the audit bits are actually shut off over there, and potentially conflicting PRs were landed, so I can't comment on how it would work today...

@jtpio
Copy link
Member

jtpio commented Oct 3, 2022

FYI a new pre-release for Notebook 7 is out: https://github.com/jupyter/notebook/releases/tag/v7.0.0a6

It includes the update to CodeMirror 6 so if folks would like to try it that would be great!

Closing this issue since the RetroLab repo is going to be archived soon. Happy to continue discussing this in https://github.com/jupyter/notebook or https://github.com/jupyter/accessibility.

@jtpio jtpio closed this as completed Oct 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants