Content overflows and is cut off at 200% text enlarge

[karlgroves]

Content overflows and is cut off at 200% text enlarge

• Severity: Medium
• Affected Populations:
  • Low-Vision
  • Cognitively Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Block Panel
  • Document Panel

Issue description

Several controls allow text to overflow out of them, or clip the text, at 200% text enlarge. This is due to containers being set in fixed pixel heights, which cannot grow with their content.

The checkmark icons move out of their checkboxes as they grow, leaving a white checkmark against a white page background.

The ability to resize text is essential for users with low-vision, and may be helpful for users who have a cognitive disability. Catering to zoom alone is not sufficient because the browser's font-size may be increased independently of zoom level.

Issue Code

    /* selects */

    .wp-admin select {

        ...

        line-height: 28px;

        height: 28px;

        ...

    }

    /* checkboxes/radios */

    input[type=checkbox], input[type=radio] {

        ...

        height: 16px;

        ...

        width: 16px;

        min-width: 16px;    

    }

    /* buttons */

    .components-button.is-large {

        height: 30px;

        line-height: 28px;

        ...

    }

    .components-button.is-small {

        height: 24px;

        line-height: 22px;

        ...

        font-size: 11px;

    }

    /* pressable buttons */

    .components-toolbar__control.components-button {

        ...

        width: 36px;

        height: 36px;

    }

    /* number inputs */

    input[type=number] {

        height: 28px;

        line-height: 1;

    }

Remediation Guidance

Avoid setting fixed heights on elements (even inputs), and especially in px units. Instead, set min-heights on containers, allowing them to always expand to enclose their content, and allowing containers to themselves wrap as needed.

