WCAG 1.4.11: Contraste no textual

Qué significa esta regla

WCAG 1.4.11 Contraste no textual es un criterio de Nivel AA introducido en WCAG 2.1 y mantenido en WCAG 2.2. Exige una relación de contraste mínima de 3:1 entre la presentación visual de las siguientes dos categorías de contenido y sus colores adyacentes:

• Componentes de la Interfaz de Usuario (UI): Los límites o indicadores visuales que identifican controles interactivos como campos de texto, casillas de verificación, botones de opción, interruptores de palanca, menús desplegables y botones. Esto incluye tanto el propio componente como cualquier cambio de estado visual (por ejemplo, hover, foco, seleccionado, error).
• Objetos gráficos: Partes de íconos, gráficos, diagramas y otras imágenes significativas que son necesarias para comprender el contenido. Cada parte del gráfico que transmite información debe cumplir el umbral de 3:1 frente a su color circundante.

La relación de contraste se mide entre el elemento en primer plano y el color inmediatamente adyacente a él — normalmente su color de fondo, color de borde o un segmento vecino de un gráfico. El cálculo utiliza la misma fórmula de luminancia relativa definida en WCAG 1.4.3, pero el umbral es 3:1 en lugar de 4.5:1 porque los elementos no textuales pueden permitirse un contraste ligeramente menor y seguir siendo discernibles.

Un aprobado significa que todo indicador visual que identifica un componente de UI o comunica información en un gráfico alcanza al menos una relación de 3:1. Un fallo ocurre cuando un borde, trazo de ícono, segmento de gráfico o indicador de estado está por debajo de esta relación y el componente o gráfico no puede identificarse o entenderse sin esa información visual.

La especificación WCAG define varias excepciones importantes:

• Componentes inactivos: Los componentes de UI que están deshabilitados y no disponibles para la interacción están exentos. Un botón atenuado que no se puede pulsar no necesita cumplir el requisito de contraste.
• Apariencia controlada por el agente de usuario: Los componentes cuya presentación visual está completamente controlada por el estilo predeterminado del navegador (no sobrescrito por CSS del autor) están exentos, porque la responsabilidad recae en el proveedor del navegador.
• Gráficos esenciales o decorativos: Objetos gráficos donde la presentación particular es esencial para la información que se transmite (por ejemplo, banderas nacionales que representan países) o que son puramente decorativos están exentos. Los logotipos también suelen estar exentos en virtud de esta cláusula.
• Texto: El texto e imágenes de texto ya están cubiertos por 1.4.3 y 1.4.6 y no entran en 1.4.11.

Los indicadores de foco merecen especial atención en WCAG 2.2. El criterio 2.4.11 (Apariencia del foco) añade requisitos más estrictos para la visibilidad del foco, pero 1.4.11 sigue aplicándose al contraste de cualquier anillo de foco personalizado frente a su fondo. Un outline o box-shadow personalizado usado como indicador de foco debe alcanzar 3:1 frente al color adyacente para satisfacer este criterio de forma independiente.

Por qué es importante

Aproximadamente 2.2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual, según la Organización Mundial de la Salud. Una proporción significativa de estas personas — incluidas las aproximadamente 253 millones que viven con pérdida de visión moderada a grave — dependen de un contraste suficiente para percibir e interactuar con interfaces digitales sin necesidad de usar un lector de pantalla. Las personas con baja visión que navegan con software de aumento, modos de alto contraste o simplemente en condiciones de iluminación difíciles se encuentran entre las más directamente afectadas por fallos en 1.4.11.

