Contenido que se entiende, formularios que orientan y documentación que alguien puede usar. Un cuaderno en español para construir y cuidar proyectos web.
Una portada puede verse terminada mientras el contenido sigue sin estructura. Para un sitio pequeño, conviene empezar con una hoja y una pregunta: ¿qué cosas distintas vamos a publicar? Una noticia, una persona y una actividad no necesitan exactamente los mismos datos.
Imaginemos una biblioteca comunitaria ficticia. Sus actividades tienen título, fecha, lugar y una descripción. Sus artículos necesitan título, autoría y texto, pero no un horario de asistencia. Si todo se guarda en un gran campo de texto, cada editor deberá recordar el mismo formato. Separar los datos repetidos permite pensar en consistencia antes de elegir colores.
Un modelo mínimo
Dibuja una ficha de actividad y complétala con tres ejemplos inventados: un taller presencial, una charla en línea y una actividad cancelada. El tercer ejemplo es especialmente útil. Obliga a decidir dónde vive el estado de la actividad y cómo se conserva la información anterior sin confundir a quien llega desde un enlace antiguo.
Drupal distingue contenido, configuración, estado y sesión en su guía de tipos de datos. Esa distinción ayuda a no tratar el texto de un artículo, una regla del sitio y un dato temporal como si fueran la misma cosa. El ejercicio de la biblioteca es una propuesta editorial propia, no una receta de configuración para una versión específica.
Cuando las fichas funcionen sobre papel, revisa qué información se repite y cuál debe ser obligatoria. Después podrás decidir cómo implementarla. Un tema visual debería presentar un modelo entendible, no esconder la ausencia de uno.
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.
Esquema propio: la identificación permanece y el error añade información. El color acompaña al mensaje; no lo sustituye.
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.
Por qué importa explicar el resultado
Este video de W3C WAI muestra cómo una respuesta ausente o un error confuso deja a una persona sin saber qué hacer. Complementa el banco de prueba: el aviso debe explicar el problema y ayudar a corregirlo. Es un recurso externo en inglés, no una grabación de nuestro formulario.
Sólo al pulsar el botón se conecta el reproductor con YouTube. Google puede tratar datos de conexión y reproducción. No hay reproducción automática y no necesitas cargar el video para seguir la práctica.
Idea para esta práctica: un aviso útil identifica qué ocurrió y qué paso puede dar la persona. El banco conserva el dato, explica el formato esperado y distingue formato admitido de mensaje enviado. Este resumen es una explicación editorial; la transcripción del video está en la fuente enlazada.
¿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.
