Falando Accesible

WCAG 2.2 en 2026: criterios clave para blogs modernos

Las Web Content Accessibility Guidelines (WCAG) 2.2 introdujeron nueve nuevos criterios de éxito que han cambiado la forma en que pensamos la accesibilidad web. Aunque fueron publicadas en octubre de 2023, en 2026 ya son el estándar de facto para proyectos profesionales.

Los tres criterios que más impactan en blogs

1. Focus Not Obscured (Minimum) - Nivel AA

Este criterio (2.4.11) establece que cuando un elemento recibe el foco del teclado, debe ser al menos parcialmente visible. Nada de barras fijas, modales o sticky headers que tapen completamente el elemento enfocado.

Implementación práctica: Si usas elementos posicionados de forma fija (como un menú sticky), asegúrate de que no cubran más del 50% de ningún elemento interactivo cuando este reciba el foco. Usa scroll-margin-top en CSS para crear espacio automáticamente:

:focus { scroll-margin-top: 80px; }

2. Target Size (Minimum) - Nivel AA

El criterio 2.5.8 requiere que los elementos interactivos tengan al menos 24×24 píxeles CSS, con algunas excepciones. Esto es especialmente importante en móviles, donde dedos de diferentes tamaños necesitan objetivos suficientemente grandes.

Implementación práctica: Establece un tamaño mínimo para todos los enlaces y botones:

a, button { min-height: 44px; min-width: 44px; }

Sí, 44px es más que el mínimo de 24px requerido, pero coincide con las guías de iOS y Android para áreas táctiles cómodas. Si el elemento visible es más pequeño, asegúrate de que el área interactiva (con padding) alcance este tamaño.

3. Consistent Help - Nivel A

Si ofreces mecanismos de ayuda (contacto, chat, teléfono, FAQ), deben aparecer en el mismo orden relativo en todas las páginas donde estén presentes (criterio 3.2.6).

Implementación práctica: En nuestro caso, mantenemos el enlace "Contacto" siempre en la misma posición del menú, y la sección de contacto siempre al final de cada página. Simple pero efectivo.

Otros criterios relevantes para 2026

Dragging Movements (2.5.7): Cualquier función que requiera arrastrar debe tener una alternativa de un solo puntero. Importante para galerías de imágenes o sliders.

Redundant Entry (3.3.7): No pidas al usuario información que ya proporcionó en el mismo proceso, a menos que sea esencial para seguridad. Relevante si tienes formularios de varios pasos.

Accessible Authentication (Minimum) (3.3.8): Los tests cognitivos (como recordar contraseñas sin gestor) no deben ser el único método de autenticación. Permite copiar/pegar, autocompletar o alternativas biométricas.

¿Vale la pena implementar WCAG 2.2?

Absolutamente. No solo porque será un requisito legal en muchas jurisdicciones (ya lo es en la UE para el sector público), sino porque hace tu sitio genuinamente más usable para todo el mundo. Una persona mayor con temblor en las manos, alguien usando el móvil con una mano en el metro, o un usuario de teclado navegando rápidamente: todos se benefician.

La mejor parte es que la mayoría de estos criterios no requieren JavaScript complejo ni bibliotecas especiales. Son mejoras progresivas que puedes implementar directamente en tu HTML y CSS.

Recursos recomendados:

• Especificación oficial de WCAG 2.2 (W3C)
• Understanding WCAG 2.2 - Guías de implementación detalladas
• Herramientas de testing: axe DevTools, WAVE, Lighthouse

Modo oscuro accesible: más allá de invertir colores

El modo oscuro se ha convertido en una característica esperada en cualquier sitio web moderno. Pero implementarlo bien no es tan simple como invertir una paleta de colores. Hablemos de cómo crear un tema oscuro que realmente respete la accesibilidad.

Por qué filter: invert() no es suficiente

La tentación es grande: aplicar filter: invert(1) hue-rotate(180deg) y llamarlo un día. El problema es que esto:

• Invierte también las imágenes (incluyendo logos y fotos)
• No respeta el contraste real entre texto y fondo
• Puede generar colores inesperados que fallen los ratios WCAG
• Ignora las preferencias del sistema operativo
• Causa problemas de rendimiento en algunos navegadores

El enfoque correcto: variables CSS

La solución profesional es usar custom properties (variables CSS) que cambien según el tema activo. Así mantienes control total sobre cada color en cada contexto:

