WCAG 1.3.3: Características sensoriales

Qué Significa Esta Regla

El Criterio de Éxito 1.3.3 de las WCAG — Características sensoriales (Nivel A) establece que las instrucciones proporcionadas para comprender y operar el contenido no deben depender únicamente de características sensoriales de los componentes, como la forma, el tamaño, la ubicación visual, la orientación o el sonido. En otras palabras, si tu interfaz indica a una persona usuaria que interactúe con algo haciendo referencia solo a cómo se ve, dónde aparece en la pantalla o cómo suena, esa instrucción carecerá de sentido para quienes no pueden percibir esas propiedades sensoriales en particular.

La palabra clave aquí es únicamente. El criterio no prohíbe el uso de referencias sensoriales: prohíbe que sean el único medio de identificación. Una instrucción como "haz clic en el botón redondo verde de la izquierda" falla cuando una persona usuaria no puede distinguir el verde, no puede ver la forma del botón o no puede determinar izquierda y derecha debido a un diseño con reflujo. Sin embargo, "haz clic en el botón Enviar (el botón redondo verde de la izquierda)" cumple, porque la etiqueta de texto "Enviar" proporciona un identificador no sensorial que funciona independientemente del color, la forma y la posición.

Las instrucciones afectadas por este criterio incluyen cualquier contenido de texto, audio o visual que indique a las personas usuarias que realicen una acción o localicen información. Algunos patrones de fallo comunes incluyen:

• "Haz clic en el botón de la derecha para continuar": depende únicamente de la ubicación visual.
• "Selecciona el icono cuadrado para abrir la configuración": depende únicamente de la forma.
• "Los campos obligatorios se muestran en rojo": depende únicamente del color.
• "Cuando escuches la campanilla, pasa al siguiente paso": depende únicamente del sonido.
• "Toca el recuadro grande para expandir la sección": depende únicamente del tamaño.

Una instrucción que cumple siempre incluye al menos un identificador no sensorial — normalmente una etiqueta de texto, un nombre programático o un encabezado — de modo que las personas que dependen de tecnología de apoyo o que operan en condiciones donde las señales sensoriales no están disponibles puedan seguir las indicaciones. Ten en cuenta que este criterio se refiere específicamente a las instrucciones; no exige rediseñar todos los elementos de la interfaz, pero sí exige que cualquier orientación textual o hablada sobre esos elementos sea perceptible sin discriminación sensorial.

No hay excepciones oficiales definidas dentro del propio 1.3.3, aunque el documento Understanding aclara que el contenido que utiliza características sensoriales además de identificadores no sensoriales cumple plenamente. El criterio también complementa, pero es distinto de 1.4.1 (Uso del color), que aborda específicamente el color por sí solo; 1.3.3 tiene un alcance más amplio que cubre todas las modalidades sensoriales.

Por Qué Importa

Las instrucciones basadas solo en lo sensorial crean barreras importantes para una amplia variedad de personas usuarias. Considera cada grupo afectado:

Personas ciegas y con baja visión dependen de lectores de pantalla o software de magnificación. Cuando una instrucción dice "haz clic en el icono en la esquina superior derecha", una persona usuaria de lector de pantalla que navega por orden de tabulación o por estructura de encabezados no tiene ningún concepto de "esquina superior derecha" en el diseño visual. De manera similar, una persona con baja visión grave que ha hecho zoom al 400% puede ver solo una pequeña parte de la pantalla a la vez, lo que hace que referencias posicionales como "panel izquierdo" o "sección inferior" sean completamente poco fiables. Según la Organización Mundial de la Salud, aproximadamente 2,2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual, lo que convierte a este en uno de los grupos más afectados.

Personas con daltonismo — que afecta aproximadamente a 1 de cada 12 hombres y 1 de cada 200 mujeres — no pueden distinguir ciertos pares de colores. Una instrucción que diga "los campos resaltados en rojo son obligatorios" es invisible como señal distintiva para alguien con daltonismo rojo-verde. Aunque 1.4.1 aborda esto para el propio elemento de la interfaz, 1.3.3 garantiza que el texto de las instrucciones también proporcione una alternativa.

Personas sordas y con discapacidad auditiva se ven afectadas por señales solo de audio. Si una plataforma de aprendizaje en línea indica a las personas usuarias que "continúen cuando escuchen la campana", quienes no pueden oír la campana quedan excluidas. Este patrón aparece en presentaciones interactivas, tutoriales en vídeo y evaluaciones cronometradas.