Considera un escenario práctico: una persona con glaucoma está rellenando un formulario de reclamación de seguro en el sitio web de un hospital. Los campos del formulario usan un borde gris claro (#cccccc) sobre un fondo blanco (#ffffff), lo que produce una relación de contraste de solo 1.6:1 — muy por debajo del 3:1 requerido. La persona no puede ver dónde comienzan y terminan los campos de entrada, por lo que no puede hacer clic en ellos de forma fiable ni entender la estructura del formulario. Abandona el formulario por completo, lo que tiene tanto un coste personal como una responsabilidad legal para la institución.

Más allá de la discapacidad visual, las discapacidades cognitivas también pueden hacer que los componentes de UI con bajo contraste sean más difíciles de interpretar. Las personas con trastornos de atención o dificultades de procesamiento dependen de una fuerte diferenciación visual entre elementos interactivos y no interactivos para entender rápidamente la estructura de la página. Del mismo modo, las personas con temblores o discapacidades motoras que usan objetivos de puntero grandes necesitan ver claramente los límites de los controles para apuntar con precisión.

Desde la perspectiva del negocio, cumplir con 1.4.11 mejora la usabilidad para todas las personas en condiciones subóptimas — luz solar intensa en una pantalla móvil, monitores de baja calidad o pantallas antiguas con mala precisión de color. Reduce los costes de soporte, amplía el alcance de la audiencia y fortalece el SEO de forma indirecta al reducir las tasas de rebote asociadas a una mala usabilidad. Para las organizaciones sujetas a mandatos legales de accesibilidad, incumplir este criterio en el Nivel AA supone un riesgo directo de incumplimiento normativo.

Reglas relacionadas de Axe-core

• color-contrast (cobertura parcial): La regla color-contrast de axe-core se centra principalmente en el contraste de texto según WCAG 1.4.3, pero también realiza comprobaciones parciales para elementos no textuales en ciertos contextos. Axe marca componentes de UI como botones y controles de formulario cuando puede determinar de forma programática que el límite visual o el fondo del componente no cumple la relación 3:1. Sin embargo, la cobertura de la regla está explícitamente marcada como parcial para 1.4.11 porque muchos fallos de contraste en elementos no textuales son invisibles para el análisis automatizado. Por ejemplo, el contraste del trazo de un ícono SVG frente a su fondo, o el borde de una casilla de verificación con estilo personalizado implementada con pseudoelementos CSS, no puede extraerse de forma fiable del DOM sin contexto de renderizado. El estilo calculado de un borde CSS puede estar presente en el árbol de accesibilidad, pero el fondo adyacente — especialmente cuando es un degradado, una imagen o un elemento superpuesto — no siempre es computable de forma programática. Por eso axe informa de infracciones de 1.4.11 bajo la regla color-contrast con la designación needs review en muchos casos, lo que significa que la herramienta ha detectado un posible problema pero una persona debe confirmarlo inspeccionando visualmente el elemento y usando una herramienta de análisis de contraste de color para muestrear los píxeles realmente renderizados.

Dado que las herramientas automatizadas solo pueden detectar una fracción de los fallos de contraste no textual, las pruebas manuales son esenciales. Herramientas como Colour Contrast Analyser (TPGi), los selectores de color de las DevTools del navegador o la herramienta Accessible Colors deben utilizarse para muestrear directamente los colores de primer plano y de fondo de la interfaz renderizada. Los escaneos automatizados deben tratarse como un primer paso, no como una auditoría exhaustiva.

Cómo probar

1. Ejecuta un escaneo automatizado con axe DevTools o Lighthouse: Instala la extensión de navegador axe DevTools y ejecuta un escaneo de página completa. En el panel de resultados, filtra los problemas etiquetados con WCAG 1.4.11 o revisa cualquier infracción de color-contrast. Anota cualquier elemento marcado como Needs Review en la categoría de contraste no textual — estos requieren seguimiento manual. En Lighthouse (Chrome DevTools > pestaña Lighthouse), ejecuta una auditoría de Accesibilidad y revisa los hallazgos relacionados con contraste, teniendo en cuenta que la cobertura de Lighthouse también es parcial para elementos no textuales.
2. Inspección manual con un analizador de contraste de color: Descarga y abre la aplicación de escritorio TPGi Colour Contrast Analyser. Usa su herramienta cuentagotas para muestrear el color de primer plano de cada límite de componente de UI (por ejemplo, el borde de un campo de texto, el trazo de un ícono, el relleno de una barra de gráfico) y luego muestrea el color de fondo adyacente. La herramienta mostrará la relación de contraste calculada. Cualquier relación inferior a 3:1 es un fallo. Recorre de forma sistemática todos los controles de formulario interactivos, botones solo con ícono, indicadores de foco y visualizaciones de datos.
3. Navegación con teclado y prueba de indicadores de foco: Recorre toda la página usando solo el teclado con la tecla Tab. Para cada elemento interactivo que recibe el foco, verifica que el indicador de foco (anillo, contorno o cambio de fondo) sea visible. Usa el analizador de contraste para confirmar que el color del indicador de foco alcanza 3:1 frente al fondo del elemento. Prueba en NVDA + Firefox y JAWS + Chrome para confirmar que el elemento recibe el foco en el orden esperado y que el indicador visual no está suprimido por CSS outline: none sin un reemplazo equivalente.
4. Prueba en modos de alto contraste y colores forzados: En Windows, activa el modo de Alto Contraste (Configuración > Facilidad de acceso > Alto contraste) y recarga la página. En navegadores basados en Chromium, abre DevTools, ve a Rendering y habilita la opción Emulate CSS media feature forced-colors: active. Verifica que los límites de los componentes de UI sigan siendo visibles. Aunque el cumplimiento del modo de colores forzados no es estrictamente requerido por 1.4.11, probar en este modo revela elementos que dependen únicamente de pistas de color de bajo contraste.
5. Verifica los objetos gráficos en contexto: Para cada gráfico, ícono, diagrama o imagen informativa, identifica cada segmento o trazo que transmite significado. Usa la herramienta cuentagotas para muestrear colores adyacentes dentro del propio gráfico (por ejemplo, dos segmentos vecinos de un gráfico de pastel) y frente al fondo de la página circundante. Cada parte distinta que comunica información debe alcanzar individualmente 3:1.
6. Revisa todos los estados de los componentes: Los elementos interactivos tienen múltiples estados — por defecto, hover, foco, activo, seleccionado, marcado, error y éxito. Prueba cada estado por separado. El borde de un botón que aprueba en su estado por defecto puede fallar en su estado hover si el color cambia a una variante de bajo contraste.

Cómo corregir

Borde de campo de formulario — Incorrecto

<!-- Fails: light grey border (#cccccc) on white (#ffffff) = 1.6:1 ratio -->
<style>
  .form-input {
    border: 1px solid #cccccc;
    background-color: #ffffff;
    padding: 8px 12px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Borde de campo de formulario — Correcto

<!-- Passes: darker border (#767676) on white (#ffffff) = 4.54:1 ratio, exceeds 3:1 -->
<style>
  .form-input {
    border: 1px solid #767676; /* Darkened to achieve sufficient contrast */
    background-color: #ffffff;
    padding: 8px 12px;
  }
  .form-input:focus {
    outline: 3px solid #005fcc; /* Focus ring at 5.9:1 against white */
    outline-offset: 2px;
  }
</style>
<label for='email'>Email Address</label>
<input type='email' id='email' class='form-input' />

Botón solo con ícono — Incorrecto

<!-- Fails: light grey icon (#aaaaaa) on white (#ffffff) = 2.32:1 ratio -->
<style>
  .icon-btn { background: none; border: none; color: #aaaaaa; }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Botón solo con ícono — Correcto

<!-- Passes: dark icon (#595959) on white (#ffffff) = 7:1 ratio, well above 3:1 -->
<style>
  .icon-btn { background: none; border: none; color: #595959; cursor: pointer; }
  .icon-btn:focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
    border-radius: 4px;
  }
</style>
<button class='icon-btn' aria-label='Delete item'>
  <svg aria-hidden='true' focusable='false' width='24' height='24'>
    <!-- Darker stroke ensures the icon shape is perceivable -->
    <path d='M3 6h18M8 6V4h8v2M19 6l-1 14H6L5 6' stroke='currentColor' stroke-width='2' fill='none'/>
  </svg>
</button>

Casilla de verificación personalizada — Incorrecta

<!-- Fails: custom checkbox uses a light border (#d0d0d0) on white background -->
<style>
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #d0d0d0; /* 1.3:1 ratio against white — fails */
    border-radius: 3px;
    display: inline-block;
  }
</style>
<label>
  <input type='checkbox' style='position:absolute;opacity:0;width:0;height:0' />
  <span class='custom-checkbox-box'></span>
  I agree to the terms
</label>

Casilla de verificación personalizada — Correcta

<!-- Passes: border (#5a5a5a) on white = 7.2:1. Checked state tick also uses sufficient contrast -->
<style>
  .custom-checkbox-input {
    position: absolute; opacity: 0; width: 0; height: 0;
  }
  .custom-checkbox-box {
    width: 18px; height: 18px;
    border: 2px solid #5a5a5a; /* Sufficient contrast against white background */
    border-radius: 3px;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    background-color: #ffffff;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box {
    background-color: #005fcc; /* Blue fill on checked */
    border-color: #005fcc;
  }
  .custom-checkbox-input:checked + .custom-checkbox-box::after {
    content: '';
    display: block;
    width: 10px; height: 6px;
    border-left: 2px solid #ffffff; /* White tick on blue = 5.9:1 */
    border-bottom: 2px solid #ffffff;
    transform: rotate(-45deg) translateY(-2px);
  }
  .custom-checkbox-input:focus-visible + .custom-checkbox-box {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>
<label class='custom-label'>
  <input type='checkbox' class='custom-checkbox-input' />
  <span class='custom-checkbox-box' aria-hidden='true'></span>
  I agree to the terms
</label>

Gráfico de datos — Incorrecto

<!-- Fails: two adjacent pie chart segments use similar light hues with <3:1 contrast -->
<svg viewBox='0 0 200 200' aria-label='Market share chart' role='img'>
  <!-- Segment A: #f5c6cb (light pink) adjacent to Segment B: #ffeeba (light yellow) -->
  <!-- Contrast ratio between these two colors is approximately 1.1:1 — fails -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#f5c6cb' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#ffeeba' />
</svg>

Gráfico de datos — Correcto

<!-- Passes: use high-contrast segment fills OR add a visible border between segments -->
<svg viewBox='0 0 200 200' aria-label='Market share chart: Segment A 50%, Segment B 25%' role='img'>
  <!-- Option 1: Use a dark stroke between segments to separate them at 3:1 against both fills -->
  <path d='M100,100 L100,10 A90,90 0 0,1 190,100 Z' fill='#d63384' stroke='#ffffff' stroke-width='2' />
  <path d='M100,100 L190,100 A90,90 0 0,1 100,190 Z' fill='#0d6efd' stroke='#ffffff' stroke-width='2' />
  <!-- The white (#ffffff) stroke separates the two segments; each fill also has 3:1 against white bg -->
</svg>

Errores comunes

• Usar un borde de un solo píxel que cumple 3:1 pero se vuelve invisible a baja DPI: Incluso un color conforme puede volverse imperceptible si el borde tiene solo 1px de ancho en una pantalla de baja resolución. Usa border: 2px solid o un box-shadow visible junto con un color conforme para garantizar que el límite sea físicamente perceptible.
• Suponer que el fondo siempre es blanco: Cuando un campo de formulario o ícono aparece dentro de una tarjeta o barra lateral con un fondo gris claro (#f5f5f5), el contraste debe medirse frente a ese gris, no frente al blanco. Un borde que aprueba sobre blanco puede fallar sobre un fondo ligeramente teñido.
• Eliminar el contorno de foco predeterminado con outline: none y no proporcionar un equivalente: Este es uno de los fallos más comunes de 1.4.11. Establecer :focus { outline: none; } globalmente destruye la visibilidad del foco para las personas que usan teclado. Sustitúyelo siempre por un estilo de foco personalizado que alcance al menos 3:1 de contraste frente a su fondo.
• Tratar el estado deshabilitado como excusa para omitir todas las comprobaciones de contraste: Los componentes deshabilitados están exentos, pero a veces se marcan elementos como visualmente deshabilitados mediante estilos de bajo contraste sin añadir realmente el atributo disabled o aria-disabled='true'. Un elemento que parece deshabilitado pero sigue siendo interactivo debe seguir cumpliendo 1.4.11.
• Confiar únicamente en el color para diferenciar segmentos de un gráfico sin un trazo separador: Dos segmentos de gráfico adyacentes donde el único diferenciador es el matiz (por ejemplo, azul claro frente a verde claro) pueden fallar si su relación de contraste es inferior a 3:1. Añadir un trazo separador blanco o oscuro de 2px entre segmentos es una solución fiable.
• Aplicar correcciones de contraste solo al estado por defecto y olvidar los estados hover, foco, error y éxito: Cada estado interactivo tiene su propia presentación visual. El borde de un botón que aprueba en el estado por defecto puede cambiar a un color de bajo contraste en hover. Todos los estados deben probarse de forma independiente.
• Incrustar íconos como imágenes de fondo y depender del color CSS para el contraste: Los íconos SVG integrados en HTML responden a color y currentColor, pero los íconos usados como background-image en CSS no pueden recolorearse mediante CSS. Si el propio archivo de imagen del ícono tiene un contraste insuficiente, ninguna corrección CSS puede resolver el problema sin reemplazar el recurso.
• Olvidar que el texto placeholder en campos de entrada no está cubierto por 1.4.11 pero sí está regulado: El texto placeholder entra en 1.4.3 (contraste de texto de 4.5:1), no en 1.4.11. A veces se aplica por error el umbral de 3:1 al texto placeholder, creando un fallo separado y no detectado de 1.4.3.
• Usar transiciones CSS que animan a través de un color intermedio no conforme: Un elemento puede animarse desde un color conforme, pasando por un color intermedio no conforme, hasta otro color conforme. Incluso si los estados inicial y final aprueban, el componente visual es técnicamente no conforme durante la transición. Usa las media queries de prefers-reduced-motion de forma cuidadosa y evita que las transiciones pasen por estados de bajo contraste.
• Ignorar barras de progreso, controles de rango e interruptores de palanca: Estos componentes de UI personalizados se estilizan con frecuencia sin tener en cuenta 1.4.11. La parte rellena de una barra de progreso debe tener 3:1 de contraste frente a su pista; el pomo de un interruptor debe contrastar frente al fondo del interruptor; el pulgar de un control de rango debe contrastar frente a la pista.

Relación con la normativa de accesibilidad de Turquía

La Circular Presidencial n.º 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece requisitos obligatorios de accesibilidad web y móvil para una amplia gama de entidades públicas y privadas que operan en Turquía. La Circular adopta WCAG 2.2 como su estándar técnico normativo, y la conformidad de Nivel AA es el umbral requerido para el cumplimiento.

WCAG 1.4.11 Contraste no textual, como criterio de Nivel AA, es por lo tanto directamente exigible en virtud de la Circular. Las organizaciones sujetas a la regulación deben garantizar que todos los límites de componentes de UI, estados de controles interactivos y objetos gráficos significativos en sus propiedades digitales cumplan el requisito de contraste no textual de 3:1.

Las entidades cubiertas por la Circular Presidencial 2025/10 incluyen instituciones y organismos públicos en todos los niveles de gobierno, plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de salud privados, operadores de telecomunicaciones con 200,000 o más suscriptores, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Para estas organizaciones, no implementar 1.4.11 no es simplemente una carencia de buenas prácticas, sino una no conformidad regulatoria.

El Logotipo de Accesibilidad (Erişilebilirlik Logosu), emitido por el Ministerio de Familia y Servicios Sociales, sirve como marca de certificación visible públicamente para servicios digitales conformes. Para obtener y mostrar este logotipo, una organización debe demostrar plena conformidad de Nivel AA en todos los criterios WCAG 2.2 aplicables, incluido 1.4.11. Dado que muchos portales de gobierno electrónico turcos, interfaces bancarias y formularios de salud utilizan ampliamente controles de formulario y visualizaciones de datos con estilos personalizados, el contraste no textual es un criterio que las personas auditoras probablemente evaluarán de forma especialmente rigurosa durante el proceso de certificación.

Las organizaciones que utilizan el widget de superposición Accsible deben ser conscientes de que la tecnología de superposición puede ayudar a remediar ciertos ajustes de contraste en tiempo de ejecución — como permitir que las personas activen un tema de alto contraste — pero los fallos estructurales persistentes, como un campo de formulario renderizado con un contraste de borde de 1.6:1, deben corregirse a nivel de código fuente para lograr una conformidad genuina y poder optar al Erişilebilirlik Logosu. Combinar correcciones a nivel de código con las funciones de mejora orientadas a las personas de un widget de accesibilidad representa la postura de cumplimiento más defendible según la legislación turca.