La web necesita una nueva especificación

Hay una tensión que ya se siente en casi cualquier proyecto web serio: por un lado, quieres construir interfaces rápidas, accesibles y fáciles de mantener; por el otro, terminas lidiando con una pila de frameworks, convenciones, componentes, reglas de SEO, métricas de rendimiento y detalles de accesibilidad que nadie ordenó de forma clara. El resultado suele ser el mismo: cada equipo resuelve la web a su manera, y la interoperabilidad queda como un ideal más que como una base compartida.

Ahí entra The Website Specification, una propuesta que intenta describir qué debería ser una web moderna desde una perspectiva más formal. No pretende sustituir HTML, CSS o los estándares del W3C. Más bien intenta poner sobre la mesa una idea incómoda pero útil: si la web ya es una plataforma madura, ¿por qué seguimos tratándola como un conjunto de patrones sueltos en vez de como un sistema con reglas explícitas?

Qué intenta resolver esta propuesta

La idea de The Website Specification parte de un problema real: hoy se construyen sitios y aplicaciones web con demasiada complejidad accidental. Puedes tener una landing page simple que termina dependiendo de tres capas de JavaScript, una fuente externa, un sistema de analytics, un CMS, un runtime de componentes y una lógica de hidratación que nadie quiere tocar. Eso no solo afecta velocidad. También complica mantenimiento, accesibilidad y compatibilidad entre navegadores, lectores de pantalla y herramientas automatizadas.

La propuesta no dice que todo deba volver a una web estática de 2005. Dice algo más razonable: si vas a hablar de una web moderna, necesitas un marco que defina qué cosas son esenciales y cuáles son opcionales. En otras palabras, no basta con “funciona en mi navegador”. Necesitas criterios compartidos para saber si una página es legible, navegable, interoperable y usable en distintos contextos.

Eso importa mucho si trabajas en producto. En América Latina, donde todavía conviven conexiones inestables, dispositivos de gama media y flujos de compra muy sensibles al rendimiento, cada decisión técnica se siente más. Una página que pesa 4 MB no es un detalle menor si una parte de tu audiencia navega con planes limitados o en redes móviles irregulares. Una especificación más clara ayuda a discutir prioridades con menos humo y más evidencia.

Qué significa formalizar la web

Formalizar no es burocratizar. Es dejar de depender de intuiciones o de la moda del stack del momento. Cuando una especificación define conceptos como estructura, navegación, estados, contenido y comportamiento esperado, te da un lenguaje común para evaluar implementaciones.

Eso puede sonar abstracto, pero en la práctica sirve para preguntas muy concretas: ¿esta página sigue siendo usable sin JavaScript?, ¿este componente expone su estado de forma accesible?, ¿el contenido principal está disponible sin esperar a que cargue una librería completa?, ¿el sitio se comporta igual en diferentes motores de render?

La ventaja de una propuesta así es que te obliga a separar lo esencial de lo accesorio. Y esa separación es exactamente lo que suele perderse cuando un proyecto crece sin límites claros.

Interoperabilidad: el punto donde la web se rompe

La interoperabilidad es una de esas palabras que se usan mucho y se explican poco. En simple: significa que una cosa funciona de forma consistente en distintos entornos. En la web, eso incluye navegadores, motores de render, dispositivos, lectores de pantalla, proxies, herramientas de automatización y hasta sistemas de indexación.

Cuando la interoperabilidad falla, no siempre lo notas de inmediato. A veces solo ves que un menú no se abre en Safari, que un formulario no anuncia bien sus errores en VoiceOver o que una animación con CSS y JavaScript produce un salto raro en Firefox. A escala de producto, eso se traduce en tickets, abandono y trabajo de soporte que nadie presupuestó.

The Website Specification intenta dar un vocabulario para discutir esas diferencias. No desde el “debería funcionar” genérico, sino desde la definición de comportamientos esperados. Eso es útil porque la web ya no es solo HTML renderizado. Es HTML, CSS, JavaScript, APIs del navegador, carga diferida, estados del lado del servidor y del cliente, y múltiples capas que pueden divergir.

Interoperabilidad no es compatibilidad visual

Un error común es pensar que si algo se ve igual, entonces funciona igual. No siempre. Puedes lograr una interfaz visualmente idéntica y aun así tener problemas de accesibilidad, foco, lectura secuencial o interacción por teclado.

