Govuk-frontend: Form elements do not scale well if only font size increased

Created on 1 Aug 2019 · 11Comments · Source: alphagov/govuk-frontend

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.

Screen Shot 2019-08-01 at 14 30 10

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:

Screen Shot 2019-08-01 at 14 31 28

🐛 bug accessibility ⚠️ high priority 🕔 days accessibility-regulations-failure

Source

andysellick

All 11 comments

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?

andysellick on 2 Aug 2019

There seems to be some concern to nested font sizing: https://github.com/alphagov/govuk-frontend/commit/5f4d20c2ef9549c0e4596239f77067e0462ff89a

But perhaps rem would be fine?

nickcolley on 2 Aug 2019

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 on 2 Aug 2019

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.

andysellick on 2 Aug 2019

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 on 2 Aug 2019

👍1

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

nickcolley on 2 Aug 2019

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

Screen Shot 2019-08-07 at 16 02 06

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…'.

36degrees on 7 Aug 2019

👍1

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

Screen Shot 2019-09-12 at 14 57 32

Chrome when text resized to 48

Screen Shot 2019-09-12 at 14 58 15

Safari when text resized to 200%

Screen Shot 2019-09-12 at 14 59 36

Firefox when text resized to 200%

Screen Shot 2019-09-12 at 16 24 03

IE11 when text resized to Largest

Screen Shot 2019-09-12 at 16 29 36

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.