Full Low Vision Support (400% zoom) (Mobile/Tablet-Responsive Support)

[manfromjupyter]

Purpose: Fully support all users with a low vision disability on JupyterLab
Screenshots for points 1-4 below: https://imgur.com/a/OStTXXr
Derivative from: #9399
Required Skills: Purely CSS (my guess)

Todo

All sites needs to have the capability to zoom to 200% for WCAG2.0 compliance (~Tablet support), or 400% zoom for WCAG2.1 compliance (~Mobile support) WITHOUT causing anything but vertical scroll bars to appear. The goal of this ticket is to support 400% zoom. If we're gonna do it, let's do it all the way.

1. All header dropdowns need to no longer truncate off the side of the page (6-7 screenshots on the imgur link)
2. All panels needs to have their heights flexible (ex. 100%) so they can be scrolled (may have to remove a overflow: hidden somewhere)
3. All panels with sections with predefined heights (ex. 200px), this needs to be removed and moved to an automatic height. Goal is to remove all vertical scroll bars but the main one that controls the scrolling down of the entire panel section. Some of these sections are collapsible so if having to scroll for too long is a problem, new features need to be added to support collapsing of other panel's sections that don't already have it. (2-3 screenshots on the imgur link)
4. Need to handle multiple panels open at the same time. I present 2 options:
   a.) When panel is open on 400%+ zoom, it needs to either be full width and collapse the opposite side's panel and also find a way to collapse the notebook region (middle/main panel) (screenshot on the imgur link of both options)
   OR
   b.) the side bars need to become overlaps (think how dropdowns work) and then need to drop a background color over everything else that makes it a transparent dark gray color where nothing in the dark gray area is clickable until the panel is closed (screenshot on the imgur link of both options). Only thing missing is notebook underneath it would be the full 100% width of the page (minus the sidebars of course).
5. Not labeled on screenshots but very important is that the right sidebar AND footer still appears. If the final design decision for the sidebars is to make them derive from a single source, switch to horizontal tabs, OR collapse on each side to give way for more real estate for the notebook section, that is beyond the scope of this ticket. For this ticket, merely need to make it sticky (on the right side and left side) at every screensize AND make sure the footer is sticky to the bottom (it doesn't take up much space, should be fine). position: fixed in CSS will let you affix something in one place so it remains on scroll.
6. Not labeled on screenshots but very important is that the sidebars need to not have elements that are unable to be scrolled to. Example in the screenshots, the bottom 2 icons to opening debugger panel and extensions panel I think is unable to be put into view to be clicked on at 400% zoom. This can be done by either making the height set to a viewport height (vh) of maybe 100% or calc(100vh-120px) or whatever the size of the header is and then just make sure a min and max-width is set so the size does not get too small or too large if they move all of the actions to the opposite side bar or zoom in to 500% despite it not being supported. The alternative and perhaps ideal way to achieve this is to just allow it also to be vertically scrolled down.

OPTIONAL: One header dropdown causes a subdropdown to appear. Make sure that one looks appropriate. Technically doesn't need to be done to support these things but will look tacky if it's not done. Just needs to open below the tab in the header, not above pretty much.

Not Included

• Another requirement I left off is for low vision support need to make sure error messages (pop ups, inlined, etc) appear where a user can see it (with 500% zoom on). If you cause any errors, must appear within sight of user. This might also be supported and requires a bunch of flushing out of these errors which I have been unsuccessful with doing.
• Icon selectable areas need to be 44px by 44px wide minimum for WCAG2.1 (if I remember correctly). This size keeps changing year after year it seems so it's not as important to me. We will need to make probably the size of the File Browser icons larger, but think the side bars and notebook editor icons are fine. Definitely not worth raising the lift of this ticket as these are the biggest things holding low vision and mobile-support back, this is just a nice to have.

[isabela-pf]

Summary (added per request): JupyterLab needs to support zooming in UI and open documents up to 400% without losing information out of the window or requiring horizontal scroll bars. There are two strategies we could keep in mind to solve this: 1) prioritizing the document and keeping it in focus at all zoom levels 2) prioritizing the UI and scaling back the document to make room for it. Please provide feedback on what you think we could do!

---

To my knowledge, JupyterLab's browser zoom situation hasn't changed since this issue was posted. The above comment and #9399 provide great context. For a more recent review scoped only for zoom, you can also visit @steff456's aggregate review issue to see in detail how this is still a problem in JupyterLab now.

Possible solutions

While the above comment lists what is needed, I'm going to give some proposals of how that might work on a high-level for the different UI regions. These proposals are two extremes; I personally expect we'll end up somewhere in the middle, but I think this is the best place to start discussing since it could include several impactful UX changes.

Document emphasis (option 1)

In this approach, when screen space is limited—whether because of high browser zoom or a small window—the document area becomes the primary focus. Everything else is able to be accessed, but not all the standard UI is immediately visible.

Screen.Recording.2022-09-28.at.5.00.59.PM.mov

The major changes:

• This version continues to put the document area into focus at small sizes by removing some of the surrounding UI and adding it to the command palette.
• The command palette is given a button for easy access, and regions that collapsed have sections to group their commands pinned to the top.
• Open document tabs are grouped and collapsed behind the ellipses, but switching them does not open new browser tabs.
• UI areas originally in the sidebar become their own tab in the document area a la the launcher or settings. UI areas that are reliant on a selection in the main area appear as an overlay to the tab, but this should be used with discretion.

UI emphasis (option 2)

In this approach, when screen space is limited the UI takes most of the space. The document is prominent as possible, but UI takes precedence and must be collapsed by default. This is essentially the current JupyterLab behavior at all zoom levels, but optimized to fix bugs and make the interactions more intentional.

Screen.Recording.2022-10-12.at.7.25.40.PM.mov

The major changes:

• Sidebars collapse as they already do, but when they expand they do (as is mentioned in the prior comment) take up most of the screen.
• Like option 1, open document tabs are grouped and collapsed behind the ellipses, but switching them does not open new browser tabs.
• Because it's been discussed in other situations, I also think it is still worth adding a command palette button back to the UI. Having it at the bottom of a main menu is still quite out of the way for such a powerful tool.

Additional context

There are many details to work out area by area once we agree on the general approach. I still think we need to agree on this high-level direction first because it could change how we need to solve these problems.

Feedback is not only welcome, but desired! I'd like to get fixing this. To get conversation going, you can ask yourself

1. How do you think this compares with JupyterLab’s current behaviors at 100% zoom and higher?
2. What problems and edge cases can you think of facing with removing areas of the UI? Or with the ones I’ve proposed adding?
3. What technical constraints come to mind?
4. What UI do you think does a good job at this?
5. What parts do you like? Why do you like them. You can do the same for dislikes.

[krassowski]

open document tabs are grouped and collapsed behind the ellipses, but switching them does not open new browser tabs.

This was also discussed in #10305 with a work started on scrolling for the tabs open in #12278 (which I would love to finish soon)

[isabela-pf]

I’ve been asking for feedback across a few meetings in the community calendar and I want to summarize some of what I’m hearing. I hope this helps people who aren’t at these meetings join the conversation. Comments include:

• In past versions of JupyterLab, at about 200% zoom and higher the UI switches to simple mode to let the document take up most of the window. This seems like a precedent for Document emphasis (option 1) where the surrounding UI is pushed to the side in favor of the document.
• Some people consider Document emphasis (option 1) to be an entirely different user experience than the rest of JupyterLab and that it should be disqualified for that reason.
• Because UI emphasis (option 2) is closest the the current UX, this should be the direction we take. The goal here is to minimize experience changes.
• Prioritizing the document when zooming (Document emphasis (option 1)) makes sense for demos and other presentations. This is what people often want when they zoom in to screen share as well.
• @krassowski recommended a different approach than either of the above: having different controls for zooming documents versus UI. Document zooming takes precedent, but UI zoom can be determined in Settings and perhaps changed quickly with a different command. This behavior matches some other document-focused applications.
  • To review this we also collaboratively noted zoom behaviors in some other applications. The sample is one of convenience, so don’t take it to be too meaningful. The full review notes are on hackMD. Summarized in a table that looks like:

App	1. Does the app respond to keyboard-driven zoom commands?	2. Does the app respond to mouse-driven zoom commands?	3. Does the app have a feature to resize document text (or other elements) only?	4. Does the app have a feature to resize UI text (or other elements) only?
Microsoft Word	No	Yes; only the document/main content zooms	No	No
XCode	Yes; only the document/main content zooms	No	Yes, in the settings/preferences	No
Figma	Yes; only the document/main content zooms	Yes; only the document/main content zooms	Yes, it can be found somewhere else	Yes, it can be found somewhere else
RStudio	Yes; everything in the app zooms	No	Yes, in the settings/preferences	No
HackMD	Yes; everything in the app zooms	Yes; everything in the app zooms	No	No
Adobe Photoshop	Yes; only the document/main content zooms	Yes; only the document/main content zooms	Yes, in the main/home UI	Yes, in the settings/preferences
Microsoft Excel	No	Yes; only the document/main content zooms	Yes, in the main/home UI	No

---

As far as I’ve heard, there’s no clear next step we want to take or direction that has more support. I’m not sure how we want to move forward at the moment, but I will continue to follow up.

[krassowski]

An important data point is Microsoft Word Office 365 (which is the Word version running in the browser). It responds to zoom:

• mouse-driven
  • when you hovers over the document (or the background), it zooms the document
  • when you hover over the non-document UI (Ribbon or statusbar) it zooms the entire page
• keyboard-driven:
  • zooms document if document is focused or nothing is focused
  • zooms entire UI if Ribbon items are focused/menu is open etc

When UI is zoomed it collapses more and more items progressively but does not change the overall layout (statusbar/Ribbon/menu stay where they were to begin with).

This seems clever and works exactly as I would expect.

[isabela-pf]

Summary: Let's informally vote on which of the above directions we want to pursue so we can move this issue forward into fixes!

---

Based on discussions in this issue and this week’s JupyterLab meeting, we’re going to take an informal poll on this issue to figure out which direction to pursue reflow/zoom fixes for. If there’s any objection, this can become a formal JupyterLab Council vote. So far, little concern has been expressed and I’d like to start fixing this issue in earnest.

React to this comment with the following to vote:

• If you are in favor of following Document emphasis (option 1) react with ❤️
• If you are in favor of following UI emphasis (option 2) react with 🚀
• If you are in favor of following the unnamed third option where document and UI zoom/reflow are separate operations (roughly as described in @krassowski’s comment) react with 👀
• If you are not in favor of any of these options and would like to actively abstain react with 😕

I will tally the reactions and comment below after midnight Monday Nov 21 Anywhere on Earth unless there are any objections.

As always, I’m happy to answer any questions you might have! I believe any of these directions can give help us resolve this issue accessibly.

[krassowski]

Another comment: I often use zoom at ~150% when using 4k screen as I prefer that over increasing fractional scaling desktop environment-wise. It is not clear to me at which point the proposed change to the UI layout from option 1 would be triggered, but I would prefer it to be based on the available space rather than zoom alone (or both, e.g. condition like zoom > 200% AND screen resolution/zoom < {threshold}).

[isabela-pf]

Sorry for the delay, since this was a tie at the deadline, I'm going to tiebreak.

While options 1 and 3 have traits I think could make strong interactions for zoom behaviors, the resources we have to make these fixes throughout the UI make me think option 2 (UI emphasis) is the best step for now. This involves mostly fixing existing behaviors rather than working on an entirely new experience.