Personas con discapacidades cognitivas y de aprendizaje pueden tener dificultades con el lenguaje direccional, especialmente cuando su tecnología de apoyo presenta el contenido en forma lineal, eliminando la posición visual. Una persona que utiliza un dispositivo de pulsador o un sistema de seguimiento ocular también navega en secuencias que pueden no tener relación con el diseño espacial bidimensional que imaginó una persona diseñadora vidente.

Considera un escenario concreto del mundo real: un portal de servicios electrónicos del gobierno turco indica a la ciudadanía que "rellene los campos delineados en azul y luego pulse el botón triangular para enviar su solicitud". Una persona ciega que navega por campos de formulario escucha las etiquetas de los campos mediante su lector de pantalla, pero no tiene forma de saber qué campos están delineados en azul ni puede identificar un botón por su forma triangular. El proceso de solicitud queda efectivamente bloqueado. Añadir las etiquetas reales de los campos (por ejemplo, "Nombre, Número de identificación y Fecha de nacimiento son obligatorios") y la etiqueta de texto del botón ("Enviar solicitud") elimina la barrera de inmediato.

Más allá de la accesibilidad, eliminar las instrucciones basadas solo en lo sensorial mejora la usabilidad para todas las personas. Los diseños responsivos hacen que el contenido fluya de forma diferente, de modo que las referencias posicionales se vuelven inexactas en dispositivos móviles. El modo oscuro o los temas de alto contraste cambian la representación del color. Los asistentes de voz que leen en voz alta las instrucciones de la página eliminan todo contexto visual. Construir instrucciones en torno a etiquetas programáticas estables en lugar de propiedades sensoriales transitorias hace que el contenido sea más sólido en todos los dispositivos y contextos, lo que también supone un beneficio directo para el SEO y el mantenimiento.

Reglas Relacionadas de Axe-core

WCAG 1.3.3 requiere pruebas manuales porque las herramientas automatizadas no pueden interpretar de forma fiable el significado o la intención de las instrucciones en lenguaje natural. Un motor de análisis estático puede detectar que existe un botón o que se utiliza un color, pero no puede leer un párrafo de texto instructivo, entender que se refiere a un botón y luego determinar si esa referencia es exclusivamente sensorial. Se trata de un juicio semántico y contextual que requiere revisión humana.

• Se requiere revisión manual: no existe una regla específica de axe-core para 1.3.3. Reglas de axe-core como color-contrast y label pueden sacar a la luz problemas relacionados (por ejemplo, un botón sin nombre accesible), pero abordan criterios diferentes. Para 1.3.3, una persona evaluadora debe leer cada frase instructiva de la página, identificar cualquier referencia sensorial (forma, color, tamaño, ubicación, orientación, sonido) y verificar que al menos un identificador no sensorial acompañe cada referencia. Las herramientas automatizadas no marcarán una frase como "haz clic en el botón verde de abajo" como infracción porque analizar la intención del lenguaje natural está más allá de la automatización basada en reglas actual.
• Por qué la automatización falla aquí: Ten en cuenta que "haz clic en el botón grande" contiene la palabra "botón", que una herramienta automatizada podría interpretar como referencia a un rol accesible. Pero la instrucción sigue dependiendo únicamente del tamaño ("grande") para distinguir este botón de otros. Las herramientas automatizadas no pueden determinar si "grande" es la única característica distintiva o si solo hay un botón en la página (lo que haría que "grande" fuera redundante pero no perjudicial). El juicio humano es esencial para evaluar estos matices en contexto.
• Reglas de axe complementarias para ejecutar junto con la revisión manual: Ejecutar comprobaciones de color-contrast, label, button-name y aria-label ayudará a garantizar que los elementos de la interfaz a los que se hace referencia en las instrucciones tengan realmente nombres programáticos, un requisito previo para redactar instrucciones no sensoriales. Si un botón no tiene nombre accesible, ninguna instrucción puede referirse a él de forma significativa sin recurrir a señales sensoriales.

Cómo Probar

