search

jupyter / notebook

Jupyter Interactive Notebook
https://jupyter-notebook.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
11.63k stars 4.89k forks source link

Accessibility Issues Needing Addressing for WCAG 2.1 compliance (As of Version 7.0.0a15) #6800

Open manfromjupyter opened 1 year ago

manfromjupyter commented 1 year ago

I know Jupyter Notebook v7 just announced huge accessibility improvements recently available in alpha but I wanted to throw my hat into the ring with remaining pieces before we celebrate fully that it's fully accessible. Lot of this is super low hanging fruit with potential huge impact.

Summary

Blind Users – minorly functional but with great annoyances. Grade C Low Vision – almost completely supported, mostly minor annoyances. Grade A- Color Blind – almost completely supported on light theme, Grade A-. Same A- on dark theme Ambulatory - mostly usable, just a few blockers for supplementary actions. Grade B Deaf/Hard of Hearing - completely supported. Grade A+ Cognitive - completely supported. Grade A+ Seizures - completely supported. Grade A+

Related to https://github.com/jupyterlab/jupyterlab/issues/9399 but NotebookV7 obviously much better and what should be recommended to persons with disabilities and just needs a few small fixes to be fully supporting of Low Vision, Color Blind, and Ambulatory users.

Issues

Issues (Broken Down)

Language

Focus

Issue Area # 1

Issue Area # 2

Content, Organization, and Navigation

Issue Area # 1

Issue Area # 2

Issue Area # 3

Issue Area # 4

Color, Contrast, and Zoom

Issue Area # 1

Issue Area # 2

seirani commented 1 year ago

Hello! I noticed that the "skip to main content" feature is still not implemented. I have some experience working with accessible design and would love to contribute to this or any other open tasks listed here if it would be of any help?

jtpio commented 1 year ago

Thanks @seirani! If you would like to get started on this please feel free to open a PR. Thanks again!

seirani commented 1 year ago

Awesome, thank you @jtpio! Quick question: I am trying to navigate the Jupyter Notebook codebase and am a little confused as to where exactly the HTML notebook files or .less files are located - I can find the template HTML files that are pretty sparse and seem to be configured elsewhere? But for a feature such as this one where I'd likely add a div and a link, where would I make that change to have it go into effect? Or do I have to run something first to make them appear? Thank you in advance!

jtpio commented 1 year ago

The templates are minimal and similar to the ones in JupyterLab. This is because the application populates the DOM on startup when the shell is created.

Probably it would have to be implemented similar to what was done in JupyterLab: https://github.com/jupyterlab/jupyterlab/pull/10126

manfromjupyter commented 1 year ago

Sorry for scope creep, but I forgot 2-3 things that I found just recently that are worth noting to get fixed.

  1. Color contrast of code blocks syntax highlighting (I recognize it might be another code base)
  2. Few things being hidden when zoomed in to 400% that shouldn't be hidden
RRosio commented 1 year ago

There are at least 14 remaining tasks, could we identify which would be release blockers from these?

krassowski commented 1 year ago

Minor dark theme color contrast fix on "About Jupyter Notebook" modal.

Can we check this one? I believe this one was also reported in https://github.com/jupyter/notebook/issues/6552 / https://github.com/jupyterlab/jupyterlab/issues/14084 and fixed on JupyterLab side by https://github.com/jupyterlab/jupyterlab/pull/14159.

isabela-pf commented 1 year ago

In the 31 May 2023 Jupyter Accessibility meeting (cc: @andrii-i), it was requested that people weigh in on which of the listed items on this issue are release blockers—defined as issues that prevent someone from using the notebook in full.

I can only speak for myself, but here is my brief-as-possible thoughts on which are blockers and which are not. I've copied the tasks listed above and added my thoughts in the second level of checklists for each item.

andrii-i commented 1 year ago

Thank you for quick and detailed feedback @isabela-pf.

andrii-i commented 1 year ago

Based on discussions during the calls, if certain issue is a regression vs Notebook 6 and if it is solvable in a reasonable amount of time should also be taken into account when determining release blockers.

gabalafou commented 1 year ago

This came up in yesterday's accessibility call.

During that call, I committed to attending the triage meeting on Tuesday, June 13 (I've added it to my calendar). If this issue still needs triaging at that point, I can help then. (I'm going to be out all next week, is why I can't attend next week's triage.)

