WCAG 3.3.3: Sugerencia de error

Qué Significa Esta Regla

WCAG 3.3.3 Sugerencia de Error es un criterio de Nivel AA bajo el principio de Comprensible. Se basa directamente en 3.3.1 (Identificación de Errores), que exige que los errores se identifiquen en texto. Sugerencia de Error va más allá: cuando un error de entrada se detecta automáticamente, la interfaz también debe sugerir cómo puede corregirlo la persona usuaria, siempre que esa sugerencia no comprometa la seguridad o el propósito del contenido.

La distinción clave aquí es entre identificación de errores y sugerencia de errores. Decirle a una persona usuaria "Tu fecha de nacimiento no es válida" es identificación. Decirle "Tu fecha de nacimiento no es válida; introduce una fecha en formato DD/MM/AAAA" es una sugerencia. Ambos son necesarios según sus respectivos criterios, pero Sugerencia de Error exige que, siempre que sea posible, un mensaje de error vaya acompañado de una orientación correctiva y accionable.

El criterio se aplica siempre que un error de entrada se detecta automáticamente; es decir, cuando la lógica de validación del lado del cliente o del servidor determina que un valor enviado o introducido no cumple los criterios esperados. Se aplica a todos los controles de formulario: campos de texto, selectores, casillas de verificación, botones de opción, selectores de fecha, campos de carga de archivos y cualquier componente interactivo que recopile datos de la persona usuaria.

Qué se considera un cumplimiento: El mensaje de error se presenta en texto (no solo mediante color o icono), identifica claramente el campo con error y proporciona una orientación específica sobre cómo corregirlo. Por ejemplo: "La contraseña debe tener al menos 8 caracteres e incluir una letra mayúscula" en lugar de solo "Contraseña no válida". La sugerencia debe aparecer cerca del campo, estar asociada programáticamente a él (mediante aria-describedby o similar) y ser perceptible por las tecnologías de apoyo.

Qué se considera un incumplimiento: Cualquier mensaje de error que simplemente indique que se ha producido un error sin explicar qué está mal o cómo solucionarlo. Mensajes genéricos como "Error", "Entrada no válida" o "Campo obligatorio" sin más contexto incumplen este criterio. Los errores comunicados solo mediante un borde rojo o un icono de advertencia, sin texto descriptivo, también incumplen.

Excepciones definidas: El criterio incluye dos excepciones explícitas en las que no se requiere una sugerencia. En primer lugar, si proporcionar la sugerencia pone en peligro la seguridad; por ejemplo, en un formulario de inicio de sesión donde explicar exactamente por qué falló una contraseña (contraseña incorrecta frente a nombre de usuario incorrecto) podría facilitar ataques de fuerza bruta. En segundo lugar, si proporcionar la sugerencia pone en peligro el propósito del contenido; por ejemplo, en un cuestionario educativo donde revelar la respuesta correcta anula el objetivo de evaluación. Estas excepciones son limitadas y no deben utilizarse para eludir el requisito en contextos de formularios estándar.

Por Qué Es Importante

Sugerencia de Error existe porque completar formularios es una de las actividades cognitivamente más exigentes que las personas realizan en la web, y también una de las más trascendentales: los errores en formularios de pago, solicitudes de prestaciones gubernamentales, formularios de admisión médica o portales bancarios pueden tener consecuencias reales para las personas usuarias que no pueden entender qué salió mal o cómo recuperarse.

Discapacidades cognitivas: Las personas con dislexia, TDAH, dificultades de aprendizaje o alfabetización limitada pueden tener dificultades para descifrar mensajes de error vagos y relacionarlos con el campo específico o el formato requerido. Sin una sugerencia correctiva clara, pueden abandonar el formulario por completo o enviar información incorrecta. Según la Organización Mundial de la Salud, aproximadamente 1 de cada 6 personas en el mundo —más de 1,3 mil millones— vive con algún tipo de discapacidad, y las discapacidades cognitivas se encuentran entre las categorías más prevalentes y menos atendidas.

