Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessibility of Jupyter #1801

Open
crwilcox opened this Issue Sep 30, 2016 · 16 comments

Comments

@crwilcox
Copy link
Contributor

crwilcox commented Sep 30, 2016

I have been looking into Accessibility concerns with Jupyter and it seems that there was some work done at some point to address accessibility concerns. I did find some Aria tags for instance. My guess is this was done a bit back or it was never validated that enough was done.

The current state isn't great on the accessibility front. I had the opportunity to work with an individual who browses through a screen reader and their experience with Jupyter was sub par. It was incredibly difficult to know what cell they were in, what type the cell was, where they were in the cell, etc.

Has Jupyter ever attempted to meet either Section 508 or WCAG 2.0? From what I understand these things are important to government and educational spaces so I was curious if there are plans to address these sort of issues?

Resources

Product Version

FYI, I am using Jupyter Version 4.2.3

@Carreau

This comment has been minimized.

Copy link
Contributor

Carreau commented Sep 30, 2016

Hi @crwilcox

Thanks a lot for this issue, I'm going to link to another related issue. jupyterlab/jupyterlab#911
Yes we tried our best to improve accessibility, but for lack of people that told us what they had difficulty with we didn't went far. And it's true that we don't have much experience with it either.

The structure of the current notebook is not that great to do any improvements (as we were not javascript/web developers). But we are now working on JupyterLab, which is a complete rewrite of the notebook (using Typescript). We hope to try to bake accessibility directly in it.

We are doing user studies every now and then, if we could find a way to get users with accessibility issues to give early feedback that would be great.

Note that we also had a look at adding voice control to the notebook (as an extension) in order to help users with reduced mobility. Unfortunately the voice recognition API that were accessible were not that great at understanding my strong french accent, but that's something which can be revisited.

cc @ellisonbg and @jasongrout from JupyterLab. @willingc and @JamiesHQ as well.

@willingc

This comment has been minimized.

Copy link
Member

willingc commented Sep 30, 2016

Hi @crwilcox,

Thanks for your interest in accessibility. Four years ago, I had the opportunity to have dinner with a woman and her guidedog. She demonstrated for me how you could set up and configure an iPhone without the need to see the screen or have assistance by another person. This demo had a huge impact to see what is possible with accessibility and its importance.

Here are some resources that I keep handy when working on Jupyter's documentation. We are currently looking at updating our documentation themes (cc @gnestor @SylvainCorlay ), and I am sensitive to providing the best user experience with the resources that we have.

Resources
https://pages.18f.gov/accessibility/
http://a11yproject.com

Tools
One tool that I find helpful for a quick look at accessibility of a page is: http://squizlabs.github.io/HTML_CodeSniffer/

The other resources provide a great list of available tools.

cc @ivanov @fperez @minrk

@crwilcox

This comment has been minimized.

Copy link
Contributor Author

crwilcox commented Oct 3, 2016

Terrific. Thanks for getting back to me. We currently use Jupyter Notebook and quite possibly will be transitioning to Juptyer Lab when it goes 1.0. It sounds like, and correct me if I am wrong, but Jupyter Notebook is likely to get little in the way of improvements. Your linked issue does indicate to me that Jupyter Lab is getting some real improvements though.

@JamiesHQ JamiesHQ self-assigned this Oct 24, 2016

@JamiesHQ

This comment has been minimized.

Copy link
Member

JamiesHQ commented Oct 24, 2016

Also - @willingc @gnestor @SylvainCorlay : we also have a newish Berkeley accessibility policy that we're working toward incorporating into the documentation design: https://webaccess.berkeley.edu/

@gnestor

This comment has been minimized.

Copy link
Contributor

gnestor commented Oct 24, 2016

@JamiesHQ @willingc Does it make sense to open an issue elsewhere to tackle docs accessibility across Project Jupyter?

@gnestor

This comment has been minimized.

Copy link
Contributor

gnestor commented Oct 24, 2016

@crwilcox Regarding accessibility on the jupyterlab front, a label has been created to track those efforts: https://github.com/jupyterlab/jupyterlab/issues?q=is%3Aissue+is%3Aopen+accessibility+label%3Acat%3AAccessibility