:root { --bg: #ffffff; --text: #000000; }

[data-theme="dark"] { --bg: #0f0f0f; --text: #f5f5f5; }

Este enfoque te permite:

• Ajustar el contraste específicamente para cada tema
• Mantener colores de marca consistentes
• Crear degradados y sombras apropiados para cada modo
• Excluir elementos específicos (como imágenes) de la inversión

Contraste real, no invertido

Un error común es asumir que si blanco sobre negro tiene contraste 21:1, entonces negro sobre blanco también. Esto es cierto matemáticamente, pero no perceptualmente. Los fondos muy oscuros necesitan texto ligeramente menos brillante que blanco puro (#f5f5f5 en lugar de #ffffff) para evitar el efecto de "halación" o sangrado visual.

Ratios recomendados para modo oscuro:

• Texto normal: mínimo 7:1 (AAA)
• Texto grande: mínimo 4.5:1 (AA)
• Elementos UI: mínimo 3:1

Usa herramientas como Contrast Checker de WebAIM o las DevTools de Chrome para verificar cada combinación en ambos temas.

Respetar las preferencias del usuario

Muchos usuarios ya tienen configurado un tema preferido en su sistema operativo. Respétalo usando la media query prefers-color-scheme:

@media (prefers-color-scheme: dark) { :root { /* colores oscuros */ } }

Pero también ofrece un control manual. No todos los usuarios que prefieren modo oscuro lo quieren en todos los sitios, ni en todos los momentos del día. Un botón de alternancia que persista la preferencia en localStorage es la mejor experiencia de usuario.

Casos de uso reales

Personas con fotofobia: La sensibilidad a la luz hace que las pantallas brillantes sean dolorosas. Para ellas, el modo oscuro no es una preferencia estética, es una necesidad médica.

Usuarios nocturnos: Leer en la oscuridad con un fondo blanco brillante dificulta conciliar el sueño (la luz azul suprime la melatonina). Un modo oscuro bien diseñado minimiza este impacto.

Usuarios con astigmatismo: Curiosamente, algunos usuarios con astigmatismo reportan que el texto oscuro sobre fondo claro es más legible para ellos. De ahí la importancia de ofrecer ambas opciones.

Colores de acento en modo oscuro

Los colores brillantes que funcionan en modo claro a menudo resultan demasiado intensos en fondos oscuros. Ajusta la saturación y luminosidad:

• Modo claro: Colores más saturados y ligeramente más oscuros
• Modo oscuro: Colores menos saturados y más luminosos

En nuestro caso, el dorado #d4af37 funciona bien en oscuro, pero lo ajustamos a #b8964e para modo claro (menos luminoso, mejor contraste sobre blanco).

Testing exhaustivo

No te confíes de un solo dispositivo o navegador. Prueba en:

• Diferentes niveles de brillo de pantalla
• Pantallas OLED (negro verdadero) y LCD (gris oscuro)
• Exteriores con luz solar directa
• Habitaciones completamente oscuras

Lo que se ve perfecto en tu monitor de diseño de alta gama puede fallar miserablemente en un móvil económico bajo el sol.

Conclusión

Un modo oscuro bien implementado requiere trabajo: definir variables, probar contrastes, respetar preferencias del sistema, ofrecer control manual. Pero el resultado es un sitio que realmente sirve a sus usuarios en lugar de solo verse moderno en un portfolio.

La accesibilidad no es una característica opcional que añades al final. Es la base sobre la que construyes todo lo demás.

Ventajas reales de los sitios 100% estáticos en 2026

En una era donde cada sitio parece necesitar React, Next.js, un backend serverless y una docena de microservicios, los sitios estáticos pueden parecer anticuados. Sin embargo, para blogs, portfolios, sitios corporativos y documentación, lo estático no solo es suficiente: es superior.

¿Qué es realmente un sitio estático?

Un sitio 100% estático está compuesto exclusivamente de HTML, CSS y JavaScript opcional que se ejecuta en el cliente. No hay procesamiento en el servidor, no hay bases de datos, no hay generación dinámica de contenido. Los archivos que subes son exactamente los archivos que se sirven.

Esto no significa que sea aburrido o limitado. Puedes tener:

• Interactividad completa con JavaScript vanilla
• Formularios (usando servicios de terceros o serverless functions)
• Búsqueda del lado del cliente
• Comentarios (con soluciones como utterances o giscus)
• Animaciones, transiciones, Single Page Application si lo deseas

Ventaja 1: Seguridad por diseño

La mayoría de vulnerabilidades web explotan el procesamiento dinámico: inyección SQL, XSS almacenado, ejecución remota de código, deserialización insegura. Un sitio estático elimina toda esa superficie de ataque.

No hay:

• Base de datos que hackear
• Backend que explotar
• Dependencias del servidor que queden obsoletas
• Credenciales de administrador que filtrar
• Panel de WordPress vulnerable a ataques de fuerza bruta

Tu única preocupación de seguridad es el XSS del lado del cliente si aceptas input del usuario, y eso se mitiga fácilmente sanitizando cualquier contenido dinámico o usando Content Security Policy headers.

Ventaja 2: Velocidad extrema

Sin procesamiento del servidor, los sitios estáticos se sirven directamente desde memoria o disco. Con un CDN (Cloudflare, Netlify, Vercel), tu contenido se replica globalmente y se entrega desde el servidor más cercano al usuario.

Números reales:

• Time to First Byte: 50-100ms (vs 300-800ms de WordPress típico)
• First Contentful Paint: 200-400ms (vs 1-2 segundos)
• Time to Interactive: Inmediato (sin esperar JavaScript pesado)

Esta velocidad no solo mejora la experiencia del usuario, también impacta directamente en SEO (Core Web Vitals), tasas de conversión y accesibilidad (usuarios con conexiones lentas).

Ventaja 3: Privacidad por defecto

Un sitio estático no puede rastrearte por naturaleza. No hay cookies de sesión, no hay logs del lado del servidor capturando IPs, no hay analytics integrados por defecto. Si quieres privacidad total, simplemente no añadas nada que rastreara.

Contrastemos con plataformas dinámicas:

• WordPress: IPs en logs, cookies de comentarios, plugins de analytics en el 90% de instalaciones
• Wix/Squarespace: Rastreo incorporado que no puedes desactivar completamente
• Sitios con backend: Sesiones, autenticación, comportamiento almacenado

Con un sitio estático, puedes cumplir GDPR sin siquiera mostrar un banner de cookies (si no usas cookies no esenciales). Esa simplicidad legal es valiosa.

Ventaja 4: Hosting gratis o casi gratis

Como no necesitas procesamiento del servidor, puedes hostear en servicios que ofrecen planes gratuitos generosos:

• GitHub Pages: Gratis ilimitado para proyectos públicos
• Netlify: 100GB bandwidth gratis/mes
• Vercel: 100GB bandwidth gratis/mes
• Cloudflare Pages: Bandwidth ilimitado gratis

Para blogs personales o sitios de proyectos pequeños, tu único costo puede ser el dominio (10-15€/año). Compara eso con hosting compartido (60€/año mínimo) o VPS (10-20€/mes).

Ventaja 5: Portabilidad total

Tu sitio son archivos. Puedes:

• Moverlo a otro host en minutos (solo sube los archivos)
• Versionarlo completamente con Git
• Hacer backup simplemente copiando una carpeta
• Trabajar offline y pre-visualizar sin servidor local
• Servir desde un USB en caso extremo

No hay dependencias de versiones de PHP, extensiones de servidor, configuraciones de base de datos o migraciones complejas. Archivos son archivos, funcionan en cualquier servidor web.

Ventaja 6: Mantenimiento mínimo

Un CMS dinámico requiere:

• Actualizaciones de seguridad constantes
• Parches de plugins/temas
• Backups regulares de base de datos
• Monitoreo de uptime y errores de servidor
• Optimización de queries conforme crece

Un sitio estático publicado en 2020 funciona exactamente igual en 2026 sin tocar una línea de código. No se "rompe" con el tiempo porque no hay componentes dinámicos que desactualizarse.

¿Cuándo NO usar sitios estáticos?

Sean honestos, los sitios estáticos no son para todo:

• E-commerce complejo: Catálogos dinámicos con miles de productos necesitan backend
• Plataformas sociales: Contenido generado por usuarios en tiempo real requiere base de datos
• Aplicaciones web: Si tu sitio es principalmente una app (Gmail, Trello), no es estático
• Personalización por usuario: Dashboards personalizados necesitan autenticación y estado del servidor

Pero para blogs, portfolios, sitios corporativos, documentación, landing pages, sitios de eventos, galerías de fotos y mucho más, lo estático es la elección inteligente.

Generadores de sitios estáticos (SSG) en 2026

Si quieres disfrutar de las ventajas del contenido estático pero con comodidades de desarrollo modernas:

• Hugo: Velocidad extrema, perfecto para blogs grandes
• 11ty (Eleventy): Flexible, JavaScript-based, sin magia
• Jekyll: El clásico, integración perfecta con GitHub Pages
• Next.js SSG mode: Si necesitas React pero quieres output estático

O simplemente escribe HTML manualmente si tu sitio es pequeño. No hay vergüenza en ello (es lo que hacemos en Falando para nuestro propio sitio).

Conclusión

Los sitios 100% estáticos representan una filosofía: menos es más, la seguridad por diseño importa, la privacidad es un derecho, la velocidad es una característica, y no toda web necesita ser una aplicación.

En 2026, mientras otros lidian con pipelines complejos, contenedores, microservicios y facturas de hosting infladas, los sitios estáticos simplemente... funcionan. Rápido, seguro, privado, para siempre.