Personas ciegas y con baja visión: Las personas usuarias de lectores de pantalla dependen por completo de descripciones textuales para entender los errores de validación. Cuando un mensaje de error dice solo "No válido" y no proporciona ninguna sugerencia, la persona usuaria no tiene forma de determinar qué significa "no válido" para ese campo. No puede echar un vistazo a etiquetas adyacentes, texto de marcador de posición o pistas de formato visual para deducir el formato esperado. Una sugerencia clara, asociada programáticamente a la entrada mediante aria-describedby, es el único canal de información fiable.

Personas con discapacidad motriz: Las personas que dependen de acceso por pulsadores, control por voz o dispositivos de entrada alternativos realizan un esfuerzo físico significativo al completar formularios. Tener que volver a navegar hasta un formulario tras un envío fallido —sin entender qué debe cambiar— impone un coste desproporcionado. Las sugerencias claras reducen la carga de reintroducción y el número de ciclos de envío fallidos.

Personas que no dominan el idioma y personas mayores: Las personas que no dominan el idioma del formulario, o que tienen menos experiencia con las convenciones web, también se benefician enormemente de sugerencias correctivas explícitas. Un mensaje como "Introduce tu número de teléfono sin espacios ni guiones, p. ej. 05321234567" elimina la ambigüedad para quienes de otro modo quizá nunca logren completar el formulario con éxito.

Escenario del mundo real: Considera a una persona ciudadana turca que solicita una prestación de asistencia social a través de un portal de gobierno electrónico. La solicitud requiere un Número de Identidad TR (TC Kimlik Numarası), un formato específico de 11 dígitos. Si la persona introduce 10 dígitos y solo recibe el mensaje "TC Kimlik Numarası hatalı" (el Número de Identidad TC es incorrecto), una persona con discapacidad cognitiva, una persona mayor o una persona usuaria de lector de pantalla puede no saber si el número es demasiado corto, contiene un carácter no válido o tiene un problema de formato. Añadir "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901" (el Número de Identidad TC debe tener 11 dígitos, p. ej., 12345678901) resuelve inmediatamente la ambigüedad y permite que la persona se autocorrija.

Beneficios de usabilidad y conversión: Más allá de la accesibilidad, el abandono de formularios es una métrica empresarial crítica. La investigación muestra de forma consistente que los mensajes de error poco claros se encuentran entre las principales razones por las que las personas abandonan procesos de pago en comercio electrónico y flujos de registro. Las sugerencias de error específicas y accionables reducen las tasas de abandono de formularios y mejoran las tasas de finalización para todas las personas usuarias, lo que convierte este criterio en un sólido argumento empresarial además de un requisito de accesibilidad.

Reglas Relacionadas de Axe-core

WCAG 3.3.3 requiere pruebas manuales porque las herramientas automatizadas no pueden evaluar la calidad o integridad del texto de los mensajes de error. Un escáner automatizado puede detectar que existe un mensaje de error y que está asociado programáticamente a un campo de formulario, pero no puede determinar si el mensaje realmente proporciona una sugerencia correctiva útil. Esto requiere juicio humano para evaluar si el texto es específico, accionable y suficiente para guiar a la persona usuaria hacia una entrada válida.

