-
-
Notifications
You must be signed in to change notification settings - Fork 46
Run an accessibility audit on this UI #80
Comments
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! |
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. |
@choldgraf Do you have a sense if it is more colors or reading of tags are more the issue with the accessibility? |
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! |
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. |
@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. |
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: |
@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/ |
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 |
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? |
As designed, the idea would be:
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... |
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. |
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?
The text was updated successfully, but these errors were encountered: