WCAG 3.3.5: Ayuda

Qué significa esta regla

\n

El Criterio de Conformidad 3.3.5 Ayuda (Nivel AAA) de las WCAG establece: «Hay ayuda sensible al contexto disponible.» Esto significa que siempre que una página web o aplicación pida a las personas usuarias que introduzcan información, se debe proporcionar ayuda adecuada para aclarar qué se espera. La ayuda debe ser contextual — es decir, debe estar directamente relacionada con el campo, la tarea o el proceso en el que la persona usuaria está trabajando en ese momento, en lugar de ser una página de ayuda genérica escondida en algún lugar de la navegación.

\n

El criterio se aplica a cualquier componente de la interfaz de usuario que requiera entrada: campos de texto, menús desplegables, selectores de fecha, controles de carga de archivos, casillas de verificación, botones de opción y formularios de varios pasos. La ayuda sensible al contexto puede adoptar muchas formas, como instrucciones en línea, etiquetas descriptivas, texto de marcador de posición orientativo, tooltips, iconos de ayuda que despliegan explicaciones, enlaces a artículos de ayuda relevantes o incluso soporte de chat en vivo, siempre que la ayuda esté disponible en proximidad al campo que la requiere.

\n

Se obtiene un aprobado cuando al menos uno de los siguientes elementos está presente para cada entrada que pueda causar confusión a la persona usuaria: una etiqueta claramente redactada que explique por completo la entrada esperada; texto descriptivo complementario adyacente al campo (no solo un marcador de posición, que desaparece al escribir); un enlace de ayuda visible o un tooltip desplegable que proporcione más explicación; o un mecanismo de ayuda fácilmente accesible (como un icono de signo de interrogación) que muestre orientación específica para el contexto actual. La ayuda no tiene que ser idéntica en todos los campos; el requisito clave es que, siempre que una persona usuaria pueda tener dudas sobre qué introducir, la ayuda esté realmente disponible y sea accesible.

\n

Se produce un fallo cuando los campos no proporcionan ninguna explicación de lo que se espera, cuando la ayuda solo está disponible después del envío y de que se produzca un error, cuando los tooltips o el texto de ayuda son inaccesibles para quienes usan teclado o lector de pantalla, o cuando los enlaces de ayuda llevan a una página general de preguntas frecuentes en lugar de a contenido relevante para la entrada específica. Es fundamental entender que confiar únicamente en mensajes de error a posteriori no satisface este criterio: la ayuda debe estar disponible antes o durante la introducción de datos, no solo después de que se haya cometido un error.

\n

WCAG 3.3.5 no define un único método de implementación estricto. Reconoce que la ayuda sensible al contexto puede implementarse de muchas formas válidas, dando flexibilidad a las personas desarrolladoras, pero la intención es inequívoca: las personas usuarias nunca deberían quedarse adivinando qué espera un campo de formulario. No hay excepciones oficiales a este criterio: se aplica de forma universal siempre que se solicite entrada de usuario.

\n\n

Por qué es importante

\n

Los formularios están entre las partes más desafiantes de cualquier interfaz digital. Para las personas con discapacidades cognitivas, incluidas aquellas con dislexia, trastornos por déficit de atención, discapacidades intelectuales o problemas de memoria, los campos de formulario ambiguos pueden ser una barrera insalvable. Sin ayuda clara y contextual, estas personas pueden fracasar repetidamente al intentar completar tareas, experimentar una frustración considerable o abandonar el proceso por completo. Según la Organización Mundial de la Salud, aproximadamente 1 de cada 6 personas en todo el mundo vive con algún tipo de discapacidad significativa, y las discapacidades cognitivas representan una parte sustancial de esta población.

\n

Las personas con baja alfabetización digital o con experiencia limitada en interfaces web también se benefician enormemente de la ayuda sensible al contexto. Una persona que usa por primera vez un portal de servicios electrónicos gubernamentales, una persona mayor que solicita en línea una prestación sanitaria o la propietaria de una pequeña empresa que rellena un formulario de impuestos puede no saber qué formato se espera para un número de identificación fiscal, qué tipos de archivo se aceptan para la carga de documentos o qué diferencia hay entre dos campos con nombres similares. Sin orientación en contexto, estas personas quedan expuestas a errores y a la ansiedad de no saber qué han hecho mal.

\n

Consideremos un escenario concreto: una persona con una discapacidad cognitiva está solicitando un abono de transporte subvencionado a través del portal web de la autoridad municipal de transporte. El formulario pide un «Número de referencia» sin ninguna explicación. La persona tiene varios documentos — su documento nacional de identidad, su tarjeta de transporte y una confirmación de una solicitud anterior — cada uno con identificadores numéricos diferentes. Sin ayuda sensible al contexto que indique qué documento específico o qué formato se espera, es probable que introduzca el número equivocado, active un error de validación y posiblemente se rinda. Si hubiera habido un simple icono de ayuda o una descripción en línea — «Introduzca el número de 10 dígitos que aparece en la esquina superior derecha de su tarjeta de transporte» — toda la interacción habría tenido éxito en el primer intento.

\n

