Partes de un campo

Las piezas con las que están hechos todos los campos de la biblioteca: FieldLabel, FieldHint y FieldError, más la función fieldClasses para la raíz. Sirven para que un campo propio se vea igual que los demás.

Cuándo usarlo

• Cuando ningún campo de la biblioteca encaja y hay que montar uno a mano con un control nativo (<input>, <select>…).
• fieldClasses({ size, variant }) en la raíz, amset-field__control en la caja y amset-field__entry en la entrada: así hereda tamaños, variantes, foco y error.
• required en FieldLabel solo pinta el asterisco; lo que hace obligatorio el campo es el propio control (required o aria-required).

Cuándo no

• Si el campo ya existe: TextField, TextArea, NumberField, SearchField o Select traen las piezas puestas y enlazadas.

Teclado: las piezas no son interactivas; el teclado es el del control al que acompañan.

Accesibilidad: dentro de los campos de la biblioteca, FieldLabel es un <label> enlazado al control (pulsarla lleva el foco al campo) y FieldHint y FieldError se enlazan por aria-describedby. Sueltas se pintan igual, pero no se enlazan solas: en un campo propio, el control tiene que quedar nombrado (dentro de la etiqueta, o con aria-labelledby) y la ayuda y el error enlazados con aria-describedby, poniéndoles un id en un elemento que las envuelva. El asterisco lleva aria-hidden: no entra en el nombre. FieldError solo se pinta cuando recibe el texto en error, con su icono y una transición corta; marcar el control como no válido es cosa del control (aria-invalid). hidden deja la etiqueta solo para el lector de pantalla: nunca para ahorrar sitio.

Aspecto fino: --amset-field-label (letra de la etiqueta) y --amset-field-description (ayuda y error), --amset-field-required-display (con none se esconde el asterisco de obligatorio; el lector lo sigue anunciando), y las clases amset-field__label, amset-field__required, amset-field__hint y amset-field__error.