1. Ejecuta primero un análisis automatizado (axe DevTools o Lighthouse): Abre la página en Chrome, activa la extensión axe DevTools y ejecuta un análisis de página completa. Aunque ninguna regla se asigna directamente a 1.3.3, revisa cualquier problema marcado en las categorías de "color", "label" y "name". Estos resultados proporcionan una línea base: si los elementos de la interfaz carecen de nombres accesibles, es casi seguro que el texto de las instrucciones que los menciona está dependiendo de señales sensoriales. Exporta los resultados y anota todos los elementos interactivos sin etiquetas programáticas.
2. Identifica manualmente todo el texto instructivo: Lee cada frase de la página que indique a una persona usuaria que realice una acción o localice información. Esto incluye textos de ayuda, indicaciones en formularios, tooltips, superposiciones de tutoriales, mensajes de error y flujos de incorporación. Crea una lista de cada instrucción y resalta cualquier referencia sensorial: palabras de color (rojo, azul, verde), palabras de forma (redondo, cuadrado, triangular), palabras de tamaño (grande, pequeño, grande), palabras posicionales (izquierda, derecha, arriba, abajo, encima, debajo, esquina), palabras de orientación (horizontal, vertical) y referencias a sonido (campanilla, pitido, sonido de alerta).
3. Evalúa cada referencia sensorial en busca de identificadores adicionales no sensoriales: Para cada referencia sensorial encontrada, determina si también hay presente un identificador no sensorial. Un identificador no sensorial incluye una etiqueta de texto que coincida con la etiqueta visible del elemento o su nombre accesible, un encabezado, un paso numerado, un rol programático único o una etiqueta ARIA. Si la única forma de identificar el elemento mencionado es mediante la percepción sensorial, la instrucción no cumple 1.3.3.
4. Prueba con un lector de pantalla (NVDA + Firefox): Navega por la página usando solo el teclado y NVDA. Recorre con la tecla Tab todos los elementos interactivos y escucha cómo NVDA anuncia cada uno. Luego, lee el texto instructivo de la página y pregúntate: ¿podría una persona usuaria que solo escucha estos anuncios seguir las instrucciones? Si una instrucción dice "haz clic en el icono de la derecha" pero NVDA anuncia el elemento como "Configuración, botón", entonces la referencia posicional es superflua, pero la etiqueta hace que la instrucción sea navegable. Si NVDA anuncia el elemento como "botón" sin nombre, la instrucción que depende de la posición visual falla por completo.
5. Prueba con VoiceOver + Safari (macOS/iOS): Activa VoiceOver y navega por la página. Usa el rotor para explorar por botones, enlaces y controles de formulario. Verifica que cada elemento mencionado en una instrucción sea alcanzable e identificable solo por su nombre anunciado, sin depender de su posición en el diseño visual.
6. Prueba con JAWS + Chrome: Abre la página en Chrome con JAWS activo. Usa el modo Forms para navegar por los campos de entrada y escucha los anuncios de los campos. Contrasta con cualquier instrucción a nivel de formulario que use el color o la posición para indicar campos obligatorios.
7. Prueba en modos de alto contraste y oscuro: Cambia el sistema operativo a modo de alto contraste y recarga la página. Las instrucciones codificadas por color que se refieren a colores específicos pueden volverse ambiguas o invisibles cuando cambia la representación del color. Esto ayuda a sacar a la luz una dependencia oculta del color como única señal sensorial.
8. Prueba en una vista móvil con zoom o reflujo: Redimensiona la ventana del navegador a 320px de ancho o usa un dispositivo móvil. Las instrucciones que utilizan lenguaje posicional como "barra lateral izquierda" o "navegación superior" deberían seguir teniendo sentido cuando el diseño se ha reestructurado a una sola columna.

Cómo Corregir

Instrucciones de Campos de Formulario Solo por Color — Incorrecto

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Instrucciones de Campos de Formulario Solo por Color — Correcto

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

Referencia Posicional a un Botón — Incorrecto

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Referencia Posicional a un Botón — Correcto

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

Navegación con Iconos Solo por Forma — Incorrecto

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Navegación con Iconos Solo por Forma — Correcto

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

Señal de Progreso Solo por Audio — Incorrecto

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

Señal de Progreso Solo por Audio — Correcto

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

Errores Comunes

