Hello, I’m a student at NYU’s Center for Data Science, working with @VickySteeves this summer on an accessibility audit for Jupyter Notebooks. I was trained by NYU IT’s Accessibility Office to be able to do a full audit. I’ve gone through Jupyter Notebook version 6.0.0, using notebooks from the Data 8 course materials as examples, and VoiceOver on Mac for screen reader testing. Below I’ve included some critical accessibility issues as starting points, along with a Google Doc for more details. I also have a spreadsheet of the complete audit I performed, showing the pages I tested, which areas did not pass WCAG 2.0. Each bolded point under the “Test Procedure” column links to the corresponding section on WCAG 2.0 for reference. I also referenced WAI-ARIA Authoring Practices for examples on design patterns.
Accessible name missing for folder/file icons
Status changes are not announced for assistive technologies
Graphs generated by code need alternative way to convey information
Menu items are difficult to access with keyboard
Keyboard trap
Code editor mode or Command mode information not conveyed
Thanks for working on this and posting the results!
What do you think is the next action to take?
There are several posts on this forum as well as on GitHub that talk about accessibility work, needs, audits, etc. It would be good if we could keep the number of issues constant instead of increasing them by starting new topics each time. Otherwise we end up with bits of information in 101 places. So maybe a next step would be to link all of them and/or post on GitHub - jupyter/accessibility: A repository for ongoing work around making Jupyter's software accessible and inclusive which @ellisonbg created but hasn’t seen much action so far. Some of the other topics I could find:
Now that I opened the GitHub repo I see you already posted an exact copy of your post there as well. Where do you want to discuss this? In my experience posting in more than one places leads to split brain syndrome :-/
Hey Tim – I suggested to Eileen she post in both places, since it seems the discussion has been spread that way anyway. The accessibility repo on GitHub was set up for discussion, wasn’t it? Just like this forum? Where do you all want us to post this stuff?
The next step for this is to make some fixes though Eileen is finishing up her work on this project this month, I am hoping to continue facilitating this work at NYU and have some folks actually make PRs, etc. But proposed changes first need to be discussed, yes?
I’d post in one place with pointers from others that note “please go over there for discussions” to avoid having two or more (diverging) discussions.
I don’t know what the best way forward is.
The document is great because you can look at it and even without knowing much about WCAG you can see what the items are that need work. Then question then is “ok, what needs changing and what does it need to be changed to?” Following the link to Web Content Accessibility Guidelines (WCAG) 2.0 I’m still none the wiser as to which attributes or additional HTML elements need to be added or if that is even the thing to do.
Probably if you are an experienced in working on this you take one look and know what needs to be done. However that person will probably not have experience in how the notebook code is organised, so they’ll get stuck trying to work out where to change stuff.
The place I’d start is to take each of the items in the document, check if there is already an existing issue for it on the notebook repository, then create/add to an issue the description from the document with pictures. To do item: determine what HTML stuff needs to be added/removed/changed (the outcome would be something like “all <input> items need a <label> tag describing them, an example is link-to-an-example”). Now someone else can pick up the issue and either do it or figure out where the change needs to happen.
Divide and conquer with the goal that each “to do” takes a few minutes for a person with the right skills. Then if we advertise it people can pick off onne or two when they have a short amount of free time. “Ah, I’ll do something nice for the project, I’ll go and update some HTML by following the instructions left in the issues” or “I’ll do something nice for the project and translate human words describing a problem into concrete changes needed”.
The other thing that would be helpful for items like the “change in notebook state isn’t announced” is to expand the “how to reproduce” instructions. Right now it says “perform any of the tasks while using VoiceOver”. I have no idea how or what voice over is :-/ which means in a short break I won’t try and work on this because I don’t know how to “see” (in this case hear…) the problem.
The hard part isn’t that people can’t find out if they invest enough time but that people don’t have the time to invest. Which is why I think breaking down the tasks into “5 minute” tasks will be helpful. Even though it feels like spoon feeding.
Since we’ve started discussions here, I’ll have the GitHub post point here.
Some issues, such as anything tagged under 4.1.2 in the spreadsheet, will likely need discussion with people who know Jupyter for the best way to implement the change, because it might be helpful for coming up with a set of guidelines writing accessible code for Jupyter. For example, the icons on the file browser of the notebook intend to show information about whether the item is a folder, notebook, text file, but this information is not conveyed to a screen reader. The screen reader (VoiceOver in this case) skips over the icon, and only identifies the next item (folder name or file name) as a link. How this should be implemented is probably better defined by someone who is more familiar with notebook code. WAI-ARIA Authoring Practices 1.1 has design patterns and examples, as well as information on how to make sites accessible.
VoiceOver is just the screen reader that every Mac has, which I used as a quick test. I don’t have a Windows computer, but other popular screen readers are NVDA and JAWS, which should be tested too for evaluating success of changes. I can put in some extra details for “how to reproduce” instructions, but it’s basically just to turn on any screen reader and try to use the notebook to see what breaks.
I would be very interested in communicating with your group. There really appears to be at least 3 distinct paths of inquiry regarding access to the scientific disciplines: One for blindness focusing on access to audio and Braille, Low Vision which focuses on increased visibility and dyslexia which appears to require audio and visual accommodation along with other factors I have never imagined.
We really need to address this with full communication between these three tracks.
though Eileen is finishing up her work on this project this month, I am hoping to continue facilitating this work at NYU and have some folks actually make PRs, etc. But proposed changes first need to be discussed, yes?