Support for text resizing up to 200%

[rf-uw]

Expected behavior

Text and UI components should be resizable up to 200% without compromising functionality per WCAG criterion 1.4.4.

Actual behavior

Standard browser/device resizing tools can cause portions of the interface, including the code window and stage, to become obstructed/unusable. This is especially problematic in Learn, where the tutorial window takes up a significant amount of space and forces the code and stage windows into too small a space; the result is that some buttons and icons are partially or completely obscured. Opening secondary windows like the palette or guide completely obscures the stage or code window. Additionally, while a lot of components are visible/accessible at the larger text size through scrolling or toggling, this is a cumbersome way to interact with them and makes it significantly more difficult to (for example) read and write code.

The examples below are from desktop Chrome; I also tested on tablet Safari and got worse results, which I will endeavor to share in the comments.

Screenshots

An example from the tutorial (Chrome, macOS):

The interface at normal size.

The interface resized to 200% using Chrome's resizing tool. Obscured interface components circled in red. Some are still usable but visually obscured, some are not clickable, and some are gone entirely. The tutorial window, symbology bar, code window, and site settings/directory bar at the bottom are all scrollable; everything else is static.

Opening the palette completely covers the stage.

The worst-case scenario - the guide, palette, tutorial, code window, helper window, and stage window are all open at once. (Admittedly extreme, but this probably shouldn't be possible!)

Environment

What platform, OS, browser, and version are you using? Please be exact with version numbers, as different versions can result in a defect happening or not. Don't skip these; cross-browser issues are a common cause of problems.

Tested resizing on: Laptop:

• macOS 14.0
• Chrome 121.0.6167.160

Tablet:

• iPad Air 5th gen.
• iOS 17.3
• Safari 17.2

Design Proposal

My design for this issue involves changing the relative proportions of all the current elements present on the interface, in order to better support resizing upto 200%.

I have attached a drawing below:

 As you can see, I merged the header with the site settings/directory bar at the bottom, in order to make use of the empty space at the top. I also propose icons for the ‘saved online’ and the ‘user’ elements, in order to save space. The proposed icons are a tick mark, which usually accompanies the text ‘saved online’, and the emoji chosen by the user, which usually accompanies the username as well.
This created space for the symbology bar to have all its elements resized without having to scroll, making most, if not all, the interface components usable.

For the palette and guide windows, instead of opening alongside the tutorial, code window, and stage, I propose that they open as a pop-up instead. I have attached a drawing of this below:

 (A drawing of the proposed design for resizing upto 200% with the palette window, which usually opens alongside the tutorial, code window, and stage, opening as a pop-up instead)

While having the palette window open as a pop-up will visually obscure the interface, it allows resizing upto 200% with compromising as little usability as possible.

[amyjko]

Thanks for reporting @rf-uw! This is super critical to address. Can you do a few things to improve the issue text?

• Change to a bug report instead of an enhancement (using the bug report template). Since WCAG is a target standard we're trying to meet, and this fails to meet it, these are defects.
• When writing this as a defect, detail the precise cases where scaling causes obstruction, so we know what cases we're trying to design for.
• Include details, per the bug report template, of which devices and window sizes you're using.

Thanks!

[rf-uw]

Reformatted and added specific examples - will continue to update as I find other examples of problematic behavior.

[rf-uw]

Addendum: in designing resizability, I would argue that slightly violating WCAG 1.4.4 may be necessary to ensure that the core functionality of the interface is maintained - the fundamental issue here is that there isn't enough space on the screen for everything to get resized to 200%, so some compromises have to be made as to what gets resized and what doesn't; for example, forcing the "Learn" header to resize along with everything else in the tutorial means that ~1/4 of the vertical space gets taken up by a mostly empty cosmetic component. Excepting it and certain other components from resizing is technically a violation of the guideline, but would provide a lot more freedom in trying to fit everything in without losing functionality.

[amyjko]

Thank you @rf-uw! Removing needs triage from this, and adding needs design. Another design consideration is how to elegantly scale down to tablet and mobile size screens as well. Some of the same layout issues occur at 100% zoom on mobile. Whoever tackles this design challenge should think about what our responsive strategy should be: hide everything in menus, automatically collapse tiles, etc? I'm excited to see what everyone comes up with!

[leisha5]

@amyjko My design is ready for review

[amyjko]

@leisha5 These are good brainstorms, thanks for the design proposal! A few reactions:

• Icons are an okay strategy for condensing, but they can reduce comprehensibility, as they are not culturally universal, and touch screens have no way of showing tooltips.
• The design you should uses the tutorial page, but that is not the same layout as the project view page, which doesn't have an empty header. Wouldn't it also be very jarring to have the footer jump into the header after a certain size? Or are you proposing that it always be at the top? I would focus the design on the project view, which is the main view that's the issue here (and aggravated further on the tutorial page, which has even more content).
• Pops ups are generally highly inaccessible for people using screen readers, unless there is a dedicated task that does not require switching between a popup and other views that can be completed without leaving the popup. Using the palette, however, requires viewing the palette and the corresponding edits to the output and program, which requires a lot of window switching. That would be very hard to use for someone using a screen reader and text magnification simultaneously.

I think I'd recommend exploring designs that 1) do not require popups, 2) that rely on overlapping views (like a stack of views). Consider looking at the proposal in #409 for ideas, which is exploring layouts for small screens (essentially the same problem here, where large text turns a large screen small). We'd likely want to resolve these with the same design.

[leisha5]

@amyjko I would like to work on this issue. Could you please assign me to it?

[amyjko]

Hi @leisha5! I assume you want to resume design work on this?

[leisha5]

Yes!

[leisha5]

@amyjko I am unable to edit the main issue body

[amyjko]

@leisha5 It looks like this is a limitation of non-collaborator roles; even when you're assigned an issue, you can't edit the issue body. For now, we're going to change the design process to place design proposals in comments instead. That has tradeoffs, but will work around this GitHub limitation.

[leisha5]

Thank you for all your feedback @amyjko! As per your suggestion, I decided to focus on the project view page. The proposal in #409 used a hamburger menu, but I used an accordion-style menu for my modified proposal, as I thought it seemed more intuitive for a laptop/tablet screen. I also felt it fit in better with the existing layout. Additionally, the new design does not include pop-ups, but still involves a fair amount of window switching– I’m not sure how one can remove that aspect while maintaining 200% magnification.

My proposal involves putting the stage, guide, and palette in an accordion-style menu, with a split-screen interface with the editor. I have attached a few drawings below:

The editor occupies the left side of the screen. The right side of the screen features an accordion menu of the stage, guide, and palette. Only one thing from the menu can be open at a time, and this will have a split-view with the editor.

For example, the possible combinations are: editor and stage in Split View, editor and guide in Split View, and editor and palette. My current design does not include having the editor in full screen if none of the elements from the accordion menu are open, but that can be added.

Further design elements include having the interface components organised in two lines, instead of one scrollable line, making it more accessible for screen readers.

[amyjko]

I like the concept. Several questions:

• What would breakpoint be for this different window behavior? For example, if a large desktop window is reduced in size, what when would it switch to this accordion behavior, and when would that behavior switch to the small screen layout proposed in #409? (You should probably talk the new dev on #409 by the way, as these two issues are very related).
• Could the editor be collapsed in this mode? (It can currently, to just view the stage. What happens then? Is it one huge accordion?
• What happens in full screen mode, when one of the titles is maximized? Is the accordion visible at all?
• Scrolling isn't actually an issue for screen readers; (screen readers don't care about what's visible; they provide make all things navigable regardless of they're visible in the window).