The Recommended Code is using a minimum of 44px for the settings (following https://www.w3.org/TR/WCAG21/#target-size), meaning designers may want to reconsider how they want to show some buttons as larger than others (visual importance), as well as dealing with horizontal button rows wrapping as necessary (such as in the "Image Resize" section of the Block Panel).

The checkboxes are made larger so that the growing checkmark icon remains visible inside the checkboxes (by allowing them to grow with the checkmark). These do not need to meet target size minimums as they are inline with their (clickable) labels.

Recommended Code

    /* selects */

    .wp-admin select {

        ...

        min-height: 44px;

        ...

    }

    /* checkboxes/radios */

    input[type=checkbox], input[type=radio] {

        ...

        height: 1.5em;

        ...

        width: 1.5em;

        min-width: 16px;    

    }

    /* buttons */

    .components-button.is-large {

        min-height: 54px;

        ...

    }

    .components-button.is-small {

        min-height: 44px;

        ...

    }

    /* pressable buttons */

    .components-toolbar__control.components-button {

        ...

        min-width: 44px;

        min-height: 44px;

    }

    /* number inputs */

    input[type=number] {

        min-height: 44px;

    }

Relevant standards

• 1.4.4 Resize text (Level AA)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-32 in Tenon's report

[melchoyce]

Full report screenshot:

[afercia]

Discussed during today's accessibility bug scrub: not so much to add here, everything makes perfectly sense and just needs to be fixed 🙂

[kjellr]

I opened #15973 to start working through these issues. A few notes:

• The button sizes, the select button size, and the number input heights actually come from WP-Admin, so we should consider fixing there too.
• I didn't tackle the checkbox styles. I believe those are lifted from core styles too, and would need a bigger refresh in order to be truly em-based. Alternatively, we switch from using an icon font for the checkmark to an icon, which would prevent this issue from occurring.
• To fix the broken H1-H6 icons, I think we'd need to switch away from using live text for the numbers there. Unless there's a way to prevent a specific element from scaling?

[kjellr]

Since this will need fixes both here and in core, I've added the [Type] WP Core Bug label, and also ported it over to Trac:

https://core.trac.wordpress.org/ticket/47477

I've included a quick draft at a patch to get things started as well.

[afercia]

To fix the broken H1-H6 icons ...

Didn't know the letter H is actually a SVG icon and the numbers are CSS pseudo generated content (absolutely positioned, thus the overlapping problem).

I'm not sure why SVG icons are used in the first place. Both the H and the numbers should be done with just text and not use absolute positioning to allow better scaling.

[tellthemachines]

The broken UI elements initially flagged in this issue seem to have been fixed, can we close this now?

[afercia]

Seems there are still some UI components that don't scale well with text enlarged. Testing with latest Gutenberg 7.9.0-rc.1 and Firefox with text-only zoom at 200%:

Font size:

• text within the select is only partially visible
• the reset button is almost entirely out of screen

Image style:

• text almost not visible

Post format (activate Twenty Thirteen to make it appear):

• text almost not visible

Minor: checkboxes:

• though functional, checkboxes don't scale very well:

Note: I did a very quick testing, so there are probably more cases.

[tellthemachines]

Seems there are still some UI components that don't scale well with text enlarged. Testing with latest Gutenberg 7.9.0-rc.1 and Firefox with text-only zoom at 200%:

@afercia this is not a Gutenberg-specific issue, it happens on all of wp-admin. Here's a screenshot of the admin bar with text-only zoom at 200%:

I'm not sure it's useful to keep this issue open for that reason. There are a few things we should tackle at a Core level regarding responsiveness:

• Set font sizes in rem or equivalent so that browser-set custom font sizes are respected;
• Replace fixed px widths and heights with relative units so that layouts don't break when custom font sizes are used;
• Setting our media queries in em units might help trigger mobile breakpoints when text zoom is used - this would need a little testing though.

It would be good to have a Trac ticket for this purpose, as well as a Gutenberg ticket so we can make the necessary changes in both repos.

Note: Firefox's text-only zoom breaks pretty much the whole of the internet: check Google or MDN for example. And apart from Safari, that has it really well hidden, I don't know of any other browsers implementing this feature. I'm not saying we shouldn't fix our stuff so it works with text zoom, but I don't see it as a high priority. Respecting browser-defined font sizes should be higher on the to-do list, as all browsers implement them.

[afercia]

this is not a Gutenberg-specific issue, it happens on all of wp-admin

I do know very well what the situation in the WP admin is. As with many other things in the WP admin, there are historical reasons why things are what they are and it's not always possible to fix long standing issues without a substantial, radical, refactoring. Instead, Gutenberg is new code and as such it's required to be accessible.

It would be good to have a Trac ticket for this purpose,

In WordPress 5.3 we removed fixed heights from most of the UI controls, see https://core.trac.wordpress.org/ticket/47477. You're very welcome to open a new ticket for all the other cases you noticed. Thank you.

Note: Firefox's text-only zoom breaks pretty much the whole of the internet: check Google or MDN for example. ... I don't know of any other browsers implementing this feature

Honestly I don't mind what others on the internet do so if "the whole of the internet" is broken, that's their responsibility. Re: Firefox: text-only zoom is just a quick way to reproduce the issue for testing purposes. There are other ways to increase the default font size via the operating system, browser settings, add-ons, etc.

Replace fixed px widths and heights

Totally agree and that's what we did in WordPress 5.3. Seems Gutenberg still uses fixed heights though.

I don't see it as a high priority

Thanks for sharing your opinion. I think I explained you may have misinterpreted the issue, as it's not just about Firefox. For the accessibility team, this is a priority though. I'd also like to remind the WPCampus accessibility audit reported a series of issues, including this one, on April 30, 2019. One year has passed since then and this isn't solved yet. Honestly, I'm a bit surprised. This is not rocket science. It just requires to not use fixed heights.

[paaljoachim]

Is this issue still valid?

[tellthemachines]

Yes, this issue won't be fixed until we have replaced all uses of px units throughout our CSS with responsive units such as em, rem or %. This needs to be done not only for font sizes but for all container widths too. Ideally we shouldn't need to use px at all.

[paaljoachim]

@aristath @gziolo @youknowriad @jasmussen I think you would like to be aware of this issue and Isabels response.