• Revisión manual — calidad del contenido del mensaje de error: Las personas evaluadoras deben activar manualmente cada condición de validación (enviar un campo obligatorio vacío, introducir datos en un formato incorrecto, exceder los límites de caracteres, etc.) y evaluar cada mensaje de error resultante. La persona evaluadora se pregunta: ¿este mensaje le indica a la persona usuaria no solo que se produjo un error, sino específicamente qué debe hacer para corregirlo? Si el mensaje es genérico ("No válido", "Error", "Por favor revisa este campo"), incumple 3.3.3 independientemente de que esté expuesto programáticamente.
• Revisión manual — asociación programática: Las personas evaluadoras deben verificar que el texto de la sugerencia de error esté vinculado programáticamente al campo de entrada correspondiente mediante aria-describedby, regiones aria-live o asociación en línea, de modo que los lectores de pantalla lo anuncien sin requerir navegación adicional. Esto se solapa parcialmente con reglas de axe como label y aria-input-field-name, pero el propio texto de la sugerencia no es comprobado por estas reglas.
• Revisión manual — validez de la excepción de seguridad: Las personas evaluadoras deben verificar que cualquier formulario que omita sugerencias correctivas por motivos de seguridad (por ejemplo, formularios de inicio de sesión) realmente cumpla con la excepción de seguridad, y que esta excepción no se utilice para evitar el requisito en campos no sensibles.
• Parcialmente automatizado — regla label: Aunque la regla label de axe-core comprueba que las entradas de formulario tengan nombres accesibles, no comprueba si los mensajes de error proporcionan sugerencias correctivas. Puede sacar a la luz etiquetas faltantes que agravarían el problema de sugerencia de error, y corregir los problemas de etiquetas es un requisito previo para una implementación eficaz de sugerencias de error.

Cómo Probar

1. Línea base de escaneo automatizado: Ejecuta axe DevTools o Lighthouse en la página que contiene el formulario. Toma nota de cualquier infracción existente relacionada con etiquetas de formulario, roles ARIA o identificación de errores (3.3.1). Estas deben resolverse primero, ya que son requisitos previos para una sugerencia de error eficaz. Los escaneos automatizados no señalarán sugerencias faltantes; solo establecen la base estructural.
2. Activa todas las condiciones de validación: Para cada campo del formulario, activa deliberadamente todos los posibles estados de error: envía un campo obligatorio vacío, introduce datos en un formato incorrecto (formato de fecha erróneo, correo electrónico no válido, contraseña demasiado corta, valor no numérico en un campo numérico) y excede cualquier límite de caracteres. Documenta cada mensaje de error que aparezca.
3. Evalúa la calidad de la sugerencia: Para cada mensaje de error, pregúntate: (a) ¿Identifica el campo específico? (b) ¿Explica qué está mal? (c) ¿Proporciona una orientación accionable sobre cómo corregir la entrada? Un mensaje que responde a las tres preguntas cumple 3.3.3. Un mensaje que solo responde a (a) cumple 3.3.1 pero incumple 3.3.3.
4. Pruebas con lector de pantalla usando NVDA + Firefox: Navega hasta el formulario usando Tab. Introduce un valor no válido. Envía o mueve el foco. Escucha lo que anuncia NVDA. Verifica que el texto de la sugerencia de error se lea en voz alta automáticamente (mediante una región aria-live o gestión del foco hacia el error) sin requerir que la persona usuaria lo busque manualmente.
5. Pruebas con lector de pantalla usando VoiceOver + Safari (macOS/iOS): Realiza los mismos pasos. Usa VO+Flecha derecha para leer el campo y su descripción asociada. Confirma que el texto de la sugerencia se anuncia como parte de la descripción accesible del campo, no solo como texto cercano que podría omitirse.
6. Pruebas con lector de pantalla usando JAWS + Chrome: Después de enviar un formulario con errores, confirma que JAWS lee la sugerencia de error ya sea mediante gestión del foco (foco movido al resumen de errores) o mediante actualizaciones de regiones aria-live. Usa el cursor virtual de JAWS para navegar hasta el campo y confirma que la sugerencia forma parte de la descripción del campo.
7. Navegación solo con teclado: Sin lector de pantalla, navega por el formulario usando solo Tab, Shift+Tab y Enter. Verifica que las sugerencias de error sean visibles en el área de visualización, que no estén ocultas fuera de la pantalla ni tapadas por otros elementos, cuando el campo recibe el foco tras un envío fallido.
8. Verifica las excepciones de seguridad: Para formularios de inicio de sesión y autenticación, confirma que la omisión de sugerencias específicas sea intencional y esté documentada, y que la excepción de seguridad se limite al mínimo de campos necesario.

