Gutenberg: Content overflows and is cut off at 200% text enlarge

Created on 30 Apr 2019  路  9Comments  路  Source: WordPress/gutenberg

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

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

Accessibility (a11y) [Type] WP Core Bug [a11y] Zooming

All 9 comments

Full report screenshot:

image

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

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?

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.

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.

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

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

15356 font size

Image style:

  • text almost not visible

15356 image style

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

  • text almost not visible

15356 post format

Minor: checkboxes:

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

15356 checkboxes

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

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%:

Screen Shot 2020-04-15 at 1 47 25 pm

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.

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.

Was this page helpful?
0 / 5 - 0 ratings