Cumplir accesibilidad web en 2026 significa alcanzar WCAG 2.2 nivel AA: el estándar publicado por el W3C en octubre de 2023, que la Ley 1346 de 2009 y la NTC 5854 exigen a entidades públicas y contratistas del Estado en Colombia. Implica contraste mínimo 4.5:1, navegación completa por teclado y texto alternativo en todas las imágenes.
Por qué la accesibilidad web ya no es opcional en 2026
La accesibilidad web es la práctica de diseñar y desarrollar sitios para que personas con discapacidades visuales, auditivas, motoras o cognitivas puedan usarlos con autonomía. En 2026 dejó de ser un “nice to have” para convertirse en un requisito legal, comercial y de SEO simultáneamente.
El estándar internacional es WCAG 2.2 (Web Content Accessibility Guidelines), publicado oficialmente por el W3C en octubre de 2023. En la Unión Europea es obligatorio para sitios públicos y empresas grandes desde la European Accessibility Act (vigencia junio 2025). En Colombia, la Ley 1346 de 2009 ratificó la Convención de Naciones Unidas sobre derechos de personas con discapacidad y exige accesibilidad digital en entidades públicas y empresas con contratos estatales.
Más allá de lo legal: el 15% de la población mundial vive con algún tipo de discapacidad. Un sitio inaccesible está perdiendo entre 1 de cada 7 visitantes potenciales. Y Google usa señales de accesibilidad como factor secundario de ranking desde 2024 (anunciado en Google I/O).
WCAG 2.2: qué cambió respecto a 2.1
WCAG 2.2 introdujo 9 nuevos criterios respecto a 2.1, todos pensados para mejorar la experiencia de usuarios con discapacidades motoras, cognitivas y de baja visión. Los más impactantes para sitios PYME en Colombia:
Criterio 2.4.11 — Foco no oculto (mínimo)
Cuando un usuario navega por teclado, el elemento enfocado nunca debe quedar totalmente oculto detrás de otros elementos (banners de cookies, headers fijos). Es el problema más común que vemos en auditorías.
Criterio 2.4.12 — Foco no oculto (mejorado)
El elemento enfocado debe ser completamente visible (no parcialmente). Aplica al nivel AAA pero es buena práctica.
Criterio 2.5.7 — Movimientos de arrastre
Toda funcionalidad que requiera arrastrar (drag) debe tener una alternativa por click simple. Aplica a sliders, controles, mapas interactivos.
Criterio 2.5.8 — Tamaño objetivo (mínimo)
Los elementos clicables deben tener al menos 24x24 píxeles. En 2.1 era una recomendación; en 2.2 es criterio obligatorio nivel AA.
Criterio 3.2.6 — Ayuda consistente
Si un sitio ofrece ayuda (chat, contacto, FAQ), debe estar en la misma posición relativa en todas las páginas donde aparezca.
Los 4 principios POUR de la accesibilidad
WCAG se organiza alrededor de 4 principios fundamentales. Memorizar POUR (Perceivable, Operable, Understandable, Robust) ayuda a auditar cualquier sitio rápido.
Perceivable (Perceptible)
La información debe presentarse de formas que los usuarios puedan percibir. Texto alternativo en imágenes, subtítulos en videos, contraste suficiente, transcripciones en audio.
Operable (Operable)
Toda funcionalidad debe ser operable por teclado, no solo mouse. Navegación lógica, sin trampas de foco, tiempos de respuesta ajustables.
Understandable (Comprensible)
Texto legible, comportamiento predecible, asistencia a errores en formularios. Idioma declarado en HTML, errores explicados con texto, no solo color.
Robust (Robusto)
Compatible con tecnologías asistivas presentes y futuras. HTML semántico válido, ARIA solo cuando HTML nativo no basta, roles y estados correctos.
Niveles A, AA, AAA: cuál debe cumplir su sitio
WCAG define tres niveles de cumplimiento. Para casi todos los casos comerciales en Colombia el objetivo es AA.
| Nivel | Cobertura | Para quién | Esfuerzo relativo |
|---|---|---|---|
| A | Mínimo absoluto | Sitios pequeños sin obligación legal | Bajo |
| AA | Estándar industria | Empresas, e-commerce, sitios públicos | Medio (recomendado) |
| AAA | Excelencia | Sector salud, educación inclusiva, gobierno | Alto (no práctico para todo el sitio) |
El estándar de mercado en 2026 es AA. La mayoría de regulaciones (EAA europea, ADA en EEUU, Ley 1346 Colombia) exigen AA. AAA es aspiracional para secciones críticas (formularios médicos, contenido educativo de discapacidad).
Ley 1346 en Colombia: obligaciones legales reales
Colombia ratificó la Convención de Naciones Unidas sobre derechos de personas con discapacidad mediante la Ley 1346 de 2009. Eso convirtió en ley nacional el compromiso de garantizar accesibilidad de la información digital.
Obligaciones específicas
Las entidades públicas deben tener sus sitios web accesibles bajo la NTC 5854 (norma técnica colombiana de accesibilidad web, basada en WCAG 2.0 nivel AA). El MinTIC ha publicado guías técnicas de aplicación.
Empresas privadas con contratos públicos
Cualquier empresa que licite con el Estado colombiano debe demostrar accesibilidad en sus plataformas digitales según los pliegos. Esto incluye sitios institucionales, portales de empleo, plataformas de servicios.
Salud, educación y servicios financieros
Aunque no haya regulación específica, hay tendencia jurisprudencial a exigir accesibilidad en estos sectores como derecho fundamental. La Corte Constitucional ha emitido sentencias favorables a usuarios discapacitados con sitios inaccesibles.
Auditoría rápida: 10 elementos críticos en cualquier sitio
Esta es la lista corta que aplicamos al revisar un sitio en menos de 30 minutos. Si fallan más de 3, el sitio no cumple WCAG AA.
- Navegación completa por teclado (Tab, Shift+Tab, Enter, Espacio, flechas).
- Foco visible en todos los elementos interactivos (outline o equivalente).
- Contraste mínimo 4.5:1 en texto normal, 3:1 en texto grande.
- Atributo alt descriptivo en TODAS las imágenes con información.
- Estructura de encabezados jerárquica (un H1, H2 en orden, sin saltarse niveles).
- Formularios con label asociado a cada input.
- Errores de formulario explicados con texto, no solo color rojo.
- Idioma declarado en .
- Botones identificados como
- Videos con subtítulos y transcripción cuando contienen información hablada.
Contraste, tipografía y tamaño de texto
El contraste es el problema #1 de accesibilidad en sitios “estéticos”. Texto gris claro sobre fondo blanco se ve elegante pero falla WCAG AA.
Ratios de contraste obligatorios WCAG AA
Texto normal (menos de 18pt o 14pt bold): mínimo 4.5:1. Texto grande (18pt+ o 14pt+ bold): mínimo 3:1. Componentes UI y gráficos esenciales: mínimo 3:1. Para AAA los ratios suben a 7:1 y 4.5:1.
Tipografía legible
Tamaño mínimo recomendado: 16px en cuerpo de texto. Las fuentes serif decorativas para texto largo reducen legibilidad. Sans-serif limpias (Inter, Funnel Display, Open Sans) funcionan mejor para usuarios con dislexia.
Zoom hasta 200% sin pérdida de funcionalidad
WCAG exige que el sitio funcione cuando el usuario hace zoom hasta 200%. Esto descarta diseños con tamaños fijos en píxeles para todo, y obliga a usar unidades relativas (rem, em, %) y media queries inteligentes.
Navegación por teclado y screen readers
Una persona ciega o con discapacidad motora navega usando solo teclado y lector de pantalla (NVDA, JAWS, VoiceOver). Si su sitio no es navegable así, está roto para esos usuarios.
Orden de tabulación lógico
Al presionar Tab, el foco debe moverse en el orden visual y lógico de la página. Si el menú lateral atrapa el foco antes de llegar al contenido principal, hay problema.
Skip links
El primer elemento focusable debe ser un link “Saltar al contenido principal” que permita al usuario de teclado evitar el menú repetido en cada página.
ARIA solo cuando HTML no basta
Es preferible usar HTML semántico nativo (nav, main, article, button, aside) que añadir role manualmente. ARIA mal aplicado empeora la accesibilidad.
Estados anunciados
Cuando un elemento cambia de estado (acordeón abierto/cerrado, tab activo), debe comunicarlo con aria-expanded, aria-selected, etc. Sin esto, el usuario ciego no sabe qué está pasando.
Imágenes, videos y descripciones alternativas
Cada imagen necesita un atributo alt que describa su función o contenido. Pero hay matices.
Imágenes informativas
alt describe el contenido relevante. Ejemplo: alt=“Equipo de trabajo en reunión presencial en oficina de Bogotá”.
Imágenes decorativas
alt="" (vacío). El lector de pantalla las ignora. NO omitir el atributo (sin alt el lector lee el nombre del archivo).
Imágenes funcionales (botones, links)
alt describe la acción, no la imagen. Ejemplo: alt=“Buscar” en el ícono de lupa, no alt=“Lupa”.
Videos con audio
Subtítulos sincronizados (cerrados o abiertos) y transcripción descargable. YouTube genera subtítulos automáticos pero hay que revisarlos.
Videos sin audio
Audiodescripción o transcripción que describa lo que pasa visualmente.
Formularios accesibles: errores, labels, validación
Los formularios son donde más se viola accesibilidad porque suelen estar diseñados pensando en estética.
Labels asociados
Cada input debe tener un
Mensajes de error útiles
Cuando un campo falla validación: indicar QUÉ falló y CÓMO arreglarlo. “Email inválido” es pobre. “El email debe tener formato nombre@dominio.com” es accesible.
Errores anunciados
Usar aria-live=“polite” en el contenedor de errores para que el lector de pantalla los anuncie cuando aparecen.
Campos requeridos
Marcarlos con required y anunciarlos con texto (“Campo obligatorio”) o aria-required=“true”, no solo con asterisco rojo (color es para videntes).
Herramientas para auditar accesibilidad
Combinar herramientas automáticas (rápidas pero limitadas) con auditoría manual (lenta pero completa).
HerramientaTipoCobertura WCAGCostoWAVE (browser extension)Automática30%Gratisaxe DevToolsAutomática57%Gratis (avanzado pago)Lighthouse AccessibilityAutomática~25%GratisNVDA + FirefoxManual screen readerTodaGratisVoiceOver + SafariManual screen reader (Mac/iOS)TodaGratis (incluido)Auditoría profesionalManual experta100% WCAG AA$2-8M COP
Las herramientas automáticas detectan máximo el 30-57% de problemas reales según estudio de Deque Systems. La auditoría manual con screen reader es indispensable para certificar AA real.
