Identificación de errores

Silktide examina los campos obligatorios de formularios que parecen usar validación personalizada en lugar de la comprobación integrada del navegador, y avisa cuando no hay ninguna forma aparente de que el mensaje de error llegue a las personas que usan tecnología de asistencia.

Por qué es importante

Cuando un formulario rechaza una respuesta no válida, los usuarios videntes suelen ver un contorno rojo o un mensaje cerca del campo. Un usuario de no obtiene nada de eso a menos que la página exponga el error en el código: el formulario simplemente se niega a enviarse, sin explicación de qué falló ni dónde. El resultado es un formulario que, en silencio, deja fuera a algunos visitantes.

Los navegadores anuncian automáticamente sus propios mensajes de validación integrados. El riesgo aparece cuando una página desactiva eso o lo sustituye por su propia validación, y se olvida de conectar el sustituto para que funcione con la .

Cómo solucionarlo

Da a cada campo con validación personalizada una vía programática para su mensaje de error, usando :

<!-- Problema: validación personalizada sin canal de error accesible -->
<form novalidate>
  <input type=\"text\" required>
  <span class=\"error\">Introduce tu nombre</span>
</form>

<!-- Solución: el campo apunta a su mensaje de error -->
<form novalidate>
  <input type=\"text\" required aria-describedby=\"name-error\">
  <span id=\"name-error\" class=\"error\">Introduce tu nombre</span>
</form>

Cualquiera de estas opciones satisface la comprobación:

aria-errormessage en el campo, que apunte al elemento que rellenas con el texto del error (establece aria-invalid=\"true\" cuando se muestre el error).
aria-describedby en el campo, que apunte al elemento del mensaje.
Una dentro del formulario: un elemento con role=\"alert\", role=\"status\" o aria-live, en el que tu validación escriba el texto del error.

Como alternativa, elimina la personalización y deja que la validación nativa del navegador informe de los errores, lo cual es accesible por defecto.

Cómo lo comprueba Silktide

Encontrar los campos obligatorios visibles: campos de entrada, áreas de texto y menús de selección marcados con required o aria-required=\"true\".
Conservar solo los campos con indicios de que la validación nativa del navegador se omite o se reemplaza: el formulario tiene novalidate, un control de envío tiene formnovalidate, el campo está marcado con aria-invalid, usa aria-required sin el atributo nativo required, o el campo o el formulario llevan pistas de validación personalizada (como atributos relacionados con errores o contenedores de mensajes de error).
Para cada uno de esos campos, buscar cualquier canal de error accesible: una referencia válida de aria-errormessage, una referencia válida de aria-describedby o una región viva dentro del formulario.
Advertir sobre los campos que no tienen ninguna. Se trata de una advertencia, no de un fallo confirmado, porque el comportamiento de validación en tiempo de ejecución no puede observarse completamente a partir del código de la página.

Resolución de problemas

Mis errores se anuncian correctamente

La comprobación busca la estructura que hace posibles los anuncios, no el anuncio en sí. Si tu framework inyecta una región viva o las referencias ARIA solo en el momento en que se produce un error, la página cargada no muestra ningún canal y el campo se marca. Añadir por adelantado el elemento de mensaje (vacío) y la referencia lo resuelve y, además, es más robusto.

El elemento de mensaje referenciado aún no existe

Las referencias deben apuntar a elementos que existan en la página. Un aria-describedby que apunte a un id que solo se crea más tarde cuenta como ningún canal.