Español
Menú del sitio

invalid-field-error-message

Los campos marcados como no válidos deberían tener un mensaje de error mostrado

automaticWCAG 3.3.1 (A)confianza: highgravedad: seriousunderstandable

Comprueba que un elemento con aria-invalid tenga un mensaje de error en texto: su aria-errormessage debería nombrar un elemento mostrado con texto, y se pregunta por un campo sin ningún mensaje vinculado.

Ámbito de aplicación. Elementos que la página muestra, en el árbol de accesibilidad y no deshabilitados, cuyo aria-invalid indica que no son válidos: true, o un valor que ARIA lee como true (cualquiera salvo false, grammar, spelling o vacío). grammar y spelling marcan texto, no un valor que haya introducido el usuario.

Resultado esperado. El error se identifica y se describe al usuario en texto (WCAG 3.3.1).

  • aria-errormessage nombra un elemento que se muestra y tiene texto: pass.
  • aria-errormessage solo nombra elementos ocultos (ERROR_MESSAGE_HIDDEN): cantTell, con tendencia a fail. ARIA exige que el mensaje se muestre mientras el campo no es válido, y la página indica que no se muestra; pero, como con un mensaje vacío, el error puede seguir indicándose en la etiqueta o junto al campo, lo que cumple el 3.3.1.
  • aria-errormessage solo nombra elementos mostrados sin texto (ERROR_MESSAGE_EMPTY): cantTell. ARIA no establece ningún MUST sobre el texto del mensaje, y el error puede indicarse en la etiqueta o junto al campo, lo que cumple el 3.3.1. Cuando el aria-describedby del campo da una descripción, el error puede estar ahí: cantTell (ERROR_MESSAGE_NOT_SHOWN_DESCRIBED).
  • aria-errormessage no nombra ningún elemento de la página: cantTell (ERROR_MESSAGE_TARGET_MISSING); un script puede añadirlo.
  • Sin aria-errormessage, y aria-describedby da una descripción: pass.
  • Ninguno de los dos: cantTell (NO_ERROR_MESSAGE). El error puede estar en la etiqueta o en un texto junto al campo, que el marcado no vincula con él; compruebe que se indica al usuario, en texto, qué campo tiene el error y qué está mal.
  • aria-errormessage nombra un mensaje que es aria-hidden en sí mismo o está dentro de un elemento aria-hidden: cantTell, con tendencia a fail (ERROR_MESSAGE_HIDDEN, con hiddenBy: 'aria-hidden'). ARIA considera oculto un elemento así, y exige que un mensaje de error pertinente no lo esté.
  • aria-errormessage nombra un mensaje mostrado cuyo texto está todo dentro de elementos aria-hidden, mientras que el propio mensaje no lo está: cantTell (ERROR_MESSAGE_ARIA_HIDDEN). Quienes lo ven reciben la información; los usuarios de lectores de pantalla puede que no.

Un elemento cuenta como oculto cuando nadie lo ve: display: none, visibility: hidden, hidden, un <details> cerrado o content-visibility: hidden en él o en un ancestro; un mensaje oculto con visibility: hidden cuyo texto vuelve a hacerse visible con visibility: visible se muestra. El texto es lo que lee el cálculo del nombre accesible: el alt de una imagen cuenta, y el texto oculto dentro del mensaje no. El mensaje puede nombrarse por id o asignarse desde un script como elemento (ariaErrorMessageElements).

Qué informa un hallazgo.

  • ariaInvalid: el valor del atributo.
  • hiddenBy (ERROR_MESSAGE_HIDDEN): aria-hidden cuando solo aria-hidden oculta el mensaje; ausente cuando nadie lo ve.
  • errorMessageIds: los ids que nombra aria-errormessage, o [] si no nombra ninguno.

Estos campos de data.details ayudan a leer y reproducir un hallazgo. Salvo reasonCode y los pocos campos que Esquema de salida indica como estables, no son un contrato estable: un campo puede cambiar de nombre o desaparecer en una versión menor, así que no construyas sobre ellos.

Ejemplos

pass
<label for="email">Email</label>
<input id="email" aria-invalid="true" aria-errormessage="email-error">
<p id="email-error">Enter an email address, like name@example.com.</p>

El campo está marcado como no válido, y el mensaje que nombra aria-errormessage se muestra y dice qué está mal.

can't tell
<label for="email">Email</label>
<input id="email" aria-invalid="true" aria-errormessage="email-error">
<p id="email-error" hidden>Enter an email address, like name@example.com.</p>

El campo está marcado como no válido, pero su mensaje de error está oculto. Tiende a fail: el mensaje vinculado al campo no se puede ver ni oír, aunque el error puede seguir indicándose en la etiqueta o junto al campo.

can't tell
<label for="age">Age</label>
<input id="age" aria-invalid="true">
<p>Age must be a number.</p>

No hay ningún mensaje vinculado al campo. El texto junto a él puede describir el error; una persona comprueba que se indica al usuario, en texto, qué campo tiene el error y por qué.

Cómo comprobarlo

