Fixed content takes up too much real estate in /learn UI on zoomed viewports

[bbsmooth]

Describe the Issue

WCAG SC 1.4.10 requires that the user be able to zoom up to 400% on a 1280x1024 viewport and still be able to use the page "without loss of information or functionality". The image below shows a Step zoomed in 400% on a 1280x1024 viewport.

While technically the argument can be made that the UI is still functional at 400% the user is only able to see about three lines in the editor because the fixed content above takes up about 2/3's of the viewport height.

I'm opening this issue to brainstorm ways we might be able to give the user more space below the fixed content, which I think really means how do we allow the user to hide at least some of the fixed content.

Affected Page

Steps/Challenges in the /learn UI

Steps to Reproduce

• Open any Step in the RWD cert or Challenge in either the JS Algorithms or JS Front End certs.
• Make the browser viewport as big as possible, or at least 1280x1024px.
• Use the browser's zoom mechanism to zoom in to up to 400%. This should trigger the "mobile" layout.
• View the Code tab.
• Notice how the fixed content takes up a considerable amount of the height of the viewport allowing only a few lines in the editor to be displayed at one time.

Expected behavior

Put a mechanism in place that allows the user to temporarily hide at least some of the fixed content at the top of the page (the more the better). The user should be able to activate this mechanism with either the keyboard, mouse, or touch. While it might be nice to provide this mechanism on the "desktop" layout, I think it is only essential for the "mobile" layout.

Screenshots

No response

System

The image above was taken on:

• Device: Desktop
• OS: Fedora 36
• Browser: Edge
• Version: 110

Additional context

No response

[bbsmooth]

I suppose an alternative to hiding the fixed content itself would be to allow the editor to take up the entire view port height by superimposing it over all other content on the page. I think we would want to allow this functionality for all the tabs.

[Sboonny]

We can add the ability to open the code panel in different window like the preview page, so we can focus fully on mobile 🤔.

I can create a quick PR for refactoring this panel https://github.com/freeCodeCamp/freeCodeCamp/issues/48925, after refactoring it adding 3rd button that collapse the page should be easier.

It should be simple to implement it in CSS too, because the button will be toggle button, I think aria-pressed can be added, and if aria-pressed is true, the other section have 1px width and height.

---

TD;LR, I am in favor of showing the most out of the page.

[ahmaxed]

We can make the breadcrumbs show up in the instructions and the code tab could be a dropdown.

In addition, we could take the breadcrumb and turn it into a list of block challenges in a side drawer. The side drawer could be accessed from a button that appears in the universal main navigation on challenges.

[Sboonny]

The refactoring to grid makes the buttons hide behind the navbar when user scroll, it helps but it doesn't fix the issue.

https://user-images.githubusercontent.com/88248797/218111088-60186953-cdaa-40e3-b44a-ebea5121cf73.mp4

---

We can make the breadcrumbs show up in the instructions and the code tab could be a dropdown.

In addition, we could take the breadcrumb and turn it into a list of block challenges in a side drawer. The side drawer could be accessed from a button that appears in the universal main navigation on challenges.

This sounds cool 🤔, I am in favor of it.

Note: we have to mindful while adding, because the component affect the old JavaScript certification. 👍

[Nirajn2311]

• The files selection could be dropdowns of the code tab.
• We need to check the analytics on the breadcrumbs usage as if they're not used frequently then remove it.

[ahmaxed]

Here are the improvements I suggest for the viewports under 600px 1- remove the file selector when there is only one file, and turn the files selector into a dropdown. 2- put the breadcrumb in the dropdown navigation under the search.

[bbsmooth]

viewports under 600px

I just want to clarify, it is the height of the viewport we are concerned about here, not the width.

[bbsmooth]

put the breadcrumb in the dropdown navigation under the search.

I like this idea and I think it would work. At a 1280 x 1024 viewport, this transition happens at around 220% when the editor is taking up about 60-70% of the viewport height. So this would happen in plenty of time before the editor window gets too small.

I will put together a PR for this specific idea as a proof of concept and if we like it then we can merge.

[ahmaxed]

I understand that the height is the issue, but to simplify the problem it might help to think about it in terms of the desktop and mobile layout. Please feel free to proceed with what you have in mind.

[tobiloba7]

It seems like there are a few ways to address the limited vertical space when the viewport is this small.

• reduce margin and padding for fixed content on mobile
• hide breadcrumbs on mobile
• hide filename (maybe under a toggle or a picker)
• a button to fullscreen the code
• dropdown to hide/show all the navigation elements
• side drawer for navigating the challenges

Reducing the margin and padding and hiding the breadcrumbs when the viewport is small both seem straightforward. I will open PRs for each of those, and if those solve the issue, then great. here is a link to a prototype

The other changes seem more involved, it'd be great to have feedback on which direction to go before I start on implementation.

I'm a new contributor to the project, so let me know if this is the right approach.

[mmatsumoto1026]

After opening the #54978 PR, I noticed that with 600px threshold, unexpected behavior occurring, which is mentioned in the comment here.

With considering the height of the current mobile devices, 900px threshold was suggested and I also agree the one to avoid the behavior.

Also, The branch was tested in 400% zoom on Chrome browser, and now the user is able to see about five lines in the multifile editor on Step challenges with single file (I actually do not know this is enough but increased from three), with the fixed content above the editor takes up about less than 1/2 of the viewport height, as shown in below image (with 1920x1080 of my laptop).

400% zoomed view of multifile editor

So, can we push the 900px thresh without any other accessibility or design concern?