Cómo Corregir

Mensaje de error genérico — Incorrecto

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

Mensaje de error genérico — Correcto

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

Validación de contraseña sin orientación de formato — Incorrecto

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

Validación de contraseña sin orientación de formato — Correcto

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

Campo de fecha con error de formato ambiguo — Incorrecto

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

Campo de fecha con error de formato ambiguo — Correcto

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

Formulario con varios campos y resumen de errores del lado del servidor — Incorrecto

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

Formulario con varios campos y resumen de errores del lado del servidor — Correcto

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

Errores Comunes

• Usar placeholder como sustituto de las sugerencias de error: El texto de marcador de posición desaparece en cuanto la persona empieza a escribir y no es anunciado de forma fiable por los lectores de pantalla como un error. Nunca confíes solo en el texto de marcador de posición para comunicar qué formato se requiere después de que se haya producido un error.
• Mostrar mensajes de error solo en una notificación tipo "toast" que desaparece tras unos segundos: Las notificaciones transitorias no son perceptibles para todas las personas usuarias: las personas usuarias de lectores de pantalla pueden perderse el anuncio, y el mensaje desaparece antes de que una persona lectora lenta pueda procesarlo. Las sugerencias de error deben persistir hasta que el error se corrija.
• Usar aria-invalid='true' sin que aria-describedby apunte al texto de la sugerencia: Establecer aria-invalid indica que un campo tiene un error, pero sin que aria-describedby enlace con el elemento de sugerencia, los lectores de pantalla no leerán el texto de la sugerencia cuando el campo reciba el foco.
• Proporcionar la sugerencia solo en el diseño visual (por ejemplo, un tooltip al pasar el ratón) y no en el DOM: Los tooltips que aparecen solo al pasar el ratón son inaccesibles para las personas que usan teclado y para las personas usuarias de lectores de pantalla. El texto de la sugerencia debe estar presente en el DOM y asociado programáticamente al campo.
• Usar solo color o iconografía para indicar qué campo tiene un error: Un borde rojo o un icono de advertencia no constituyen una sugerencia de error. La sugerencia debe ser una descripción textual que explique la acción correctiva, no un indicador visual.
• Redactar sugerencias que identifican el problema pero no la solución: "Tu contraseña es demasiado corta" identifica el error pero no sugiere cómo solucionarlo. "Tu contraseña debe tener al menos 8 caracteres" proporciona la orientación correctiva necesaria. Ambas partes son necesarias para cumplir 3.3.3.
• Aplicar la excepción de seguridad de forma demasiado amplia: La excepción de seguridad se aplica de forma limitada a situaciones en las que proporcionar una sugerencia comprometería realmente la seguridad, normalmente restringida a campos de autenticación. No se aplica a campos estándar de formulario como nombres, direcciones o números de teléfono, donde los errores genéricos no están justificados.
• Colocar la sugerencia de error después del botón de envío o lejos del campo: Las sugerencias de error deben estar visual y programáticamente próximas al campo que describen. Colocar todos los errores al final de un formulario largo, sin incluir también sugerencias en línea en cada campo, obliga a las personas usuarias a cambiar de contexto y recordar qué sugerencia se aplica a qué campo.
• No mover el foco al resumen de errores tras un envío fallido del lado del servidor: Cuando una página se recarga después de un envío fallido, el foco suele volver a la parte superior de la página. Sin una gestión programática del foco hacia el resumen de errores o hacia el primer campo con error, las personas usuarias de lectores de pantalla deben navegar por toda la página para descubrir qué salió mal.
• Usar un lenguaje vago como "Por favor revisa tu entrada" o "Algo salió mal": Estos mensajes no proporcionan información sobre qué está mal o cómo solucionarlo. Cada sugerencia de error debe ser específica para el campo y para la regla de validación concreta que se ha incumplido.

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