Para las personas que son ciegas o tienen baja visión, la ayuda sensible al contexto también es importante. Los lectores de pantalla pueden anunciar el texto de ayuda asociado, las descripciones aria-describedby o el contenido de ayuda enlazado, pero solo si estos se implementan correctamente. Cuando la ayuda se transmite únicamente de forma visual (como un indicador de color o un icono sin texto accesible), se excluye a quienes usan lectores de pantalla. Garantizar que la ayuda esté presente y sea accesible refuerza la inclusión en todos los grupos de discapacidad.

\n

Más allá de la accesibilidad, la ayuda sensible al contexto mejora la usabilidad general y las tasas de conversión. Los sitios web con instrucciones claras en los formularios experimentan menores tasas de abandono, menos solicitudes de soporte y mayores tasas de finalización de formularios. En los sitios de comercio electrónico en particular, cada punto porcentual de mejora en la finalización del proceso de compra tiene un impacto directo en los ingresos. Los motores de búsqueda también recompensan las páginas con contenido claro y estructurado, y los formularios bien etiquetados y bien descritos contribuyen positivamente a las señales de calidad de la página.

\n\n

Reglas relacionadas de Axe-core

\n

WCAG 3.3.5 requiere pruebas manuales porque su cumplimiento depende de la calidad, relevancia y adecuación contextual del contenido de ayuda, factores que las herramientas automatizadas no pueden evaluar. Un escáner automatizado puede confirmar que existe una etiqueta o que un atributo aria-describedby apunta a un elemento real, pero no puede determinar si el contenido de esa etiqueta o descripción es realmente útil, preciso o suficiente para una entrada determinada.

\n

\n
• Revisión manual — Presencia de ayuda sensible al contexto: Las herramientas automatizadas no pueden evaluar si el texto de ayuda realmente responde a las preguntas probables de la persona usuaria sobre un campo específico. Una herramienta puede detectar que existe un elemento <label>, pero no puede juzgar si «Introduzca su número» es suficientemente descriptivo para un campo que espera un número de registro de IVA con un formato concreto. Las personas que realizan pruebas manuales deben evaluar si cada entrada que podría causar confusión está acompañada de una orientación que reduzca de forma significativa esa confusión.
\n
• Revisión manual — Accesibilidad de la ayuda: Incluso si la ayuda está presente visualmente, las herramientas automatizadas pueden no señalar los casos en los que esa ayuda es inaccesible para la tecnología de asistencia. Por ejemplo, un tooltip que solo se activa al pasar el ratón por encima, sin un equivalente accesible por teclado, supera muchas comprobaciones automatizadas pero falla a las personas usuarias reales. Quienes realizan las pruebas deben verificar que todos los mecanismos de ayuda — tooltips, secciones desplegables, enlaces de ayuda — sean alcanzables y operables mediante teclado y que los lectores de pantalla los anuncien correctamente.
\n
• Revisión manual — Ubicación y proximidad de la ayuda: Los análisis automatizados no pueden evaluar si el texto de ayuda está lo suficientemente cerca del campo relevante como para asociarse de forma significativa con él. Un párrafo de ayuda al final de la página, o en un modal que requiere múltiples interacciones para acceder, puede existir técnicamente pero no cumple con el espíritu de la ayuda sensible al contexto. La revisión manual debe confirmar que la ayuda está disponible en el punto de necesidad.
\n
• Revisión manual — Integridad en formularios complejos: Los formularios complejos de varios pasos introducen desafíos adicionales. Las herramientas automatizadas comprueban campos individuales de forma aislada, pero no pueden evaluar si la ayuda acumulada proporcionada a lo largo de un asistente de varios pasos es suficiente para guiar a una persona usuaria a través de un proceso complejo. Son necesarios recorridos manuales para identificar lagunas en la orientación que solo se hacen evidentes al experimentar el formulario en su conjunto.
\n

\n\n

Cómo hacer las pruebas

\n

