CUADERNO / Contenido y estructura
La etiqueta del formulario debe seguir ahí al escribir
Escribe unas letras dentro de un campo que sólo dice «Tu correo» como texto provisional. La pista desaparece. Ahora imagina que vuelves para corregir un error: el dato sigue ahí, pero la explicación que lo identificaba ya no está. Podemos revisar este pequeño problema sin construir primero un sistema completo de mensajes.
En esta práctica trabajaremos con un control de ejemplo. No se envía ni se guarda su contenido. El objetivo es observar cuatro cosas: el nombre del campo, su relación con la etiqueta, la explicación de un error y el recorrido con el teclado. No es una certificación de accesibilidad.
¿Qué nombre debe permanecer visible?
La etiqueta describe para qué sirve el control. La guía de etiquetas de W3C WAI explica cómo asociarla de manera explícita: el atributo for de label coincide exactamente con el id del campo. La referencia de MDN para label documenta también esa relación.
<label for="correo-demo">Correo de ejemplo</label>
<input id="correo-demo" type="email">En nuestro ejemplo, «Correo de ejemplo» permanece fuera del recuadro, incluso cuando hay texto dentro. La coincidencia del nombre no basta: correo-demo debe ser el mismo identificador en ambos atributos y no repetirse en otro control de la página. Al activar la etiqueta, comprueba que el foco llega al campo correspondiente.
¿Para qué dejamos entonces el texto provisional?
Podemos usarlo como una pista breve del formato, sin encargarle toda la identificación. Prueba el campo de abajo primero vacío y después con unas letras. La etiqueta exterior y la instrucción continúan visibles; el ejemplo dentro del campo puede desaparecer sin llevarse el significado.
Para este ejercicio el dato es obligatorio, aunque un formulario real podría hacerlo opcional. Esa decisión debe venir de la tarea, no de copiar nuestro ejemplo. Usamos una dirección ficticia sólo para explorar el formato; no compruebes tu correo personal aquí.
Banco de prueba: una etiqueta y un error
Usa un dato ficticio. Prueba «sin-arroba» y luego «persona@example.com». Esta práctica no envía mensajes.
La comprobación se activa con JavaScript. La etiqueta y las instrucciones pueden leerse sin él.
¿Qué debería decir el error?
El ejemplo identifica el campo y sugiere cómo corregirlo. Si está vacío, indica que falta el correo de ejemplo. Si escribes «sin-arroba», explica que el control espera una dirección con formato de correo. Conserva el texto para que puedas corregirlo; no te obliga a reconstruir todo el dato.
W3C WAI recomienda avisos claros y orientados a resolver el problema. Su guía de notificaciones muestra cómo vincular una explicación mediante aria-describedby y cómo dirigir el foco al primer campo con error. Nuestro banco aplica estas ideas a un único control; un formulario más largo necesita revisar también el conjunto de errores y el orden de navegación.
El resultado favorable también necesita un límite. El banco sólo dice que el navegador admite el formato del control. No demuestra que exista el buzón ni que pueda recibir un mensaje. Tampoco hay aquí una entrega de correo que podamos declarar exitosa.
Leer los cuatro estados del video
- El nombre del control permanece fuera del recuadro. Dentro hay una pista provisional.
- Al escribir «sin-arroba», desaparece la pista, pero la etiqueta sigue visible.
- El error explica el formato esperado y conserva el dato. El color acompaña al texto.
- Con «persona@example.com», el control admite el formato. No prueba que exista el buzón ni envía un mensaje.
¿Cómo hacemos una revisión pequeña y repetible?
- Activa la etiqueta y comprueba qué campo recibe el foco.
- Deja el dato vacío y activa «Comprobar formato» con el teclado. Lee el aviso.
- Escribe «sin-arroba», vuelve al botón con Tab y actívalo. Revisa que el dato permanezca y que el error sea concreto.
- Sustituye el ejemplo por «persona@example.com». Comprueba que el aviso ya no afirme un error de formato, sin prometer entrega.
- Vacía el ejemplo y vuelve a recorrer los controles. Comprueba que la etiqueta no desaparezca en ninguno de los estados.
Anota el navegador, el tamaño de pantalla y qué acción no produjo el resultado esperado. No cambies «lo probé con Tab» por «funciona con todas las tecnologías de apoyo». Si algo falla, un reporte reproducible permite describir el caso sin adjuntar datos privados.
¿Qué queda fuera de esta demostración?
Un formulario real necesita validación del lado del servidor, tratamiento seguro de los datos y una respuesta que corresponda a lo ocurrido. Nuestro ejemplo no incluye esas operaciones. Tampoco prueba un lector de pantalla, todos los navegadores o una tarea completa con personas usuarias.
La mejora que sí podemos observar es pequeña y concreta: el campo conserva un nombre visible, la etiqueta se relaciona con él y la explicación del error no borra el dato. Guarda ese caso de prueba junto con las tareas de entrega del sitio, para que otra persona pueda repetirlo cuando cambie el diseño. Fuentes revisadas el 15 de octubre de 2026.