El panorama de accesibilidad de Turquía ha avanzado significativamente con la Circular Presidencial 2025/10, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025. Esta circular establece requisitos obligatorios de accesibilidad web y móvil alineados con WCAG 2.2, con conformidad de Nivel AA requerida para las entidades que busquen el Erişilebilirlik Logosu (Logotipo de Accesibilidad) emitido por el Ministerio de Familia y Servicios Sociales (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 3.3.3 Sugerencia de Error, como criterio de Nivel AA, entra dentro del alcance de este requisito obligatorio. Cualquier entidad cubierta que opere formularios —para registro, pago, solicitudes de servicios o gestión de cuentas— debe garantizar que sus mensajes de error no solo identifiquen errores, sino que proporcionen sugerencias correctivas accionables, tal como se describe en este criterio.

Las entidades cubiertas por la Circular Presidencial 2025/10 abarcan una amplia gama de sectores. Las instituciones públicas y los organismos gubernamentales están obligados a cumplir, lo que significa que todos los portales de gobierno electrónico (por ejemplo, servicios de e-Devlet, portales municipales, sistemas de solicitud de prestaciones) deben proporcionar implementaciones de sugerencia de error conformes. Dado que muchos servicios gubernamentales requieren que la ciudadanía envíe datos personales complejos —números de identidad, códigos de dirección, números de impuestos—, las sugerencias de error claras son especialmente críticas en este contexto.

Los bancos e instituciones financieras están cubiertos, incluidas las plataformas de banca en línea, los formularios de registro de cuentas de inversión y los portales de solicitud de préstamos. Estos formularios recopilan de forma habitual datos sensibles y con formatos muy precisos, y la ausencia de sugerencias correctivas crea barreras reales para las personas clientas con discapacidad y una posible exposición legal.

Los hospitales y proveedores de atención sanitaria también deben cumplir, lo que abarca los sistemas de registro de pacientes, los formularios de reserva de citas y los portales de reclamaciones de seguros. Los formularios médicos suelen implicar requisitos de campos complejos (códigos de diagnóstico, números de póliza de seguro, formatos de fecha precisos), lo que hace que las sugerencias de error claras sean especialmente importantes para las personas mayores y con discapacidades cognitivas.

Las empresas de telecomunicaciones con 200,000 o más abonados están cubiertas, lo que incluye los portales de clientes de los principales operadores, los formularios de registro de SIM y las interfaces de gestión de cuentas. Las plataformas de comercio electrónico, incluidos los flujos de pago y registro de cuentas, deben cumplir, lo que hace que Sugerencia de Error sea directamente relevante para los formularios de gestión de productos y carritos que son centrales para sus operaciones comerciales.

Las agencias de viajes, las empresas de transporte privado y las escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE) también están dentro del alcance. Los formularios de reserva, las solicitudes de inscripción y las interfaces de pago operadas por estas entidades deben cumplir las normas de Nivel AA, incluida 3.3.3.

Desde una perspectiva práctica de cumplimiento, las organizaciones que persiguen el Erişilebilirlik Logosu deben tratar WCAG 3.3.3 como un punto clave de auditoría durante cualquier evaluación de accesibilidad. Se requieren pruebas manuales de todos los flujos de validación de formularios —incluidos los estados de error del lado del cliente y del servidor—, y debe mantenerse documentación sobre la justificación de la excepción de seguridad para cualquier campo en el que las sugerencias correctivas se omitan intencionadamente. No cumplir los requisitos de Nivel AA, incluida Sugerencia de Error, impedirá la concesión del logotipo y puede exponer a las entidades cubiertas a consecuencias administrativas en virtud de la circular.