Form elements do not scale well if only font size increased

[andysellick]

If you zoom text only in Firefox, select elements retain their 40px height but the text within them becomes larger and therefore cropped from the bottom edge.

Doesn't seem to be as much of a problem for text inputs.

Can't reproduce the problem in Chrome because the zoom text only option isn't available.

Noticed this during user testing on a phone of GOV.UK's search, specifically where we have select elements in finders.

(can't remember what kind but possibly an iPhone 7?)

Side note: doing this on the Design System site causes the currently active menu item to be crossed out instead of underlined:

[andysellick]

This appears to be fixable by changing the height from using px to em but I think we already discussed this and there was a reason not to do it? Can someone remind me?

[NickColley]

There seems to be some concern to nested font sizing: 5f4d20c

But perhaps rem would be fine?

[andysellick]

Interestingly on testing it seems rem is far less predictable than em. rem in the component guide produces one height but inside finder-frontend's search gives a much smaller height (actually creating the original issue in a different way). em produces a consistent height in both interfaces.

[andysellick]

Looks like the reason for that is the body font size isn't set in the component guide (?) - we might need to look into that.

[NickColley]

The main issue with 'em' and 'rem' when using it with the legacy GOV.UK Template is that GOV.UK Template messes with the root font size, which is likely what you're seeing.

[NickColley]

We do have ways to only use relative units when compatibility mode is not turned on that we could consider.

[36degrees]

It looks like this can affect text inputs, but only at extreme values (I had to modify the values for toolkit.zoomManager.zoomValues and zoom.maxPercent in Firefox's about:config to do this):

We'd probably also want to scale text inputs and buttons at the same time to ensure that they remain aligned – so I'm going to rename this to 'form inputs do not scale well…'.

[hannalaakso]

I did some investigation...

Requirement

WCAG 2.1 requires that user can resize text to at least 200% .

Inputs

Current behaviour

Chrome when text resized to 32 (16 x 2 = 200%)

Chrome when text resized to 48

Safari when text resized to 200%

Firefox when text resized to 200%

IE11 when text resized to Largest

Problem

We set the height of inputs with

height: 40px

which constraints them from expanding beyond that when text is resized.

Recommendation to fix

Swap the height property in text inputs to use min-height. This is to enable the element to expand when text size is increased. I tested setting min-height: 40px and saw no difference in supported browsers, apart from IE8 in which setting min-height makes the inputs taller than required; I haven't dug into this more but I think we could safely remove height from IE8, and wrap min-height in a conditional block which excludes IE8.

Selects

Current behaviour

Chrome when text resized to 32 (16 x 2 = 200%)

Chrome when text resized to 48

Safari when text resized to 200%

Firefox when text resized to 200%

IE11 when text resized to Largest

Problem

Again, we set the height of inputs with

height: 40px

which stops them from expanding beyond that when text is resized.

Recommendation to fix

This is a tricky one because setting min-height doesn't do anything on <select> elements. If we remove height, it allows the element to expand with the text size but the reduced height when using standard 16pt font is particularly noticeable in Chrome and Safari when compared against the current version of the element. Needs further discussion.

File inputs

Current behaviour

Chrome when text resized to 32 (16 x 2 = 200%)

Safari when text resized to 200%

Problem

This seems like a vendor issue with Chrome and Safari as the unstyled element has the same issue with overlapping text on larger font sizes.

px vs rem and compatibility mode

Chrome and IE fail to resize text when it's set in px. Our compatibility mode sets all font sizes in px to play nice with GOV.UK Template which only uses px sizing and sets global styles on <html>. We should maybe flag this about the compatibility mode and WCAG 2.1 requirement to resize text.

Other elements

I picked up on some related issues, raised here:
#1568
#1569

Reference: How text was resized in browsers

Chrome

Settings > Appearance > Customise fonts

Firefox

Set View > Zoom > Zoom text only. Press +/-
or Preferences > Language and appearance > Font size

Safari

To increase the font size, press Option-Command-Plus sign (+)
To decrease the font size, press Option-Command-Minus sign (-)

Edge

Can't resize text apart from "Reading view" which removes form elements from the view.

IE 8-11

Page > Text size > Largest

iOS

Text can't resized in browser. See #882

Android Chrome/Firefox

Settings > Accessibility > Text scaling

[NickColley]

@hannalaakso nice investigation, did you explore what happens if you use height with relative units? For example height: Nrem.

[andysellick]

@hannalaakso excellent investigation. I did a fix for our select component on GOV.UK for this issue where height: 2.14em; (equivalent to 40px) worked.

[NickColley]

@andysellick I think we'd need to avoid using em units as it is unpredictable depending on what their parent's font size, so we'd want to explore rem (but only outside compatibility mode).