Ecuador tiene norma técnica oficial de accesibilidad web desde enero de 2014 y un reglamento con plazos que vencieron en 2020. Aun así, si le preguntas a 10 dueños de PYMES si su sitio cumple las WCAG, la respuesta típica es otra pregunta: ¿las qué? Ese desconocimiento tiene un costo doble: te expone frente a un marco legal que ya existe y te cierra la puerta a casi 2 millones de ecuatorianos que hoy no pueden usar tu página con normalidad.
¿Es obligatoria la accesibilidad web en Ecuador?
Depende de quién eres. Para instituciones públicas y empresas privadas que prestan servicios públicos (salud, educación, telecomunicaciones, finanzas), sí: el Reglamento Técnico Ecuatoriano RTE INEN 288 lo exige desde 2016, con plazos que vencieron en 2018 (nivel A) y 2020 (nivel AA). Para una PYME privada común, hoy no hay sanción activa por tener un sitio inaccesible. Pero el marco legal ya existe, la tendencia regulatoria apunta en una sola dirección y el mercado que excluyes es real.
El marco legal, pieza por pieza
La base histórica fue la Ley Orgánica de Discapacidades de 2012, cuyo artículo 65 exigía que las instituciones públicas y privadas que presten servicios públicos incluyan en sus portales web un enlace de acceso para personas con discapacidad. Esa ley fue derogada: desde el 3 de julio de 2025 rige la nueva Ley Orgánica de las Personas con Discapacidad, publicada en el Cuarto Suplemento del Registro Oficial No. 73, que mantiene el mandato de accesibilidad a la comunicación mediante ayudas técnicas y tecnológicas, formatos de fácil lectura y nuevas herramientas tecnológicas, además de endurecer obligaciones laborales como la cuota del 4% para empresas con 25 o más trabajadores.
El estándar técnico es la norma NTE INEN-ISO/IEC 40500, publicada en el Registro Oficial No. 171 del 28 de enero de 2014. No es una invención local: es la adopción idéntica de la ISO/IEC 40500:2012, que a su vez es la WCAG 2.0 del W3C palabra por palabra. Cuando alguien te habla de accesibilidad web en Ecuador, técnicamente está hablando de WCAG 2.0 con sello INEN. Y el RTE INEN 288, vigente desde agosto de 2016, es el reglamento que la vuelve exigible para el sector público y los privados con servicios públicos, con nivel de conformidad AA como meta.
WCAG 2.0 es el piso legal, no el techo técnico
La norma ecuatoriana congela WCAG en su versión 2.0 (2008). El W3C ya publicó WCAG 2.1 y 2.2, que agregan criterios para móviles y baja visión. Si construyes hoy, apunta a WCAG 2.2 nivel AA: cumples la norma local por superset y no te quedas con un estándar de hace 18 años.
El mercado que excluyes cuando tu sitio no es accesible
personas con discapacidad registradas en Ecuador, el 2.67% de la población
CONADIS, Registro Nacional de Discapacidadesde ecuatorianos con 65 años o más: el 9% de la población, frente al 6.2% en 2010
INEC, Censo 2022de 1 millón de páginas de inicio analizadas tiene fallas WCAG 2 detectables
WebAIM Million 2025errores de accesibilidad en promedio por página de inicio
WebAIM Million 2025Suma las dos primeras cifras y el punto queda claro: entre personas con discapacidad registradas y adultos mayores hay cerca de 2 millones de ecuatorianos para quienes un botón sin etiqueta, un texto gris claro sobre blanco o un formulario que solo funciona con mouse es una barrera literal. Y el segmento de 65+ no es un mercado menor: es el grupo que más creció entre los dos últimos censos y el que más depende de canales digitales para trámites, banca y compras desde la pandemia. La señora de 72 años que quiere comprar en tu tienda online con su tarjeta existe; la pregunta es si tu checkout la deja terminar.
Hay un efecto secundario que casi nadie conecta: los sitios inaccesibles suelen ser también sitios viejos. HTML sin estructura semántica, botones hechos con divs, textos dentro de imágenes. Ese perfil de sitio pierde por accesibilidad y pierde por obsolescencia al mismo tiempo, y el costo comercial de esa segunda parte lo desglosamos en el artículo del blog sobre páginas web desactualizadas en Ecuador.
Los 7 errores de accesibilidad más comunes
El reporte WebAIM Million 2025 analizó el millón de páginas de inicio más visitadas del mundo y encontró que el 96% de todos los errores detectados cae en apenas seis categorías. Son fallas baratas de corregir y aun así están en todas partes. A esas seis les sumamos una séptima que las herramientas automáticas no detectan bien pero que aparece en casi toda auditoría manual: el foco de teclado invisible. Así se ven, a quién bloquean y cómo se corrigen:
| Error | Impacto (quién queda fuera) | Corrección |
|---|---|---|
| Texto con bajo contraste (79.1% de páginas, WebAIM 2025) | Personas con baja visión y adultos mayores; también cualquiera bajo el sol en la calle | Ratio mínimo 4.5:1 en texto normal; verificar con Contrast Checker de WebAIM |
| Imágenes sin texto alternativo (55.5%) | Usuarios de lectores de pantalla; si la imagen es un link, pierden la navegación completa | Atributo alt descriptivo en toda imagen informativa; alt vacío solo en decorativas |
| Formularios sin etiquetas (48.2%) | Lectores de pantalla anuncian 'campo de edición' sin decir qué va ahí | Un <label> asociado por cada input; placeholder no reemplaza al label |
| Links vacíos (45.4%) | El lector de pantalla lee 'enlace' sin destino; típico en íconos sin texto | Texto visible o aria-label en cada link; nada de 'clic aquí' repetido |
| Botones vacíos (29.6%) | Botones de ícono (lupa, carrito, menú) que el lector anuncia como 'botón' a secas | aria-label descriptivo: 'Buscar', 'Abrir carrito', 'Abrir menú' |
| Documento sin idioma declarado (15.8%) | El lector de pantalla lee español con fonética de inglés: ininteligible | lang="es" en la etiqueta html; una línea de código |
| Foco de teclado invisible (no medido por escáneres) | Cualquier persona que navega con Tab: motora, baja visión, usuarios avanzados | Nunca usar outline: none sin reemplazo; definir un focus-visible con contraste real |
Texto con bajo contraste (79.1% de páginas, WebAIM 2025)
- Impacto (quién queda fuera)
- Personas con baja visión y adultos mayores; también cualquiera bajo el sol en la calle
- Corrección
- Ratio mínimo 4.5:1 en texto normal; verificar con Contrast Checker de WebAIM
Imágenes sin texto alternativo (55.5%)
- Impacto (quién queda fuera)
- Usuarios de lectores de pantalla; si la imagen es un link, pierden la navegación completa
- Corrección
- Atributo alt descriptivo en toda imagen informativa; alt vacío solo en decorativas
Formularios sin etiquetas (48.2%)
- Impacto (quién queda fuera)
- Lectores de pantalla anuncian 'campo de edición' sin decir qué va ahí
- Corrección
- Un <label> asociado por cada input; placeholder no reemplaza al label
Links vacíos (45.4%)
- Impacto (quién queda fuera)
- El lector de pantalla lee 'enlace' sin destino; típico en íconos sin texto
- Corrección
- Texto visible o aria-label en cada link; nada de 'clic aquí' repetido
Botones vacíos (29.6%)
- Impacto (quién queda fuera)
- Botones de ícono (lupa, carrito, menú) que el lector anuncia como 'botón' a secas
- Corrección
- aria-label descriptivo: 'Buscar', 'Abrir carrito', 'Abrir menú'
Documento sin idioma declarado (15.8%)
- Impacto (quién queda fuera)
- El lector de pantalla lee español con fonética de inglés: ininteligible
- Corrección
- lang="es" en la etiqueta html; una línea de código
Foco de teclado invisible (no medido por escáneres)
- Impacto (quién queda fuera)
- Cualquier persona que navega con Tab: motora, baja visión, usuarios avanzados
- Corrección
- Nunca usar outline: none sin reemplazo; definir un focus-visible con contraste real
Los widgets de accesibilidad no te vuelven accesible
Los overlays de un clic que prometen cumplimiento instantáneo no corrigen el HTML de fondo: parchan síntomas, suelen chocar con los lectores de pantalla reales y la propia comunidad de usuarios ciegos los rechaza públicamente. Si el presupuesto es limitado, corregir contraste, alt y labels a mano rinde más que cualquier widget.
Cómo auditar la accesibilidad de tu página gratis
No necesitas contratar una consultora para saber dónde estás parado. Con navegador, 30 minutos y dos herramientas gratuitas puedes detectar la mayoría de los errores de la tabla anterior:
- 1Ejecuta Lighthouse desde Chrome DevTools (pestaña Lighthouse, categoría Accesibilidad) sobre tu home, una página de producto y el checkout. Anota el puntaje: menos de 90 significa errores estructurales, no detalles.
- 2Instala la extensión axe DevTools (gratuita, de Deque) y corre un escaneo en las mismas páginas: detecta más reglas WCAG que Lighthouse y te señala el nodo HTML exacto que falla.
- 3Navega todo el flujo principal usando solo el teclado: Tab para avanzar, Enter para activar, Escape para cerrar. Si en algún momento no sabes dónde está el foco o quedas atrapado en un modal, tienes una falla crítica.
- 4Verifica el contraste de tu texto sobre fondo con el Contrast Checker de WebAIM: el mínimo AA es 4.5:1 para texto normal y 3:1 para texto grande. Los grises claros de moda casi nunca pasan.
- 5Descarga NVDA (lector de pantalla gratuito y de código abierto para Windows) y escucha tu home con los ojos cerrados: si no puedes entender qué vende tu negocio ni llegar al botón de contacto, un usuario ciego tampoco.
- 6Revisa los alt de tus imágenes con clic derecho e inspeccionar: toda imagen que comunica algo necesita una descripción; los logos enlazados deben decir a dónde llevan.
- 7Prueba tus formularios completos: haz clic en cada etiqueta y confirma que el cursor salta al campo correcto, y verifica que los mensajes de error digan qué corregir y no solo se pinten de rojo.
Un detalle práctico: el mismo Lighthouse que usas en el paso 1 te entrega el puntaje de performance junto al de accesibilidad, y suelen caer juntos porque comparten causa raíz (HTML inflado, plantillas viejas, scripts de terceros). Cómo leer esa mitad del reporte y por qué Google la usa para rankear lo explicamos a fondo en la guía de Core Web Vitals 2026 del blog.
Accesibilidad como decisión de negocio, no como caridad
Los mismos atributos que piden las WCAG son señales que Google y los motores de IA leen para entender tu contenido: HTML semántico, encabezados jerárquicos, alt descriptivos, idioma declarado. Un sitio accesible es, casi por definición, un sitio mejor indexable. A eso se suma el ángulo regulatorio: Ecuador ya renovó su ley de discapacidades en 2025 y la experiencia comparada (la European Accessibility Act obliga al sector privado en la UE desde junio de 2025) sugiere que la exigencia al sector privado es cuestión de tiempo, no de si ocurre o no. Llegar antes cuesta menos que llegar obligado.
En NM Tech Studio esa parte no es un extra facturable: los sitios que construimos en Next.js parten de HTML semántico, foco visible y contraste AA desde el primer componente, porque corregir accesibilidad sobre un sitio terminado siempre sale más caro que incluirla en el diseño. La regla práctica que aplicamos es simple: si una página no se puede operar completa con teclado y no pasa axe sin errores críticos, no se entrega.
Preguntas frecuentes
¿Qué es la norma NTE INEN-ISO/IEC 40500?
+
Es la norma técnica ecuatoriana de accesibilidad web, publicada en el Registro Oficial No. 171 del 28 de enero de 2014. Es una adopción idéntica de la ISO/IEC 40500:2012, que corresponde palabra por palabra a las WCAG 2.0 del W3C. Define principios, pautas y criterios de conformidad en tres niveles (A, AA y AAA) para que el contenido web sea usable por personas con discapacidad visual, auditiva, motora y cognitiva.
¿Pueden multar a mi negocio por no tener una web accesible en Ecuador?
+
Si eres una PYME privada común, hoy no existe un régimen de multas activo por accesibilidad web. La obligación del RTE INEN 288 alcanza al sector público y a privados que prestan servicios públicos, con plazos que vencieron en 2018 (nivel A) y 2020 (nivel AA). Para el resto del sector privado es voluntario por ahora, pero la nueva Ley Orgánica de las Personas con Discapacidad de 2025 confirma que la regulación avanza y conviene no construir deuda de accesibilidad.
¿Qué nivel WCAG debo cumplir: A, AA o AAA?
+
El objetivo práctico y el que exige el reglamento ecuatoriano para los obligados es el nivel AA. El nivel A es el mínimo de supervivencia (deja fuera cosas básicas como el contraste), y el AAA es tan estricto que ni el W3C recomienda exigirlo como política general para sitios completos. AA cubre contraste 4.5:1, navegación por teclado, etiquetas en formularios y textos alternativos: lo que un usuario real necesita.
¿Los widgets o plugins de accesibilidad de un clic sirven?
+
No como solución de cumplimiento. Los overlays inyectan JavaScript sobre un HTML defectuoso sin corregirlo: los escáneres siguen detectando los errores de fondo, suelen interferir con los lectores de pantalla que la gente ya usa configurados a su medida, y organizaciones de usuarios ciegos han pedido públicamente no usarlos. Corregir contraste, alt, labels e idioma en el código real cuesta menos de lo que parece y sí resuelve.
¿Cuánto cuesta hacer accesible un sitio web existente?
+
Depende del estado del código. Si el sitio tiene HTML semántico razonable, corregir los errores típicos (contraste, alt, labels, foco visible, idioma) es trabajo de días, no de meses. Si el sitio es una plantilla vieja con botones hechos de divs y texto dentro de imágenes, suele ser más barato rehacerlo bien que parcharlo: el rediseño resuelve accesibilidad, performance y SEO en un solo proyecto. Una auditoría gratuita con Lighthouse y axe te dice en cuál de los dos escenarios estás.