Por ejemplo, un modal puede verse perfecto en pantalla, pero si no atrapa el foco correctamente, un usuario de teclado queda perdido. O un menú desplegable puede abrirse bien con mouse, pero no responder a flechas, Escape o Tab como debería. La especificación intenta poner el foco en el comportamiento, no solo en la apariencia.

Eso cambia la conversación entre diseño, frontend y producto. Ya no se trata solo de “pixel perfect”. Se trata de comportamiento verificable.

Qué gana un equipo con reglas compartidas

Un equipo gana menos ambigüedad. Si defines que un componente debe funcionar con teclado, lector de pantalla y sin depender de una animación para revelar contenido crítico, reduces discusiones tardías y retrabajo.

También mejoras el trabajo entre disciplinas. Diseño puede pensar en estados; desarrollo puede implementar con menos interpretación; QA puede validar casos concretos; y producto puede priorizar mejor. La web se vuelve más predecible, y eso vale más de lo que parece cuando tienes entregas semanales y varios equipos tocando la misma base.

Accesibilidad: no como checklist, sino como requisito base

La accesibilidad suele tratarse como una capa adicional: primero construimos, luego revisamos contrastes, etiquetas y navegación por teclado. Ese enfoque casi siempre llega tarde. Si una propuesta quiere definir la web moderna, la accesibilidad no puede aparecer como nota al pie.

The Website Specification ayuda porque empuja la discusión hacia el comportamiento mínimo esperable. Eso incluye jerarquía semántica, navegación clara, foco visible, estados comprensibles y contenido disponible sin depender de trucos de interacción. En términos prácticos, eso sirve para usuarios con discapacidad, sí, pero también para cualquiera que use la web en condiciones imperfectas.

Piensa en un usuario con pantalla pequeña, mala conexión o un teléfono de gama de entrada. Si tu sitio depende de una interacción compleja, de un hover imposible en móvil o de una carga pesada para mostrar el contenido principal, estás excluyendo a parte de tu audiencia aunque no tengas intención de hacerlo.

Accesibilidad y complejidad técnica

La complejidad técnica suele castigar primero la accesibilidad. Cada capa extra de JavaScript agrega riesgo: foco que se pierde, contenido que tarda en aparecer, estados que no se anuncian, formularios que validan tarde o mal. No es una teoría. Es lo que pasa cuando la interfaz se arma como una simulación de app de escritorio sin cuidar la semántica.

Una especificación más formal puede ayudar a fijar límites. Por ejemplo, si el contenido principal debe estar presente en el HTML inicial, ya no dependes de hidratar toda la página para que sea legible. Si los componentes interactivos deben declarar estados y roles claros, reduces la probabilidad de crear interfaces opacas para tecnologías asistivas.

La documentación oficial de WCAG 2.2 sigue siendo una referencia clave para esto: https://www.w3.org/TR/WCAG22/

Ejemplos concretos de decisiones accesibles

Hay decisiones pequeñas que cambian mucho:

1. Un botón debe ser botón, no un div con click.
2. Un error de formulario debe explicarse en texto, no solo con color rojo.
3. El orden visual y el orden de tabulación no deberían pelearse.
4. El contenido importante debe estar disponible sin depender de hover.
5. Los componentes deben exponer estados como expandido, seleccionado o deshabilitado de forma clara.

Nada de eso es nuevo. Lo nuevo sería tratarlo como parte del contrato base de la web, no como una mejora opcional.

La complejidad actual ya pasó el punto cómodo

La web de hoy tiene una complejidad que hace diez años habría parecido exagerada para muchos sitios. Un proyecto promedio puede incluir SSR, SSG, ISR, hydration parcial, edge rendering, analytics, feature flags, observabilidad, experimentación A/B y múltiples fuentes de contenido. Todo eso puede tener sentido. El problema es cuando se acumula sin una definición clara de qué es esencial.

En ese contexto, The Website Specification funciona como una pregunta incómoda: ¿cuánto de tu stack existe para servir al usuario y cuánto existe para compensar decisiones previas del propio equipo? Esa pregunta importa porque cada capa extra tiene costo en rendimiento, mantenimiento y riesgo de regresión.

No se trata de demonizar frameworks. Next.js, por ejemplo, resuelve problemas reales de enrutado, render y despliegue. Pero incluso con buenas herramientas, el proyecto puede volverse frágil si no tienes criterios claros sobre estructura, contenido y comportamiento. La herramienta no reemplaza la especificación.

