WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 2 weeks ago

#47477 assigned defect (bug)

Content overflows and is cut off at 200% text enlarge

Reported by: kjellr Owned by: abrightclearweb
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots wpcampus-report needs-design-feedback
Focuses: accessibility Cc:

Description (last modified by kjellr)

Moved from the WPCampus accessibility report issues on GitHub, see https://github.com/WordPress/gutenberg/issues/15356

Gutenberg inherits (and in some cases duplicates) some of the styles in question here, so I'm opening a Trac issue for this one as well. – @kjellr


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
    • (Also, buttons and form fields throughout WP-Admin)

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](https://www.tenon.io) and funded by [WP Campus](https://wpcampus.org/). This issue is GUT-32 in Tenon's report

Attachments (7)

tenon-screenshot.png (278.6 KB) - added by kjellr 4 months ago.
Screen Shot 2019-06-04 at 8.56.32 AM.png (70.8 KB) - added by kjellr 4 months ago.
Screen Shot 2019-06-04 at 8.55.41 AM.png (70.9 KB) - added by kjellr 4 months ago.
Screen Shot 2019-06-04 at 8.55.21 AM.png (58.6 KB) - added by kjellr 4 months ago.
47477.diff (3.5 KB) - added by kjellr 4 months ago.
47477.2.diff (2.4 KB) - added by kjellr 4 weeks ago.
47477.3.diff (3.8 KB) - added by kjellr 2 weeks ago.

Download all attachments as: .zip

Change History (22)

@kjellr
4 months ago

#1 @kjellr
4 months ago

I've included the original Gutenberg screenshot from the report, as well as a couple other examples inside of WP-Admin, which are more relevant to this specific ticket.

The WP-Admin screenshots were created with Firefox's Text Zoom option (set to 200%). @afercia notes that this is not exactly the same thing as the text zoom settings noted above, but it gives a general idea of the issue. (reference)


47477.diff includes a quick pass at the updates here. It's a start, but is definitely not ready to land. Some notes:

  • In general, it aims to remove imposed heights for buttons, select fields, and number fields, in favor of min-height. This helps make sure these elements don't break when text is zoomed, but it's likely to cause some visual bugs as well.
  • For instance: min-height for select fields appears to be ignored in Safari. Which isn't great.
  • This patch also includes a quick fix for the checkboxes issue — It replaces the icon-font based checkmark with an SVG one which won't scale up and break. While switching to a SVG seems like a reasonable solution here (to me at least), this implementation could certainly be improved.

With the patch applied, here are the updated screenshots:

https://cldup.com/iL0n4Z9Pyt-3000x3000.png

https://cldup.com/rPnvS54rX1-3000x3000.png

https://cldup.com/BLhjFxyBTv-3000x3000.png

#2 @kjellr
4 months ago

  • Description modified (diff)

#3 @kjellr
4 months ago

  • Summary changed from Open Content overflows and is cut off at 200% text enlarge to Content overflows and is cut off at 200% text enlarge

#4 @SergeyBiryukov
4 months ago

  • Component changed from General to Administration

This ticket was mentioned in Slack in #accessibility by kjell. View the logs.


3 months ago

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


4 weeks ago

@kjellr
4 weeks ago

#7 @kjellr
4 weeks ago

I've updated the patch to remove the checkbox implementation, since that's being handled separately in #47498.

New patch: 47477.2.diff


The main issue I see with the patch currently is that it introduces a regression in the size/alignment of the select fields when viewed without text zoom. For example:

Chrome @ 100%, today:

https://cldup.com/9_nsd4vN6X.png

Chrome @ 100%, with this patch:

https://cldup.com/NQORXIrmxV.png

From some quick research, it doesn't appear that Webkit will respect min-height values on Select fields at all — only height. 😞

(Chrome also seems to remove the box shadows for those filter buttons for some reason, though I expect that's unrelated).


The select fields aren't only problematic in Webkit though: They also don't look right in Firefox:

Firefox @ 100%, today:

https://cldup.com/2sVQw2AV01.png

Firefox @ 100%, with this patch:

https://cldup.com/M26gWoDKbQ.png


Last edited 4 weeks ago by kjellr (previous) (diff)

This ticket was mentioned in Slack in #accessibility by abrightclearweb. View the logs.


3 weeks ago

#9 @joedolson
3 weeks ago

  • Owner set to abrightclearweb
  • Status changed from new to assigned

@kjellr
2 weeks ago

#10 @abrightclearweb
2 weeks ago

I'm trying to test your patches @kjellr but I'm getting errors.

forms.css has 5 failed hunks and buttons.css has 7 failed hunks.

If I try to apply the patches anyway, an src folder is created in my WordPress folder that adds the code, but I don't think that's where I want it, because the paths are wrong.

Can you suggest a fix?

#11 @kjellr
2 weeks ago

I spent some time looking into that select field issue this morning, and it seems like the only way around this would be to use -webkit-appearance: none and add a custom dropdown arrow. I've attached 47477.3.diff, which tries this approach.

This looks consistent in all browsers, and mimics the style of our buttons:

https://cldup.com/qmTYfO-oBe.png

It works well with text zoom. Here's an example at 300%:

https://cldup.com/s6ndRCxmwF.png

I was encountering an issue where our max-width rules for table header select fields were cutting text off horizontally in those fields. Converting those max-widths to rem units instead seemed to solve that, so this patch includes that fix as well.

Note that with this approach, we'll need to sync up any changes here with button updates in #34904. Since this latest update changes the design of the select form fields, I'll add needs design feedback for a gut check from other designers.

Last edited 2 weeks ago by kjellr (previous) (diff)

#12 @kjellr
2 weeks ago

If I try to apply the patches anyway, an src folder is created in my WordPress folder that adds the code, but I don't think that's where I want it, because the paths are wrong.

@abrightclearweb Thanks for trying to test. Are you running the version of WordPress that's located in the develop repository? If so, you should have a /src/ directory already:

https://make.wordpress.org/core/handbook/testing/patch/

#13 @kjellr
2 weeks ago

  • Keywords needs-design-feedback added

#14 @abrightclearweb
2 weeks ago

@kjellr I'm not sure. I have WordPress 5.3-alpha-45933.

I'm trying not to use the command line for testing, it seems to break if I so much as look at it.

Unfortunately there's no content in the Testing Without Grunt section in the [Testing a Patch]https://make.wordpress.org/core/handbook/testing/patch/ doc. :(

I set up a site on DesktopServer using the [Blank (WordPress SVN) method]https://make.wordpress.org/core/handbook/tutorials/installing-a-local-server/desktopserver/#3-configuring-desktopserver.

Then I installed TortoiseSVN and added WordPress [via this method]https://make.wordpress.org/core/handbook/tutorials/installing-wordpress-locally/from-svn/#1-check-out-wordpress-trunk

I had a go at creating my own patch and reverting it. I've applied a few others with success e.g. (https://core.trac.wordpress.org/ticket/47019#comment:10) but I can't get yours to work.

This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.


2 weeks ago

Note: See TracTickets for help on using tickets.