[Bug]: Native RadioTile validation sub-optimal

[brunnerh]

Package

carbon-components, carbon-components-react

Browser

Chrome

Package version

v10.50.0

React version

v7.50.0

Description

Currently there are two issues when making a RadioTile selection required with native form validation:

• The required attribute has to be specified on every RadioTile (in React at least) instead of on the TileGroup
• The invisible underlying input is not positioned correctly to display validation errors at a suitable location.

The radio should probably be at the bottom middle of the tile or the group as a whole like this:

Additions for this example:

.bx--tile-group { position: relative }
.bx--tile-input {
  bottom: 0;
  left: 50%;
}

CodeSandbox example

https://codesandbox.io/p/sandbox/required-tile-group-q33x2q

import React from "react";
import { render } from "react-dom";
import { Button, Form, TileGroup, RadioTile } from "carbon-components-react";

function onSubmit(e) {
  e.preventDefault();
  alert("submitted");
}

const App = () => (
  <div style={{ padding: "2em" }}>
    <Form onSubmit={onSubmit}>
      <TileGroup name="radio">
        <RadioTile required>Tile 1</RadioTile>
        <RadioTile required>Tile 2</RadioTile>
        <RadioTile required>Tile 3</RadioTile>
      </TileGroup>
      <Button type="submit">Submit</Button>
    </Form>
  </div>
);

render(<App />, document.getElementById("root"));

Steps to reproduce

• Add TileGroup with required RadioTiles to a form.
• Submit form without selecting any of the tiles.

Code of Conduct

• I agree to follow this project's Code of Conduct
• I checked the current issues for duplicate problems

[brunnerh]

As I found out, validation messages can also be top-aligned (Safari). So if this is implemented, that should be taken into consideration.

[tay1orjones]

The invisible underlying input is not positioned correctly to display validation errors at a suitable location.

I think this part has been fixed, the other issue though remains to my knowledge

[2nikhiltom]

Hey @brunnerh

The invisible underlying input is not positioned correctly to display validation errors at a suitable location.

Above issue has been fixed by PR

I can't reproduce the other issue, and I didn't encounter any errors popup in the CodeSandbox link provided with the bug report.

Also, based on the screenshots provided in the bug(Attached above this as well), it seems that the observed behavior is related to RadioButtonGroup and RadioButton, rather than TileGroup and RadioTile.
i.e
CodeSandbox-Link

<FormGroup>
        <RadioButtonGroup name="group" legendText="Storage tier (disk)">
          <RadioButton required labelText="Free (1 GB)" value="free" />
          <RadioButton required labelText="Standard (10 GB)" value="standard" />
          <RadioButton required labelText="Pro (128 GB)" value="pro" />
        </RadioButtonGroup>
</FormGroup>

Could you confirm this or further help with a CodeSandbox that reproduces this issue with TileGroup and RadioTile. Thanks :)

[brunnerh]

This is about TileGroup, and the problem still exists (at least in v10).
The sandbox broke due to not linking to a fixed version of the packages.

I updated the link.

[brunnerh]

In v11, native validation is completely broken in the React package, because required is not set/forwarded.

carbon/packages/react/src/components/RadioTile/RadioTile.tsx

Lines 144 to 156 in 0376df7

	<input
	checked={checked}
	className={`${prefix}--tile-input`}
	disabled={disabled}
	id={inputId}
	name={name}
	onChange={!disabled ? handleOnChange : undefined}
	onKeyDown={!disabled ? handleOnKeyDown : undefined}
	tabIndex={!disabled ? tabIndex : undefined}
	type="radio"
	value={value}
	ref={ref}
	/>

StackBlitz

[2nikhiltom]

Hey @brunnerh Thanks for quick response, we are looking into this.

[brunnerh]

@2nikhiltom
This issue is not fully fixed.
The positioning of the validation message is still not so great, in some browsers it completely obscures the tile contents.

[2nikhiltom]

@brunnerh
This majorly added support for required in RadioTile
For positioning in other browsers could you reproduce the issue in a stackblitz and open a new bug to track ?