Cuando esta regla no puede decidir, informa cantTell y deja la pregunta a una persona. Cada pregunta que puede plantear aparece aquí bajo su código de motivo, con los pasos para responderla. Un hallazgo lleva los mismos pasos en howToCheck, en el idioma del análisis. Consulta Esquema de salida.

ERROR_MESSAGE_ARIA_HIDDEN

  1. Localizar el campo que indica el informe y confirmar que su mensaje de error es visible en pantalla.
  2. Inspeccionar el elemento del mensaje al que apunta aria-errormessage y anotar cuáles de sus hijos llevan aria-hidden="true".
  3. Poner el foco en el campo con un lector de pantalla en marcha, o leer su mensaje de error y su descripción en el panel Accesibilidad.
  4. Anotar si las palabras del error llegan al lector de pantalla por alguna vía.

Se cumple. A quien usa lector de pantalla se le comunica el mismo texto de error que se muestra en pantalla, por ejemplo mediante la descripción o la etiqueta del campo.

No se cumple. El error es visible pero está oculto a las tecnologías de apoyo, así que a quienes usan lector de pantalla no se les dice qué está mal, lo que incumple WCAG 3.3.1.

ERROR_MESSAGE_EMPTY

  1. Localizar el campo que indica el informe y provocar su estado de error (enviar el formulario o introducir un valor no válido) si aún no se muestra.
  2. Inspeccionar el campo y localizar el elemento al que apunta su atributo aria-errormessage; confirmar que está vacío.
  3. Buscar en la etiqueta del campo y en el texto junto a él palabras que digan qué campo tiene el error y qué está mal.
  4. Poner el foco en el campo con un lector de pantalla en marcha, o comprobar su nombre y su descripción en el panel Accesibilidad, y anotar si se transmite el error.

Se cumple. Un texto de la página, como la etiqueta o un mensaje junto al campo, dice qué campo tiene el error y qué está mal.

No se cumple. Ningún texto indica al usuario qué campo tiene el error ni qué está mal, lo que incumple WCAG 3.3.1.

ERROR_MESSAGE_HIDDEN

  1. Hacer que el campo no sea válido como lo haría un usuario (enviar el formulario vacío o escribir un valor erróneo).
  2. Buscar el mensaje de error al que apunta el campo (su aria-errormessage) y comprobar si aparece en pantalla.
  3. Si no aparece, buscar cualquier texto que le diga qué está mal: en la etiqueta, junto al campo o en un resumen en la parte superior del formulario.
  4. Con un lector de pantalla, desplazarse hasta el campo y escuchar el error.

Se cumple. El error se muestra en texto, y se anuncia, en algún lugar vinculado al campo, aunque no sea en el mensaje que indica aria-errormessage.

No se cumple. Ningún texto le dice qué campo está mal ni por qué, o a quien usa lector de pantalla no se le comunica, lo que incumple WCAG 3.3.1.

ERROR_MESSAGE_NOT_SHOWN_DESCRIBED

  1. Localizar el campo que indica el informe y provocar su estado de error si aún no se muestra.
  2. Abrir el panel Accesibilidad para el campo y leer su descripción (de aria-describedby).
  3. Comparar esa descripción con el error: decidir si dice qué está mal o si solo es un texto de ayuda, como un formato de entrada.
  4. Comprobar que el mismo texto de error es visible en pantalla cerca del campo.

Se cumple. La descripción del campo, u otro texto visible, expresa el error con palabras, así que tanto quienes ven la pantalla como quienes usan lector de pantalla saben qué está mal.

No se cumple. La descripción es solo un texto de ayuda y ningún texto visible describe el error, lo que incumple WCAG 3.3.1.

ERROR_MESSAGE_TARGET_MISSING

  1. Localizar el campo que indica el informe y anotar el id de su atributo aria-errormessage.
  2. Provocar el error (enviar el formulario o introducir un valor no válido) y buscar en el panel Elements un elemento con ese id.
  3. Si el elemento aparece, comprobar que se muestra y que tiene un texto que describe el error.
  4. Si nunca aparece, buscar otro texto visible cerca del campo o en su etiqueta que diga qué está mal.

Se cumple. Cuando el campo tiene un error, un mensaje visible con ese id, u otro texto visible, describe el error.

No se cumple. El campo está marcado como no válido pero ningún texto describe el error, lo que incumple WCAG 3.3.1.

NO_ERROR_MESSAGE

  1. Localizar el campo que indica el informe; está marcado con aria-invalid.
  2. Comprobar si el campo tiene realmente un error ahora; si está marcado como no válido antes de que el usuario haya introducido nada, introducir un valor válido y ver si la marca desaparece.
  3. Buscar en la etiqueta del campo, en el texto junto a él y en cualquier resumen de errores de la página palabras que nombren este campo y digan qué está mal.
  4. Poner el foco en el campo con un lector de pantalla en marcha y anotar si se anuncia el error.

Se cumple. Un texto visible identifica el campo con el error y describe qué está mal, o el campo no tiene realmente un error.

No se cumple. El campo tiene un error pero ningún texto lo identifica ni describe el problema, lo que incumple WCAG 3.3.1.

Ver código fuente