Qué puedes medir de verdad

Si quieres discutir complejidad con menos opinión y más datos, hay métricas que sí ayudan:

• Tiempo hasta que el contenido principal es visible.
• Tamaño del JavaScript inicial.
• Número de dependencias críticas para renderizar la primera vista.
• Cantidad de interacciones que requieren hidratación completa.
• Casos de accesibilidad detectados en QA o auditorías.

No hace falta obsesionarse con una sola métrica. Pero sí conviene mirar el conjunto. Un sitio puede tener un Lighthouse decente y aun así ser difícil de navegar con teclado o lento en equipos modestos.

Una tabla simple para pensar el costo

La tabla no pretende dar recetas universales. Sirve para mostrar que cada decisión tiene trade-offs. Una especificación útil ayuda a decidir con más claridad cuáles trade-offs aceptas y cuáles no.

Qué cambia para equipos, producto y contenido

La parte más interesante de una propuesta como esta no está solo en el código. Está en cómo cambia la conversación dentro del equipo. Si defines una base formal para la web, producto deja de pedir “algo parecido a esto” y empieza a pedir comportamientos concretos. Diseño deja de pensar solo en pantallas y empieza a pensar en estados. Desarrollo deja de improvisar patrones que luego nadie puede mantener.

También cambia la relación con contenido y SEO. Si el contenido principal está bien estructurado, los motores de búsqueda lo entienden mejor y los lectores lo consumen con menos fricción. Eso no es un detalle menor en mercados donde la adquisición orgánica sigue siendo clave y donde muchas veces el usuario decide en segundos si se queda o se va.

En equipos latinoamericanos, además, hay una realidad operativa: no siempre tienes el mismo nivel de presupuesto, tiempo o personal que en empresas grandes de Estados Unidos o Europa. Por eso una especificación clara puede ser una ventaja. Te ayuda a recortar discusiones innecesarias y a enfocar el esfuerzo donde sí hace diferencia.

Cómo aterrizar la idea en un equipo real

Si quisieras aplicar esta mentalidad en un proyecto actual, podrías empezar así:

1. Define qué debe funcionar sin JavaScript.
2. Lista los componentes críticos y sus estados accesibles.
3. Mide el peso del cliente inicial antes de agregar nuevas dependencias.
4. Revisa si el contenido principal está en el HTML inicial.
5. Haz auditorías de teclado y lector de pantalla en cada release importante.
6. Documenta decisiones de interoperabilidad para que no dependan de memoria tribal.

Ese tipo de proceso no requiere una gran transformación. Requiere disciplina. Y muchas veces, eso ya cambia bastante la calidad del producto.

Un ejemplo mínimo de contrato técnico

Podrías describir una página con algo tan simple como esto:

<main>
  <article>
    <h1>Título del contenido</h1>
    <p>El contenido principal está disponible desde la primera respuesta del servidor.</p>
    <form aria-label="Contacto">
      <label for="email">Correo</label>
      <input id="email" name="email" type="email" />
      <button type="submit">Enviar</button>
    </form>
  </article>
</main>

No es espectacular. Y justamente por eso funciona como base. La web sigue siendo mejor cuando empieza con estructura clara y comportamiento predecible, no cuando empieza con capas innecesarias de abstracción.

Por qué esta discusión importa ahora

La web no está muriendo. Está cargando demasiado peso, demasiadas expectativas y demasiadas soluciones parciales. Por eso una propuesta como The Website Specification resulta útil: no porque cierre el debate, sino porque lo ordena. Te obliga a hablar de interoperabilidad, accesibilidad y complejidad con un marco más serio que “así lo hace mi framework”.

Si trabajas en producto, frontend, contenido o UX, esta conversación te conviene. No necesitas adoptar una nueva religión tecnológica. Sí necesitas una forma más clara de decidir qué merece vivir en tu web y qué solo está ahí por costumbre.

La documentación oficial de HTML también sigue siendo una referencia directa para entender la base semántica de todo esto: https://html.spec.whatwg.org/

El valor de una especificación no está en sonar elegante. Está en reducir ambigüedad. Y en la web, reducir ambigüedad suele significar mejores experiencias, menos bugs y menos tiempo perdido discutiendo cosas que ya deberían estar resueltas desde el inicio.

Tabla resumen