Etiquetas de formulario

Un cuadro de texto junto a la palabra "Email" no está etiquetado hasta que el elemento label se vincula con él; mientras tanto, un lector de pantalla puede decir solo "editar texto".

Cada campo necesita un nombre

Cuando el foco llega a un campo de formulario, un lector de pantalla anuncia su etiqueta, su tipo y su estado: "Email, editar texto, obligatorio". La etiqueta viene de un elemento label vinculado al campo. Hay dos formas de vincularlos. Dale al input un id y a la etiqueta un for que coincida, o pon el input dentro de la etiqueta. De cualquiera de las dos maneras, al hacer clic en el texto de la etiqueta el foco también pasa al campo, y eso hace mucho más fácil acertar en casillas y botones de opción pequeños.

<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

<label>
  <input type="checkbox" name="news"> Send me the weekly menu
</label>

El criterio de conformidad 3.3.2 Etiquetas o instrucciones de WCAG 2.2, de nivel A, pide etiquetas o instrucciones siempre que el contenido requiera datos del usuario, y 1.3.1 Información y relaciones pide que el vínculo entre la etiqueta y el campo exista en el código, no solo en la pantalla. Un párrafo que casualmente está encima de un input solo está cerca a la vista; nada le dice a la tecnología de apoyo que los dos van juntos.

Un placeholder no es una etiqueta

El atributo placeholder muestra un texto de ayuda gris dentro de un campo vacío. Es tentador usarlo en lugar de una etiqueta, y muchos formularios de registro lo hacen. El problema es que desaparece en cuanto escribes, así que ya no puedes comprobar para qué era el campo, y suele ser tan pálido que no cumple las reglas de contraste de la unidad anterior. Usa una etiqueta visible y, si quieres, también un placeholder con un valor de ejemplo.

Grupos, propósito y errores

Los botones de opción y las casillas relacionadas también necesitan una etiqueta de grupo. Envuélvelos en un fieldset y pon la pregunta en su legend, para que un lector de pantalla diga "Talla, grupo" antes de "Chica, botón de opción, 1 de 3". Para los datos personales, el atributo autocomplete le dice al navegador para qué es un campo, con nombres del estándar HTML como name, email, tel, new-password y one-time-code. El criterio 1.3.5 Identificar el propósito de la entrada, de nivel AA, pide exactamente esto, porque permite que los navegadores rellenen los campos y que algunas herramientas muestren íconos conocidos junto a ellos.

Cuando algo sale mal, dilo con palabras. El criterio 3.3.1 Identificación de errores pide que un error de entrada se identifique y se describa al usuario con texto, no solo poniendo el borde en rojo. WCAG 2.2 también agregó 3.3.7 Entrada redundante: la información que una persona ya escribió en el mismo proceso debe rellenarse de nuevo por ella u ofrecerse para seleccionarla, en lugar de tener que escribirla dos veces. Y 3.3.8 Autenticación accesible (mínimo), de nivel AA, dice que un paso de inicio de sesión no debe depender de recordar o transcribir algo a menos que haya ayuda disponible; dejar que los gestores de contraseñas rellenen el campo y permitir pegar cuentan como esa ayuda.

Di lo que se necesita antes de que la gente empiece

Las instrucciones van antes de los campos que describen, no en un mensaje de error cuando alguien ya falló. Si una contraseña debe tener al menos 15 caracteres, dilo junto a la etiqueta. Marca los campos obligatorios en el texto de la etiqueta, por ejemplo con la palabra "obligatorio", y agrega el atributo required para que el navegador también lo anuncie. Cuando aparezca un mensaje de error, déjalo junto a su campo y vincula los dos con aria-describedby apuntando al id del mensaje; así el lector de pantalla lee el mensaje cuando el campo recibe el foco. Por último, mueve el foco al primer campo con problemas, o a un resumen de los errores arriba, para que quien usa el teclado no se quede al final de un formulario largo sin saber qué pasó.