Antes están la primera parte, sobre arquitectura, y la segunda, sobre privacidad y normativa.
Liquid no lanza errores: devuelve vacío. El lenguaje de plantillas de Jekyll, ante un dato mal escrito, no se queja: devuelve nada. El resultado es un enlace con destino vacío, o un rótulo en blanco. La página se genera, se publica y está rota. Descubrí que un identificador entre comillas y sin comillas se comportaban distinto —sin comillas, lo trataba como una variable inexistente— viendo desaparecer una ilustración sin explicación alguna.
YAML distingue mayúsculas. Escribí jobtitle en un archivo de datos y jobTitle en la plantilla. El resultado fue un dato nulo en los datos estructurados de la página. JSON perfectamente válido, dato perdido, cero avisos.
El filtro que se calculaba y no se usaba. En el listado del blog, el filtro por perfil se guardaba correctamente en una variable… y el bucle seguía recorriendo la colección completa. El blog de IT mostraba también los artículos de Administración. Lo peor: estaba camuflado, porque el perfil que no tenía artículos sí mostraba el mensaje de «aún no hay nada» y los demás «mostraban artículos». Todo parecía funcionar.
Lección de método: comprobar qué sale, no solo si sale.
El enlace de salto sin estilos. El sitio tenía desde el primer día un enlace «Saltar al contenido» para quien navega con teclado. El marcado estaba… y nunca tuvo CSS. Llevaba semanas apareciendo como un texto suelto en la esquina de todas las páginas y yo lo leía sin verlo.
El foco que no se movía. Y cuando por fin le puse estilos, seguía sin funcionar bien: al pulsarlo, la página bajaba hasta el contenido pero el foco del teclado se quedaba arriba. El siguiente tabulador te devolvía a la cabecera. Parecía que funcionaba. La cura fue permitir que el elemento principal pudiera recibir el foco por programa.
Este último merece explicación, porque es el ejemplo perfecto de por qué existe:
flowchart LR
accTitle: Recorrido del teclado con y sin enlace de salto al contenido
accDescr {
Sin enlace de salto, quien navega con teclado debe pulsar el tabulador unas doce veces
para atravesar toda la cabecera antes de llegar al contenido, y debe hacerlo en cada
página que visita. Con el enlace de salto, la primera pulsación del tabulador ofrece
ir directamente al contenido con una segunda pulsación.
}
subgraph SIN["Sin enlace de salto"]
direction LR
A1["Tabulador 1"] --> A2["..."] --> A3["Tabulador 12"] --> A4["Contenido"]
end
subgraph CON["Con enlace de salto"]
direction LR
B1["Tabulador 1:<br/>Saltar al contenido"] --> B2["Contenido"]
end
La cabecera tiene unos doce enlaces. Sin enlace de salto, alguien que navega con teclado los atraviesa en cada página que visita. Es el criterio 2.4.1 de las pautas de accesibilidad, y es nivel A: el mínimo.
El estilo tiene su gracia técnica. Un solo anillo de foco falla siempre contra algún fondo, y aquí hay ocho paletas. La solución fue un doble anillo concéntrico: un contorno claro y una sombra oscura alrededor. El contorno se pinta por encima de la sombra, así que uno de los dos contrasta contra cualquier fondo posible. Y va por encima de la cabecera fija, lo que cubre además el criterio 2.4.11, «Foco no oscurecido», nuevo en la versión 2.2.
El objetivo era WCAG 2.2, nivel AA. La parte automatizada la hice con axe DevTools sobre el sitio ya publicado: veinte informes, con las ocho paletas cubiertas y la batería completa de pruebas guiadas —teclado, formularios, estructura, imágenes, tablas, diálogos, elementos interactivos—. Resultado final: cero incidencias.
Lo que hubo que corregir por el camino:
| Hallazgo | Solución |
|---|---|
| Faltaba el encabezado principal en tres perfiles y en contacto | Añadido en las versiones de los dos idiomas |
| Campos obligatorios sin marcar explícitamente para tecnologías de apoyo | Declarados de forma explícita |
| Enlace de salto sin indicador de foco (crítico) | El doble anillo de arriba |
Pero conviene decir una cosa que se calla mucho: las herramientas automáticas detectan alrededor de un tercio de los problemas reales. El resto lo tiene que ver una persona. Eso significó:
Y un criterio que ninguna herramienta del mundo puede comprobar: el 3.1.2, «Idioma de las partes». Cuando en el texto en inglés dejo una expresión en español sin traducir, hay que marcarla como tal, o el lector de pantalla la pronunciará con las reglas del idioma equivocado y la línea braille aplicará contracciones que no tocan. Ninguna máquina sabe que una frase sin marcar está en otro idioma. Eso solo lo ve alguien leyendo. Es el trabajo que queda pendiente, y por eso el compromiso de accesibilidad de este sitio todavía no está publicado: prefiero escribirlo cuando pueda decir exactamente qué he medido.
Movimiento reducido. El sitio respeta la preferencia del sistema de reducir animaciones. El detalle está en cómo: la duración se pone en una centésima de milisegundo, no en cero. Con cero, algunas animaciones no llegan a dispararse, y un guion que espere el aviso de «animación terminada» se queda esperando para siempre. Además es de los pocos sitios donde marcar una regla como prioritaria está justificado: implementa la voluntad del usuario, no la del desarrollador.
El cliente nunca es frontera de seguridad. El límite de caracteres, los campos obligatorios y el contador del formulario son comodidad, no defensa. Quien puede editar el HTML puede editar el JavaScript. La defensa real está siempre en el servidor.
El constructor nativo de GitHub Pages no me servía: está fijado a una versión de Jekyll muy anterior y no admite ni el complemento de bilingüismo ni el Sass moderno. No fue una preferencia, fue una obligación: hacía falta un flujo de trabajo propio.
flowchart LR
accTitle: Proceso de publicación automática del sitio
accDescr {
Al enviar los cambios a la rama principal del repositorio, GitHub Actions arranca un
proceso que prepara Ruby e instala las dependencias, construye el sitio en modo
producción, empaqueta el resultado y lo despliega en GitHub Pages, que lo sirve bajo
el dominio propio.
}
A["Envío a la rama principal"] --> B["GitHub Actions"]
B --> C["Ruby 3.3<br/>e instalación de dependencias"]
C --> D["Construcción<br/>en modo producción"]
D --> E["Empaquetado del sitio"]
E --> F["Despliegue en GitHub Pages"]
F --> G["carloslb.com"]
Tres cosas que aprendí ahí:
Dirección y subcarpeta no son lo mismo. Una clave es protocolo más dominio; la otra es la subcarpeta dentro del dominio, y solo lleva valor si el sitio no vive en la raíz. Poner el dominio en la segunda duplicaría el dominio en cada enlace generado y rompería absolutamente todo. Antes de publicar, esa clave apuntaba a la IP privada de mi máquina virtual: de haberlo dejado así, el mapa del sitio y las direcciones canónicas se habrían publicado apuntando a una dirección de mi red local.
Los fallos intermitentes son los peores. El complemento de bilingüismo tiene una condición de carrera documentada en los servidores de integración: un proceso escribe en un directorio de idioma que otro aún no ha creado. Falla a veces. Se desactiva la paralelización y se acabó.
El último escollo fue tonto y muy instructivo. El envío se rechazaba por el correo del commit. Había corregido la configuración de Git, pero la configuración solo afecta a los commits futuros: el que ya estaba hecho conservaba el autor antiguo. Se resuelve reescribiendo la autoría del commit pendiente, algo inofensivo mientras no se haya subido nada.
Ese último merece cerrar la serie, porque enlaza con lo que conté en la primera parte sobre trabajar con un asistente de IA. Se equivocó tres veces de la misma manera: afirmando con seguridad algo deducido de una fuente incompleta —un listado de archivos truncado, una copia desactualizada del proyecto, un nombre de fichero cortado por longitud—. En una de ellas llegó a corregirme cuando yo tenía razón.
Las tres las cacé porque conocía mi propio proyecto y porque algo no me cuadraba. Y esa es exactamente la misma lección que el resto del artículo: una respuesta segura y falsa es también un fallo silencioso. No da error. Suena bien. Y hay que comprobarla igual que se comprueba un bucle que «muestra artículos».
Sea quien sea quien te dé una respuesta, la fuente se mira.
El código de todo esto está en github.com/carloslb-com/carloslb-com.github.io. Si algo de aquí te sirve, te lo llevas. Y si encuentras una barrera de accesibilidad en el sitio, escríbeme: me interesa más saberlo que tener razón.
]]>En la primera parte conté la arquitectura. Aquí toca lo que no se ve.
Iba a escribir artículos con diagramas, así que monté Mermaid. Funcionaba a la primera: una línea apuntando a una red de distribución pública y listo.
El problema lo vi al releer la política de cookies que acababa de escribir. Aquella línea estaba en la plantilla base, es decir, en todas las páginas del sitio. Cada visitante, entrara donde entrara, le estaba entregando su dirección IP a una empresa ajena para cargar una biblioteca que solo hacía falta en los artículos con diagrama. Es decir: cero. Estaba declarando una cosa y haciendo otra.
Autoalojarlo costó más de lo que parecía:
import en un guion que no está declarado como módulo lanza un error de sintaxis que mata el guion entero. No falla esa línea: no se ejecuta nada.Ahora la biblioteca vive en el propio sitio y se carga solo en las páginas que declaran tener un diagrama. Con las fórmulas matemáticas hice lo mismo, con una trampa añadida: en la versión actual, las fuentes tipográficas no vienen en el paquete y el cargador apunta por defecto a una red externa. Si no lo sobrescribes, has autoalojado el motor y sigues llamando fuera.
El resultado: este sitio no carga ni un solo recurso de un tercero. Tipografías, iconos, motores de diagramas y de fórmulas: todo servido desde aquí.
No hay cookies. Ni analítica, ni publicidad, ni sesión. Por tanto no hay banner de consentimiento, porque no habría nada que consentir.
Lo único que se guarda en tu navegador es tu preferencia de tema, claro u oscuro, en almacenamiento local. Según la guía sobre cookies de la Agencia Española de Protección de Datos, ese uso es almacenamiento técnico de personalización a petición del usuario, y está exento de consentimiento. La diferencia no es el mecanismo: es para qué se usa.
Un sitio estático no puede procesar un formulario. Necesitas un tercero. Comparé catorce servicios con tres criterios: que los datos se traten en la Unión Europea, que haya un contrato de encargado de tratamiento de verdad, y que la capa gratuita sirva para algo.
sequenceDiagram
accTitle: Recorrido de un mensaje enviado desde el formulario de contacto
accDescr {
El visitante rellena el formulario en el sitio y lo envía mediante una petición HTTP
normal, sin que el sitio necesite JavaScript propio. El proveedor, con servidores en
Alemania, aplica su filtro antispam y el campo trampa, y responde con una página propia
de verificación. Allí el navegador resuelve por su cuenta un desafío criptográfico y a
la persona solo se le pide confirmar con un clic. Después el proveedor entrega el
mensaje al buzón de correo y redirige al visitante a la página de agradecimiento.
}
participant V as Visitante
participant W as carloslb.com
participant F as Proveedor (Alemania)
participant M as Buzón de correo
V->>W: rellena y envía el formulario
W->>F: petición HTTP normal, sin JavaScript propio
F->>F: filtro antispam y campo trampa
F-->>V: página propia de verificación
Note over V,F: El navegador resuelve el desafío.<br />A la persona solo se le pide un clic
V->>F: confirma con un clic
F->>M: entrega el mensaje
F-->>V: redirige a la página de agradecimiento
Note over V,F: Ningún recurso del proveedor se incrusta en el sitio
Ese detalle del captcha es la clave: se sirve en la página del proveedor, después de pulsar enviar. En mi sitio no se incrusta nada suyo, y el formulario se envía con HTML puro, sin JavaScript propio.
Y el tipo de captcha importa tanto como dónde vive. Aquí no hay que descifrar texto deformado ni señalar semáforos: el navegador resuelve por su cuenta un desafío criptográfico y a la persona solo se le pide confirmar con un clic. Eso no es solo comodidad, es accesibilidad. Los captchas de imagen son una barrera conocida para quien tiene baja visión o navega con lector de pantalla; al hacer el trabajo el dispositivo en vez de la persona, no queda ninguna prueba visual ni de audio que superar.
Descarté un competidor por tener el tratamiento en Estados Unidos y usar cookies, y otro —libre y muy elegante— porque exigía un servidor propio que no tengo.
Dos decisiones más sobre el formulario:
Minimización de datos. Nombre, correo, asunto y mensaje. Nada de teléfono ni de actividad económica. Si no lo necesito para responderte, no te lo pido. Es lo que exige el reglamento, pero además es de sentido común: los datos que no tienes no se te pueden filtrar.
Bloquear el botón de enviar hasta que el formulario sea válido: descartado por accesibilidad. Es un patrón muy extendido y es malo. Un botón deshabilitado no explica por qué lo está, y como no recibe el foco del teclado, un lector de pantalla ni siquiera lo anuncia. La persona se queda delante de un formulario que no responde y sin ninguna pista. La validación nativa del navegador ya avisa y lleva el foco al campo problemático. Menos código y más accesible.
Aquí entra mi otro oficio. Antes de copiar una plantilla legal, hice el análisis de qué me obliga y qué no. Esta es mi lectura de mi propio caso, no asesoramiento jurídico: si tu situación es otra, el resultado cambia.
flowchart TD
accTitle: Qué normativa aplica a una web personal sin actividad económica
accDescr {
Cuatro comprobaciones. El Real Decreto 1112 de 2018 sobre accesibilidad solo alcanza
al sector público, así que no aplica. La Ley 11 de 2023 no aplica al no haber comercio
electrónico. La LSSI-CE no aplica al no haber actividad económica, de modo que ni el
aviso legal ni la política de cookies son obligatorios. En cambio, el Reglamento General
de Protección de Datos sí aplica, porque el formulario de contacto recoge datos
personales: la política de privacidad es obligatoria.
}
A["¿Es un sitio del sector público?"] -->|No| A2["RD 1112/2018: no aplica"]
B["¿Hay comercio electrónico?"] -->|No| B2["Ley 11/2023: no aplica"]
C["¿Hay actividad económica?"] -->|No| C2["LSSI-CE: no aplica<br/>Aviso legal y política de cookies<br/>no son obligatorios"]
D["¿Se recogen datos personales?"] -->|"Sí: el formulario"| D2["RGPD: sí aplica<br/>Política de privacidad obligatoria"]
Resultado: de los cuatro documentos que todo el mundo copia, solo uno era exigible. Mantengo los otros por criterio propio —prefiero pecar de exceso—, pero con una regla:
Conservar el documento no es lo mismo que conservar la ficción.
Las plantillas legales vienen infladas. La que descargué declaraba tratamientos con fines comerciales, estadísticos y de análisis de navegación. Nada de eso existe aquí. Y declarar un tratamiento inexistente hace daño dos veces: desinforma a quien lee, y te compromete con bases jurídicas que no tienes. Así que podé todo lo que no era verdad.
Lo mismo con los datos que publico de mí: nombre y correo. Sin DNI, sin domicilio, sin teléfono. La plantilla los pedía; la ley, en mi caso, no. Por coherencia, los commits del repositorio van con la dirección de reenvío anónimo de GitHub, y en los datos estructurados de las páginas no hay correo electrónico: los recolectores de direcciones rastrean precisamente ahí.
Puedes leer el resultado en la política de privacidad y en la política de cookies. Esta última la reescribí entera desde cero, porque una plantilla que empieza explicando qué cookies usa no sirve para decir que no usas ninguna.
Siguiente: en la tercera parte, lo que casi rompe el sitio sin dar ni un error, cómo se audita la accesibilidad de verdad, y por qué el constructor de GitHub Pages no me servía.
]]>Empecé a primeros de junio de 2026. El sitio se publicó el 22 de julio. En medio hay unas cuantas decisiones que no se ven, que son justo las que quiero contar: el valor de un portafolio no está en la lista de tecnologías, está en los descartes razonados.
Todo el código está a la vista: github.com/carloslb-com/carloslb-com.github.io.
Antes de escribir una línea me puse un límite: tener algo que enseñar, no ser preciso al 99,9 %. Un portafolio perfecto que no se publica no es un portafolio, es una carpeta. Y un lema de trabajo: robustez por encima de brevedad o ingenio. Cada vez que dudé entre la solución lista y la solución aburrida que aguanta, gana la aburrida.
| Pieza | Elección | Razón |
|---|---|---|
| Generador | Jekyll 4.4.1 (Ruby 3.3.8) | Sitio estático: sin base de datos y sin panel que atacar |
| Estilos | Dart Sass con @use / @forward |
Módulos de verdad; @import está obsoleto |
| Bilingüe | jekyll-polyglot | Dos árboles (/ y /en/) sin duplicar plantillas |
| Extras | jekyll-feed, jekyll-seo-tag, jekyll-sitemap | Lo estándar, sin inventar |
| Entorno | Máquina virtual Ubuntu en VirtualBox | Desarrollo aislado del equipo de trabajo |
| Publicación | GitHub Pages con flujo propio de GitHub Actions | Por obligación, no por gusto: lo cuento en la tercera parte |
Lo importante de la tabla es lo que no hay: ni base de datos, ni CMS, ni servicios de terceros incrustados. Un sitio estático es un montón de archivos HTML. No tiene sesión que robar ni consulta que inyectar.
La estructura es la misma en los tres perfiles. Cabecera, secciones, blog, pie: idénticos. Lo único que cambia es la piel: la paleta y la tipografía.
flowchart TD
accTitle: Estructura del sitio, con una portada neutral y tres perfiles
accDescr {
La portada es un espacio neutral con tres puertas de entrada: IT y Telecomunicaciones,
Administración y Recursos Humanos, y Formación y Docencia. Las tres desembocan en la
misma estructura de página, y lo único que cambia entre ellas son los tokens de CSS
que definen la paleta de color y la tipografía.
}
H["Portada neutral<br/>(tres puertas)"] --> IT["IT / Telecomunicaciones"]
H --> AD["Administración / RRHH"]
H --> FO["Formación / Docencia"]
IT --> B["Misma estructura:<br/>cabecera, secciones, blog, pie"]
AD --> B
FO --> B
B --> T["Solo cambian los tokens de CSS:<br/>paleta y tipografía"]
Son ocho paletas: cuatro mundos (los tres perfiles más la portada neutral) por dos temas, claro y oscuro. Las validé a alto contraste —la mayoría en nivel AAA— antes de escribir una sola línea de contenido. Corregir el contraste al final es rehacerlo todo.
La tipografía va autoalojada en woff2. El cuerpo es Atkinson Hyperlegible, diseñada específicamente para baja visión. Los titulares cambian por mundo: JetBrains Mono en IT, IBM Plex Serif en Administración, Nunito en Formación. Un tipo de letra dice mucho antes de que se lea la primera palabra.
Los datos —proyectos, certificaciones, cursos, experiencia— viven en YAML, con el patrón clave → {es, en}. Se traduce solo lo que cambia entre idiomas. Un año es un año en los dos.
La clase del perfil vive en la etiqueta html, no en body, junto al atributo del tema. Si vive en body, el navegador ya ha empezado a pintar cuando aplicas el tema y se ve el destello de la paleta equivocada. Con la clase arriba, el guion se ejecuta antes de que haya nada que destellar.
Efecto secundario: como los dos atributos cuelgan del mismo elemento, los selectores de paleta se concatenan sin espacio. Sí, el CSS también tiene su letra pequeña.
Aquí está la decisión de la que más orgulloso estoy, y es la que más cosas descartó.
El requisito era: si entras al blog por la puerta de IT, el artículo debería sentirse de IT. Pero un artículo es un solo archivo, y puede alcanzarse desde tres sitios distintos y en dos idiomas.
Camino 1: generar versiones físicas del artículo por contexto. Tres contextos por dos idiomas son seis versiones de cada artículo. Mantenimiento inviable y URLs duplicadas compitiendo entre sí. Descartado.
Camino 2: que JavaScript reconstruya la barra de navegación al vuelo. Más código, más frágil, y sin JavaScript el visitante se queda sin poder navegar. Descartado.
Lo que hice: el color y las tipografías sí cambian según la puerta por la que entraste; la barra de navegación se queda como está.
sequenceDiagram
accTitle: Cómo el artículo adopta el color de la puerta por la que se entró
accDescr {
Desde el listado del blog de IT, el enlace al artículo lleva un parámetro que indica
la procedencia. El artículo se sirve con la piel neutra. Un guion situado en la cabecera
del documento lee ese parámetro antes de que el navegador pinte nada, aplica la clase
del perfil correspondiente y limpia el parámetro de la barra de direcciones. La barra
de navegación no cambia en ningún momento.
}
participant L as Listado del blog de IT
participant N as Navegador
participant A as Artículo
L->>N: enlace con el parámetro de procedencia
N->>A: solicita el artículo (se sirve con la piel neutra)
A->>A: un guion en la cabecera lee el parámetro antes de pintar
A->>N: aplica la piel de IT y limpia la dirección
Note over N,A: La barra de navegación no cambia nunca
Si el guion falla, el artículo se ve en neutro y se lee perfectamente. Nadie se queda fuera.
Dos apuntes que me llevo de ahí, y que ya he reutilizado en otros sitios:
Cuando todas las soluciones a un requisito son malas, a veces el problema es el requisito, no la solución.
Busca la versión que da la mayor parte del valor percibido por una fracción del coste. El color da el 90 % de la sensación de estar en un mundo distinto. La barra dinámica añadía un 10 % a un coste enorme.
No lo he hecho solo. He usado un asistente de inteligencia artificial como herramienta de consulta, de aprendizaje de Jekyll y Liquid, de diagnóstico cuando algo no cuadraba, y de organización y seguimiento de las tareas de un proyecto que ha durado dos meses y tiene muchas piezas.
Lo digo con todas las letras porque esconderlo sería justo lo contrario de lo que defiendo. Y porque el matiz importa: la herramienta acelera la consulta y ordena el trabajo, pero no toma las decisiones. Las de arriba —qué descartar, qué requisito cuestionar, dónde parar— son mías, y cada una tiene su porqué escrito. En la tercera parte cuento en qué se equivocó y cómo lo detecté.
Siguiente: en la segunda parte, por qué este sitio no carga ni un solo recurso de un tercero, cómo funciona el formulario de contacto sin JavaScript, y qué normativa aplica de verdad a una web personal —que es bastante menos de lo que dicen las plantillas.
]]>