Sobre el Proyecto
Este proyecto desarrolla un formulario interactivo orientado a la validación en cliente, con una separación clara entre estructura, presentación y comportamiento. El objetivo no es solo capturar datos, sino demostrar un enfoque riguroso de arquitectura frontend, accesibilidad y gestión de estados sin depender de frameworks externos.
Qué demuestra este proyecto
Más allá de la validación básica, esta implementación demuestra varios criterios propios de un desarrollo frontend sólido:
- control explícito del ciclo de validación sin delegar la UX al navegador;
- encapsulación del comportamiento en una clase con estado y métodos bien definidos;
- uso de
fieldset,legend,labely atributos ARIA para mantener semántica real; - personalización avanzada de inputs complejos, como fecha y archivo;
- consistencia visual entre estados de campo, fieldset y formulario completo.
Arquitectura de la Solución
La solución se apoya en tres capas que cooperan entre sí pero mantienen responsabilidades bien delimitadas:
HTML semántico como base contractual
El marcado estructura el formulario mediante agrupaciones semánticas reales. Cada fieldset representa una unidad funcional del formulario y cada legend introduce su contexto, lo que mejora tanto la legibilidad del DOM como la navegación asistida.
CSS como sistema de estados visuales
La hoja de estilos no se limita a decorar. Define tokens de diseño, layouts adaptativos, transiciones y estilos de error o éxito que traducen el estado lógico del formulario en una respuesta visual inmediata.
JavaScript como capa de orquestación
La clase ValidacionFormulario centraliza referencias al DOM, expresiones regulares, listeners y validaciones específicas. Esto reduce acoplamiento, evita variables globales dispersas y facilita extender la solución.
Por qué no se usa la validación nativa de HTML5
Se ha optado por desactivar la validación nativa con novalidate para tener control total sobre:
- el momento exacto en que se valida cada campo;
- el contenido de los mensajes de error;
- la aplicación de estilos visuales consistentes;
- la inyección dinámica de atributos de accesibilidad;
- la experiencia de usuario en casos condicionales o compuestos.
Flujo de Validación
El formulario implementa una validación incremental guiada por eventos. Esto evita concentrar toda la lógica en el submit y ofrece feedback contextual desde el primer contacto del usuario con los controles.
Validaciones específicas implementadas
- campos de texto restringidos a letras y espacios, incluyendo caracteres acentuados;
- comprobación de formato de email y confirmación entre correo principal y repetición;
- límites de edad mínima y máxima;
- validación de fecha y URL opcional;
- obligación de seleccionar al menos un sistema operativo;
- activación condicional del bloque de radios para la opción de ciberseguridad;
- control del archivo adjunto y actualización visual del nombre seleccionado.
Decisiones de Accesibilidad y UX
La experiencia de usuario está planteada para ser clara, progresiva y compatible con navegación por teclado o asistencia tecnológica.
tabindex, respeta el flujo natural del DOM y utiliza atributos como aria-invalid, aria-describedby y role="alert" únicamente cuando el contexto lo requiere. Esto reduce ruido semántico y mejora la precisión del feedback para lectores de pantalla.Análisis por Archivo
-
-
- index.html - Estructura semántica del formulario y definición de sus grupos funcionales.
- styles.css - Sistema visual, layouts, transiciones y estados de validación.
- app.js - Orquestación de eventos, reglas de validación y sincronización del estado global.
-
fieldset segmentan el flujo en bloques comprensibles y los small.error-msg actúan como puntos de inserción para mensajes controlados por JavaScript, evitando mezclar presentación y lógica en el marcado.Valor Técnico del Proyecto
Este trabajo resulta especialmente sólido porque combina varias buenas prácticas reales de frontend en una misma pieza:
- diseño semántico y accesible del formulario;
- control explícito del estado sin librerías;
- separación clara de responsabilidades;
- validación incremental con foco en experiencia de usuario;
- base suficientemente modular como para evolucionar a componentes más complejos.
Posibles evoluciones futuras
Si el proyecto siguiera creciendo, tendría sentido incorporar:
- un esquema declarativo para reglas y mensajes de validación;
- internacionalización de labels y errores;
- tests de interfaz para cubrir flujos de validación;
- persistencia temporal del estado del formulario;
- extracción de componentes reutilizables para otros formularios del portafolio.