• Escribir "el botón rojo" o "el campo verde" como único identificador en instrucciones de formularios o textos de ayuda, sin proporcionar también la etiqueta visible del botón o el nombre del campo: esto incumple tanto 1.3.3 como 1.4.1.
• Usar frases posicionales como "el menú de la izquierda" o "el panel de arriba" en documentación de ayuda o flujos de incorporación sin nombrar el menú o el panel, lo que hace que las instrucciones sean inútiles después de que el reflujo responsivo colapse el diseño a una sola columna.
• Describir iconos solo por su forma ("haz clic en el botón triangular de reproducción") en lugar de usar el nombre accesible o la etiqueta del icono, que una persona usuaria de lector de pantalla podría localizar realmente mediante la navegación con teclado.
• Indicar campos de formulario obligatorios exclusivamente mediante el color del borde o el color de fondo en instrucciones en línea ("los campos naranjas deben rellenarse") sin un símbolo, un sufijo en la etiqueta o el atributo aria-required='true' para transmitir la misma información de forma programática.
• Colocar retroalimentación solo de audio para procesos interactivos (cargas de archivos, envíos de formularios, expiración de temporizadores) sin una actualización de estado de texto visible correspondiente usando role='status' o aria-live='polite'.
• Usar el tamaño como única señal distintiva: instrucciones como "haz clic en la tarjeta grande para expandir" fallan cuando la persona usuaria hace zoom, cuando las tarjetas se representan con el mismo tamaño en ventanas más pequeñas o cuando una persona usuaria de lector de pantalla no tiene ningún concepto de tamaños relativos de tarjetas en el DOM.
• Depender de señales de orientación como "desliza horizontalmente para navegar" sin proporcionar un método de interacción alternativo y una etiqueta no basada en la orientación para el carrusel o deslizador descrito.
• Olvidar que los mensajes de error también son instrucciones: un error que dice "los campos resaltados a continuación contienen errores" depende del resaltado visual y de la proximidad posicional, y será inútil para una persona usuaria de lector de pantalla a menos que cada campo erróneo también se nombre explícitamente en el mensaje de error.
• Suponer que añadir texto alternativo al icono corrige la instrucción: si el texto de las instrucciones sigue diciendo solo "haz clic en el icono circular", que el icono tenga texto alternativo en el elemento de imagen no hace que el texto de las instrucciones cumpla; el propio texto debe incluir un identificador no sensorial.
• Descuidar las instrucciones inyectadas dinámicamente en aplicaciones de una sola página: los tooltips, modales y pasos de asistentes que se inyectan mediante JavaScript a menudo contienen indicaciones basadas solo en lo sensorial que escapan a la revisión de control de calidad porque no son visibles en un análisis estático de la página.

Relación con la Normativa de Accesibilidad de Turquía

La Circular Presidencial 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 para una amplia gama de entidades públicas y privadas que operan en Turquía. La circular exige la conformidad con las WCAG 2.1 Nivel AA como estándar base, y la WCAG 1.3.3 — al ser un criterio de Nivel A — es por tanto plenamente obligatoria para todas las entidades cubiertas.

Las entidades cubiertas por la circular incluyen instituciones y organismos públicos, plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de servicios sanitarios, empresas de telecomunicaciones con 200.000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Las instituciones públicas deben lograr el cumplimiento total en el plazo de un año desde la fecha de publicación de la circular, mientras que a las entidades del sector privado se les concede un plazo de dos años.

La WCAG 1.3.3 es especialmente relevante para los servicios digitales turcos dado el uso generalizado de guías de formularios codificadas por color y patrones de navegación solo con iconos en los portales de gobierno electrónico, aplicaciones bancarias y flujos de pago de comercio electrónico turcos. Por ejemplo, un formulario de solicitud en línea de una institución pública que indique a la ciudadanía que "rellene los campos marcados en rojo" y envíe la solicitud "pulsando el botón de la esquina inferior derecha" estaría en violación directa de 1.3.3 y constituiría un incumplimiento de la Circular Presidencial. De manera similar, la interfaz web móvil de un banco que guíe a las personas usuarias a través de transacciones de varios pasos utilizando solo señales posicionales y de color tendría que revisarse antes del plazo de dos años para el sector privado.

El incumplimiento conlleva riesgos reputacionales y legales a medida que el entorno regulatorio de Turquía en torno a la accesibilidad digital madura. Las entidades cubiertas deberían tratar el cumplimiento de 1.3.3 no como una corrección editorial menor, sino como una revisión sistémica de todo el contenido instructivo — incluidos textos de ayuda, mensajes de error, flujos de incorporación y documentación de soporte — para garantizar que las referencias sensoriales vayan siempre acompañadas de identificadores estables, programáticos y basados en texto. El SDK de superposición de Accsible puede ayudar a detectar y remediar muchos problemas relacionados, aunque la revisión manual del contenido requerida por 1.3.3 debe, en última instancia, ser realizada por una persona auditora cualificada que trabaje junto con las herramientas automatizadas.