In the meantime, here's how I would go about identifying release blockers by Andrii's definition in today's accessibility call. The definition he shared is that release blockers are problems that prevent people from using major features of the Notebook. I would start with the list of things that Isabela identified as blockers above and ask three questions:

  1. Is this essential functionality? (I think Isabela already took that into consideration, though, in her pass-through)
  2. Is there another way to do the same thing?
  3. Is that alternative accessible?

If you answer (yes, no) or (yes, yes, no), then the issue should be triaged into the release blockers list. However, it came up in the call that it might be disingenuous or confusing to call them release blockers if they don't actually block the release.

I'm not really equipped to answer the first two questions, but I can help answer the third question about whether existing workarounds are accessible, which is why I think the fastest way to triage the above list is synchronously, so we have enough information in the heads of the people in the room to answer all three questions at once for each of the items in the list.

jtpio commented 1 year ago

release blockers are problems that prevent people from using major features of the Notebook

Since there are very limited resources on Notebook 7 at the moment, I think we should consider an issue as blocking if it prevents someone currently using Notebook 6 to migrate to Notebook 7. Either because there is a big regression, or because something is missing in Notebook 7. Normally accessibility should already be largely improved in Notebook 7 as of today compared to Notebook 6.

All the issues mentioned above should eventually be fixed for sure, but they could also go in 7.0.x patch releases to not block the 7.0 final release.

manfromjupyter commented 1 year ago

Just three comments on @isabela-pf's. Thank you making that btw.

Main page (tree page)'s table is not a real table; it's <div>s within <div>s which works for visual users but not blind users/screen readers.

Blocker. While this description does not make it clear enough for me to know how it interacts/ how it is blocking, the tree page is a big and important part of the required user flow. It's needed to open a notebook at all. This needs to work with a screen reader.

This is needed for blind users because properly made semantic <table>s give them a full suite of additional capability than if artificially constructed to look like such. These things include:

  1. Visiting cells on a table it will announce the column (or row or both) it belongs to based on the <th> elements
  2. Allows them to read the whole row at a time
  3. They can copy entire rows
  4. They can with a keyboard shortcut jump to top of table, bottom of table, left, or right.
  5. They can list all tables on the page
  6. They can jump straight to them if they know it exists (same way they can jump to the <h1>, <h2>s, etc. just by pressing "H"). So kind of a usability thing for this one but just speeds up their workflows tremendously.

Keyboard-only users (ambulatory), do not see the hoverable/tooltip of the icons in heading and in code cells when focusing on the elements.

As much as it pains me, I think I have to call it not a blocker. The buttons working is more important. This is a major issue of focus. I could imagine it as a blocker if things are not named appropriately and their function is unclear, though.

You're right that users with ambulatory disabilities can just try to figure out what these icons mean by looking at them and at worse try each one and remember. Being able to see the tooltip though that even says what the keyboard shortcut is to hit it at any time (ex. SHIFT + ENTER) to run a selected cell, this is pretty big for their experience and sanity.

Notebook cell actions are not announced to screenreader. User does not really know when cell was run, stopped, moved, duplicated, etc. successfully or what the cell is currently outputting automatically without manually doing it as it's popping out (which they won't be able to see to know to follow alone.

This one is hard because it is so big. And important. I don't think we have an ideal experience for this even for our sighted users. I want to call it a blocker but I do not know how we would solve it.

Not sure if this is a path you want to go but I always add this kind of capability by doing the following.

  1. Create <div id="screenreaderAlerts" class="sr-only"></div> and slap at the bottom of your page somewhere (or perhaps at bottom of the notebook pages if we want to keep this small for now).
  2. Insert following function in JS where the other JS files inherit it and can thus use it. 
    /* ===== Make Screenreader-Only Alert ===== */
