Hoy te comparto algunas buenas y malas prácticas al respecto con ejemplos y todo.

Malas prácticas

  • Comunicar errores solo usando color. Hacer esto implica que solo quienes son personas usuarias visuales pueden percibir el problema.
  • Usar mensajes de error genéricos. Esto deja a las personas usuarias sin visibilidad de qué puede estar fallando ni ideas sobre cómo resolverlo.e
  • Colocar los mensajes de error lejos del campo específico. La proximidad del error al campo con problemas permitirá identificar el punto a solucionar más rápidamente y facilitará su comprensión.
  • Requerir que un campo deba cumplir con un formato o reglas específicas y no comunicarlo. No podemos esperar que nuestras personas usuarias adivinen reglas o requerimientos que no les estamos especificando de antemano.
  • No permitir la navegación por teclado ya que esto implicará discriminar a un grupo de personas usuarias.
  • Usar lenguaje demasiado técnico o poco específico al comunicar errores que no le permitan a la persona usuaria entender qué sucede o cómo solucionarlo.
  • Usar placeholders como el único identificador de un input. Esto es un error fatal por muchos motivos: para quienes navegan con tecnologías asistivas el input no tendrá un identificador, para quienes perciben el contenido de manera visual no suele tener suficiente contraste, las contras son demasiadas y afectan prácticamente a todos los tipos de usuarios.

Buenas prácticas

  • Asociar el label específico a cada campo. Esto mejora la experiencia de personas usuarias que navegan la web de manera visible así como de quienes navegan con tecnologías asistivas.
<label for="Name">Name</label>
<input type="text" id="Name" name="Name" placeholder="e.g. Taylor Swift"/>
  • Especificar visual y programáticamente cuando un campo es obligatorio.
  • Proporcionar instrucciones y/o ejemplos de formato cuando hay un campo que debe cumplir ciertas reglas (como cuando un teléfono o un email deben respetar un formato específico).
  • Incluir mensajes de validación en vivo en los campos que sea necesario.
  • Usar la etiqueta fieldset para agrupar contenido relacionado como puede ser el caso de los radio buttons o checkboxes.
<fieldset>
  <legend>Choose your favorite monster</legend>

  <input type="radio" id="kraken" name="monster" value="K" />
  <label for="kraken">Kraken</label>

  <input type="radio" id="sasquatch" name="monster" value="S" />
  <label for="sasquatch">Sasquatch</label>

  <input type="radio" id="mothman" name="monster" value="M" />
  <label for="mothman">Mothman</label>
</fieldset>

Como todo lo relacionado a código HTML, no es que haya una única solución correcta, sino que todo depende del contexto. Sin embargo, seguir buenas prácticas nos ayuda a sentar una base inclusiva que permita a la mayor cantidad de personas posibles acceder a nuestro contenido. ¿Se te ocurren más tips para generar formularios siguiendo buenas prácticas?