text input is missing a visible label and an accessible name

[pauljadam]

WCAG requires labels to always be visible and each input needs an accessible name, those can be the same if using a element

[CMTegner]

WCAG requires labels to always be visible

I don't think this is applicable since we don't control the input's label. The consumer can provide both name and id props to the wrapped <input> if needed, as well as adding a label.

[...] each input needs an accessible name, those can be the same if using a element

I don't think I fully grasp what a "accessible name" actually is, but am I right in saying that the content of a <label> becomes a <input>'s accessible name when you link them via id/for? Could you shed some light on this?

[pauljadam]

You can provide a sample text value so the users of the widget know a label is required for a11y. Yes the becomes the accessible name of the input if it's connected to the input using FOR/ID attributes or wrapped labels.

All inputs must have an accessible name or they may read to the screen reader user as "edit text blank" if a text input.

[CMTegner]

You can provide a sample text value so the users of the widget know a label is required for a11y.

As in providing a value for the placeholder attribute?

Just to be clear: Does this a11y issue concern Autocomplete as a reusable component, or with the examples provided in this repo?

[pauljadam]

I looked at the examples and now they have proper connected labels so they've changed since a year ago. This issue is fixed on the currently linked examples. The a11y concern is with both the component and examples.