designsystemet icon indicating copy to clipboard operation
designsystemet copied to clipboard

Larger touch area on checkbox and radio inputs

Open Febakke opened this issue 4 months ago • 5 comments

Should we increase the touch area of checkboxes and radio inputs?

As of today our inputs have a 24x24 toucharea. The question is if we should create an invisible area that is counted as the touch area.

We need to look at

  • WCAG, what are the revelant requirements we need to look at
  • Design: How would this work in practice? Do we need more space between elements? Avoid overlap
  • Technical, what are up and downsides of different technical solutions if we decide

WCAG

There are at this moment not any WCAG requirements that are required by Norwegian law. But there are some guidelines.

Target size (enhanced) This requires that all touch areas are at least 44x44.

Target size (minimum) This is newer requirement that I think will be a part of the norwegian requirements at a future date. This is set as 24x24

Design

Technical

Febakke avatar Aug 29 '25 10:08 Febakke

Some quick notes: <label> is also touchable, and could maybe be considered in the touch area? We can't use pseudo elements (::before, ::after) since these are not supported in <input>

Barsnes avatar Aug 29 '25 11:08 Barsnes

Perhaps hard to avoid needing a wrapper. Here is how we made checkbox in equinor with 48x48 physical area, 24x24 visible area and 40x40 hover circle area https://storybook.eds.equinor.com/?path=/docs/inputs-selection-controls-checkbox--docs (inpect element to get the idea)

oddvernes avatar Aug 29 '25 13:08 oddvernes

Perhaps hard to avoid needing a wrapper. Here is how we made checkbox in equinor with 48x48 physical area, 24x24 visible area and 40x40 hover circle area https://storybook.eds.equinor.com/?path=/docs/inputs-selection-controls-checkbox--docs (inpect element to get the idea)

Thanks. Ideally we would like to solve this without wrappers, since using DS without React will become a bit more cumbersome. A good documentation could solve this, but at the time of writing we don't have a specific HTML/CSS doc.

Changing the DOM structure would also be considered a breaking change, unless we also support the old structure

Barsnes avatar Sep 01 '25 07:09 Barsnes

Yes agreed, no changes to dom should be done on inputs

oddvernes avatar Sep 01 '25 07:09 oddvernes

We need to make a decision here.

mrosvik avatar Oct 31 '25 11:10 mrosvik