\n
1. Ejecute un análisis automatizado de accesibilidad como línea base. Use axe DevTools (extensión del navegador o CLI), Lighthouse en Chrome DevTools o IBM Equal Access Checker en la página que contiene el formulario. Aunque estas herramientas no señalarán directamente infracciones del 3.3.5, sí sacarán a la luz problemas relacionados como etiquetas ausentes (elemento label no asociado a una entrada), objetivos aria-describedby ausentes o implementaciones de tooltips inaccesibles. Resolver primero estos problemas fundamentales garantiza que, cuando se añada ayuda sensible al contexto, también sea técnicamente accesible.
\n
2. Audite manualmente cada campo del formulario para comprobar la disponibilidad de ayuda. Para cada campo de entrada, pregúntese: (a) ¿La etiqueta por sí sola explica por completo qué entrada se requiere, incluidos los requisitos de formato? (b) ¿Hay texto de ayuda complementario visible adyacente al campo? (c) ¿Hay un icono de ayuda, tooltip o sección desplegable que proporcione más orientación? (d) ¿Hay un enlace a contenido de ayuda relevante? Si la respuesta a todas estas preguntas es no, y el campo tiene alguna ambigüedad, esto constituye un incumplimiento del 3.3.5.
\n
3. Pruebe la accesibilidad mediante teclado de todos los mecanismos de ayuda. Recorra el formulario usando solo el teclado (sin ratón). Verifique que cada tooltip, icono de ayuda, descripción desplegable o enlace de ayuda sea alcanzable y activable mediante teclado. Los tooltips deben aparecer al recibir foco, además de al pasar el ratón. Los botones de ayuda deben activarse con Enter o Espacio. Cualquier mecanismo de ayuda que solo sea alcanzable con el ratón falla esta prueba.
\n
4. Pruebe con NVDA + Firefox. Navegue hasta cada campo del formulario usando Tab. Escuche lo que NVDA anuncia para cada campo: ¿anuncia la etiqueta? ¿Anuncia alguna descripción asociada (mediante aria-describedby)? Active cualquier icono de ayuda o tooltip y confirme que se anuncie su contenido. Intente acceder al contenido de ayuda enlazado y verifique que esté relacionado con el campo actual.
\n
5. Pruebe con VoiceOver + Safari (macOS o iOS). Use VoiceOver para navegar por el formulario. En macOS, use Tab para moverse entre campos y escuche el anuncio completo de cada uno. En iOS, use gestos de deslizamiento. Verifique que todo el contenido de ayuda asociado a las entradas se lea en voz alta y que los activadores de ayuda (botones, enlaces) sean accesibles y estén correctamente etiquetados por VoiceOver.
\n
6. Pruebe con JAWS + Chrome. Use el modo de formularios de JAWS (actívelo con Enter cuando esté en un elemento de formulario). Navegue entre campos con Tab y verifique que JAWS lea las instrucciones y descripciones asociadas. Use el cursor virtual de JAWS para comprobar que el contenido de ayuda situado fuera de las asociaciones estándar de etiquetas también sea alcanzable.
\n
7. Realice un recorrido cognitivo. Pida a una persona que no esté familiarizada con el formulario (o simule esto revisando el formulario después de una pausa) que intente completarlo sin ninguna orientación externa. Anote cada punto en el que dude, haga una pregunta o cometa un error debido a expectativas poco claras. Cada uno de estos puntos es un candidato para mejorar la ayuda sensible al contexto según el 3.3.5.
\n

\n\n

Cómo corregirlo

\n

Campo de texto ambiguo sin explicación — Incorrecto

\n

<!-- No se proporciona ayuda para un campo ambiguo que espera un formato específico -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input type='text' id='tc-kimlik' name='tc-kimlik'>

\n

Campo de texto ambiguo con ayuda en línea — Correcto

\n

<!-- La descripción en línea asociada mediante aria-describedby ofrece orientación sobre el formato antes de que la persona usuaria escriba -->\n<label for='tc-kimlik'>TC Kimlik No</label>\n<input\n  type='text'\n  id='tc-kimlik'\n  name='tc-kimlik'\n  aria-describedby='tc-kimlik-help'\n  autocomplete='off'\n  maxlength='11'\n>\n<p id='tc-kimlik-help'>\n  Nüfus cüzdanınızda yer alan 11 haneli TC Kimlik Numaranızı giriniz.\n  (Enter your 11-digit Turkish National ID number as shown on your ID card.)\n</p>

\n\n

Icono de ayuda con tooltip inaccesible para personas usuarias de teclado — Incorrecto

\n

<!-- Tooltip que solo se muestra al pasar el ratón; las personas usuarias de teclado y de lectores de pantalla no pueden acceder a él -->\n<label for='iban'>IBAN <span class='help-icon' title='What is IBAN?'>?</span></label>\n<input type='text' id='iban' name='iban'>

\n

Icono de ayuda con tooltip accesible para todas las personas usuarias — Correcto

\n

<!-- Botón con aria-expanded controla un panel de ayuda; accesible mediante teclado y lectores de pantalla -->\n<label for='iban'>IBAN</label>\n<button\n  type='button'\n  aria-expanded='false'\n  aria-controls='iban-help'\n  class='help-toggle'\n  aria-label='Help: What is an IBAN?'\n>\n  ?\n</button>\n<input type='text' id='iban' name='iban' aria-describedby='iban-help'>\n<div id='iban-help' hidden>\n  <p>\n    IBAN (International Bank Account Number) is a 26-character code starting\n    with "TR" used to identify your Turkish bank account. You can find it\n    in your bank's mobile app under Account Details.\n  </p>\n</div>\n<!-- JavaScript alterna aria-expanded y el atributo hidden al hacer clic en el botón o al pulsar una tecla -->

\n\n

Formulario complejo de varios pasos sin orientación a nivel de paso — Incorrecto

\n

<!-- Paso 2 de una solicitud de 4 pasos sin explicación de qué documentos se necesitan -->\n<h2>Step 2: Upload Documents</h2>\n<label for='doc-upload'>Upload File</label>\n<input type='file' id='doc-upload' name='doc-upload'>

\n

Formulario complejo de varios pasos con ayuda contextual por paso — Correcto

\n\n

(Content truncated due to token limit — please retry this article.)