function makeScreenreaderAlert(element_id, on_message, off_message){
let element = '#' + element_id;
if ($(element).length){
$(element).text(message);
}
else {
$('#screenreaderAlerts').apend('<div id="' + element_id + '" role="alert">' + message + '</div>');
}
}
  3. After what JS or whatever controlling the moving, running, deleting, etc. of the notebook cells, just follow it up with a: 
    makeScreenreaderAlert('notebookActionAlert', 'Cell has finished running.');

    The purpose of the element_id part of it is so you can override it with other actions of the same type and users can re-read alerts as they wish and it doesn't take away from the visual-user experience. Example of the former is if you want to fire one on cell run start and cell run finish, if it's a 20 second cell run, it could alert them that "Cell has started running" and then would read that "Cell has finished running". If the cell only takes 0.5 seconds to run, it may only read "Cell-" of that first message before getting interrupted/replaced and reading "Cell has finished running" in full. Anyway that's just how I do it for my other apps, you do you though.

andrii-i commented 1 year ago

Thank you for feedback everyone. Moving to 7.0.x for further follow up after Notebook 7 release. Related comment: https://github.com/jupyter/notebook/issues/6307#issuecomment-1587710396

tonyfast commented 1 year ago

it was shared there it might help to break the checklist into issues. i've started that process and added what i could.

it would be awesome if folks could add any knowledge they have about solving any of these. lines of code, relevent prs. the more information we have the better chance we have for success. please, if the urge strikes you, help with splitting out the rest of the checklist.

should we transition this issue into milestone?

andrii-i commented 1 year ago

Thank you very much for creating so many issues @tonyfast, this helps a lot. We absolutely should assign them to milestones and add additional details where possible. We should start triaging these issues individually (started) and during calls.

tonyfast commented 1 year ago

of these issues i've triaged, i think the following should be pretty attainable (complexity increases with number)

  1. 6927

  2. 6924

  3. 6931

  4. 6930

afshin commented 1 year ago

Notebook cell actions are not announced to screenreader. User does not really know when cell was run, stopped, moved, duplicated, etc. successfully or what the cell is currently outputting automatically without manually doing it as it's popping out (which they won't be able to see to know to follow alone.

This could perhaps be implemented using the new notifications UI and event system. The notifications UI will need some updates to its output for it to have the semantic information necessary to work with a screen reader.

andrii-i commented 1 year ago

I've classified remaining issues created by @tonyfast into bug or enhancement category. They could still use another pass to assigning them to milestones.

tonyfast commented 1 year ago
  • All hoverables (tooltips) that appear on hover do not go away when pressing the ESC key.

@manfromjupyter which tooltips were you having trouble with? i've able to dismiss the inspector, menu and toolbar tooltips. am i missing some?

manfromjupyter commented 1 year ago

@tonyfast I'm so terribly sorry for the delay. I haven't had access to my email for a couple months. I just tested it and I'm not sure why I put that hahaha. I agree no hoverables are appearing I can't close with ESC as is. Perhaps I meant that once the hoverables work on focus/being tabbed to to make sure we double check that ESC still works to hide them. Thank you (Edited the original issue above to reflect this).

tonyfast commented 1 year ago

@manfromjupyter thanks for checking that again

just a heads up. i split the skip link and tabbing item into two separate items. the skip link has been addressed by https://github.com/jupyterlab/jupyterlab/pull/14597 . there are still some fixes we can use to ammend the number of tabs to get to a cell. per discussions in meeting we want to reduce the tab stops as much as possible.

gabalafou commented 1 year ago

@tonyfast, just a heads up that the skip link code for JupyterLab and Notebook 7 have diverged, so https://github.com/jupyterlab/jupyterlab/pull/14597 is irrelevant for Notebook 7.

Notebook 7 uses a different "shell" than JupyterLab. The shell creates the skip link, so Notebook 7 defines its own skip link.

tonyfast commented 1 year ago

thanks for the clarification. i didnt know there was a difference in the shell. thanks for the heads up. the complexity is tough to cut through sometimes.

we do have a skip link in v7? correct?

gabalafou commented 1 year ago

Yes, but... the skip link in Notebook 7 is broken. The following video shows that the skip link appears when the user tabs from the top of the document, but when the link is clicked, it doesn't skip the user forward. As the video shows, when you press the tab key after clicking the skip link, you still have to tab through UI elements (Jupyter logo, menu bar, etc.) that come before the main area.

https://github.com/jupyter/notebook/assets/317883/59590b95-d29a-4735-a91e-a2f2e0e2dfb3

jtpio commented 1 year ago

Linking to the following two open issues on the repo that are also about accessibility:

Should we close these two issues now that the accessibility focus is on Notebook 7? Or is there anything from these issues that should be listed here or tracked in separate issues?