@gnestor gnestor added this to the jupyterlab milestone Oct 24, 2016

@willingc

This comment has been minimized.

Copy link
Member

willingc commented Oct 24, 2016

@gnestor Grant, I think it does make sense to open a docs accessibility issue wherever work on the improved RTD theme will live. Perhaps for now open in jupyter/jupyter. Thanks!

@JamiesHQ

This comment has been minimized.

Copy link
Member

JamiesHQ commented Nov 4, 2016

Thanks @willingc & @gnestor - probably worth discussing at the project meeting next week.

@willingc

This comment has been minimized.

Copy link
Member

willingc commented Nov 4, 2016

Copying in @cameronoelsen since he'll be doing some of the work on the new theme's design. cc @ellisonbg

@JamiesHQ JamiesHQ added this to ToDo in Accessibility Apr 24, 2017

@Neurrone

This comment has been minimized.

Copy link

Neurrone commented Jul 15, 2017

Any updates on this issue?

I'm a screen reader user and was taking a quick look at notebook's accessibility in preparation for a machine learning course at university that starts next month.

Using jupytar 1.0 and notebook 5.0, this is what I've found so far following a basic tutorial:

  • When creating a new jupytar notebook, there is no semantic indication in the markup that the name (untitled) is clickable
  • The toolbar (inside the id="maintoolbar-container" element) have labels that are only visible when hovered over by the mouse since it uses the title attribute. This can be fixed by adding an aria-label="..." attribute containing the same information.
  • In the blank code cell that is created by default, I can't reliably find the <textarea> to enter code. Am not sure if this is caused by the way the DOM's constructed there, or CSS. Even if I manage to land inside the <textarea>, I don't hear anything when arrowing about, which is definitely not normal. This is the most critical bug.
  • As a convenience feature, it would be really nice if the output of a code cell gets automatically read when I press shift+enter to run it. This can be done by adding the role="log" attribute to the <div class="output_subarea output_text ....
@Neurrone

This comment has been minimized.

Copy link

Neurrone commented Jul 16, 2017

This is going to be much harder than I thought. The codemirror library is causing the editor problems.

@rgbkrk

This comment has been minimized.

Copy link
Member

rgbkrk commented Jul 16, 2017

There's another version of codemirror that tries to address accessibility via screen readers - http://bgrins.github.io/codemirror-accessible/ I know that Google's internal version of the notebook has modifications to support screen readers better.

In order to have it done, someone would need to sponsor CodeMirror (see codemirror/CodeMirror#4604) as it would be a large undertaking to switch to contentEditable. Otherwise, perhaps Monaco editor + JupyterLab is a smart choice, especially since @crwilcox reported the issue. ;)

@Neurrone

This comment has been minimized.

Copy link

Neurrone commented Jul 17, 2017

@rgbkrk Just tried Jupyter Lab, and its even harder to use. E.g, can't select a notebook to open from the keyboard, and the code editors exhibit similar problems. You mentioned Monaco editor + Jupyter Lab, does that mean that there's some way of changing the default editor being used, or does it already use Monaco editor already?

I can try replacing the default codemirror version with the more accessible fork, but I suspect it wont work unless I use an older notebook version, since it was done 4 years ago.

By google's fork, do you mean Data Lab?

@rgbkrk

This comment has been minimized.

Copy link
Member

rgbkrk commented Jul 17, 2017

No I mean the internal colab notebook at Google.

@sccolbert

This comment has been minimized.

Copy link
Contributor

sccolbert commented Jul 17, 2017

@Neurrone We are still using CodeMirror by default, but the editor component can be replaced. The RBrain folks have swapped it out with Monaco, but we can't do that by default because it currently only supports requirejs. https://r-brain.io/en/

Thanks for the feedback on the filebrowser. Please do open issues on the jupyterlab repo when you discover things that are difficult/impossible to use: https://github.com/jupyterlab/jupyterlab/issues

@ellisonbg

This comment has been minimized.

Copy link
Contributor

ellisonbg commented Jul 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.