WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 5 days ago

#47498 reviewing defect (bug)

Revise checkbox/radio button css for better compatibility with text zoom

Reported by: kjellr Owned by: audrasjb
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch wpcampus-report form-controls color-contrast
Focuses: ui, accessibility Cc:

Description

Related to #47477. This just breaks out one smaller, manageable piece of the patch for review.


The current implementation of checkboxes in WP-Admin relies on using the Dashicons icon font to render the checkbox. When a user uses a text zoom feature in their browser, this icon is scaled up and misplaced:

200% Text Zoom:
https://cldup.com/0LPkuLI8pX-2000x2000.png

The scaling up does not happen for radio buttons because those rely on pixel sizes and CSS to render the dot at the center of the circle. The radio buttons do call for a bullet symbol from the Dashicons font, but move it out of view using a negative text indent.

To prevent the checkbox issue and clean up our checkbox/radio buttons styles in general, I suggest we take one of two actions:

  1. Switch to SVGs instead of the Dashicons webfont. These won't scale up disproportionally with text zoom, and are altogether a more modern approach. We can use a SVG of the "Yes" Dashicon for the checkmark, but there's no plain circle in Dashicons to use for the radio button. We could either create a circle SVG, or just leave the radio button dot as is, since it's already rendering a circle using CSS and doesn't actually need Dashicons at all to accomplish what it's doing.
  1. Render both the dots and checkmarks using only CSS. The dots are easy: as noted above, they're actually rendering with just CSS today. Checkmarks are a little more complicated, but still not entirely difficult. The downside here is that it won't look exactly like the Dashicon check. Here's a quick example: https://codepen.io/kjellr/pen/NVVNzE

I'm attaching a patch that follows (one variation of) the 1st approach:

  • It uses an SVG instead of the Dashicons webfont for the checkbox checkmark. Since this is used as a pseudo element, the SVG has to be called as an external file, though we could use a data URL if we want to save the browser an extra request.
  • It removes the reliance on the Dashicons webfont for radio buttons. As far as I can tell, this isn't actually used anywhere, since the circle icon is created purely via CSS.

The patch should produce no visible difference when viewed at 100%, but it'll fix the checkbox issue when text zoom is active.

200% Text Zoom:
https://cldup.com/Y9lqcVv2Cx-3000x3000.png

Attachments (3)

47498.diff (1.5 KB) - added by kjellr 3 months ago.
47498-alternate.diff (1.3 KB) - added by kjellr 4 weeks ago.
47498-url-encoded.diff (2.5 KB) - added by afercia 3 weeks ago.

Download all attachments as: .zip

Change History (16)

@kjellr
3 months ago

#1 @afercia
3 months ago

  • Keywords needs-design-feedback added

#2 @afercia
3 months ago

Note about the current CSS used for the radio buttons: \2022 is not a glyph in the dashicons font, it's just the "bullet" unicode character. It appears the related CSS rule in forms.css has always been incorrect.
See https://core.trac.wordpress.org/ticket/47183#comment:2

#3 @afercia
3 months ago

  • Keywords wpcampus-report added

#4 @afercia
3 months ago

  • Keywords form-controls color-contrast added

Previously:

Redesign input fields, checkboxes and other form components for contrast and consistency
https://core.trac.wordpress.org/ticket/44749

Stop using dashicons to show checked state of checkboxes
https://core.trac.wordpress.org/ticket/38150

Color contrast: checkboxes and radio buttons
https://core.trac.wordpress.org/ticket/35596

#5 @afercia
3 months ago

  • Milestone changed from Awaiting Review to 5.3

Moving to the 5.3 milestone, as this ticket aims to address one of the issues from the WPCampus accessibility report on Gutenberg and all the other related tickets are already set to 5.3.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


2 months ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


4 weeks ago

#8 @kjellr
4 weeks ago

Thanks for the background, @afercia.

---

I'm including a second version of the patch that includes the SVG inline, to avoid another browser request. The two patches are:

47498.diff: Uses CSS to draw the bullet in radio buttons, calls a SVG for the checkmark in checkboxes.

47498-alternate.diff: Uses CSS to draw the bullet in radio buttons, uses an inline SVG in the CSS for the checkmark in checkboxes.

Both remove the dependency on Dashicons. I don't have a strong preference for either approach, so happy to hear thoughts from other folks.

Thanks!

#9 @afercia
3 weeks ago

Thanks @kjellr! Tested a bit and:

  • 47498.diff misses a dot in the image URL path, it should be ../
  • 47498-alternate.diff works only in Safari for me:
    • I'm not sure the <rect> element in the SVG is necessary, unless I'm missing something
    • regardless, turns out the checkmark fill value contains the hash character fill='#1e8cbe' and changing that to, for example, fill='red' makes the icon work in all browsers (also IE11).

Solution: URL encode the part that starts with <svg ... > and ends with </svg>, as also suggested here.

That said, both the checkbox checkmark and the radio button "circle" are supposed to change color when an admin alternate color scheme is set. For example, with the "Midnight" color scheme, they should be red:

http://cldup.com/KeLgQcdXYN.png

The fill color should be set dynamically in src/wp-admin/css/colors/_admin.scss but then again the color variable will output a hash character #. There's the need for some Sass to handle this special case.

47498-url-encoded.diff is a proof of concept (it works), if anyone comes up with a better method to replace the hash character # with the URL-encoded value %23, that would be welcomed!

Some testing would be nice :)

#10 @kjellr
3 weeks ago

Excellent improvement, @afercia. Thanks for sorting out the URL encoding. It makes the code a lot less readable, but at least it works this time around. I can confirm that this fixes the color for various color schemes as well. 👍

if anyone comes up with a better method to replace the hash character # with the URL-encoded value %23, that would be welcomed!

I can't think of one offhand  — trimming that off the string like you're doing seems okay. I do think it's worth adding an inline comment above that function to explain what it's for.

Thanks again!

#11 @karmatosed
3 weeks ago

  • Keywords needs-design-feedback removed

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


8 days ago

#13 @audrasjb
5 days ago

  • Owner set to audrasjb
  • Status changed from new to reviewing
Note: See TracTickets for help on using tickets.