Como crear un formulario accesible

28/05/2021

Los formularios son fuente de algunos de los problemas más comunes de accesibilidad. Las pautas de accesibilidad para el contenido web, en inglés: Web Content Accessibility Guidelines , también conocidas como WCAG, son un conjunto de estándares para hacer que el contenido en la web sea más accesible para personas con discapacidades. Son lo mínimo que debes cumplir para crear menos barreras a los usuarios, y es recomendable que sean complementadas con buenas prácticas dado que WCAG tiene ciertas limitaciones. A continuación haremos un repaso de las cosas a considerar para crear un formulario que sea más accesible.

Etiquetas

El uso correcto de etiquetas es importante al crear un formulario. Hay que tener en consideración su visibilidad, posición, que esté asociada programáticamente, y que sea descriptiva.

Etiquetas visibles

Los controles de un formulario deben tener una etiqueta visible para que los usuarios sepan cuál es su propósito y qué información deben ingresar. Esto incluye controles <input>, <textarea> y <select>.

Es además considerado un saliendo del sitio: requisito para cumplir con el criterio de conformidad etiquetas o instrucciones de las pautas de accesibilidad para el contenido web.

Evitar el atributo placeholder como la única etiqueta visible

Es importante que la visibilidad de la etiqueta sea persistente. Un atributo placeholder no cumple con este criterio, puesto que una vez que se ha llenado el campo, deja de ser visible.

2 controles de entrada con atributo placeholder, uno de ellos con el campo llenado.

Otro potencial problema es que a veces el navegador permite llenar campos automaticamente, pero estos no siempre son llenados correctamente. Si no existe una etiqueta visible que permita entender el tipo de información que debe ser ingresada, no será posible percatarse de algún error.

Asociación programática

Si existe una asociación visual, también debe existir una asociación programática. Esto para que la información sea perceptible para distintos sentidos, no solo la visión.

Una persona vidente puede entender la relación entre una etiqueta y un control en base a su proximidad. Al hacer una asociación programática nos aseguramos que dicha relación sea entendible por todas las personas y quitamos toda ambigüedad. Es además un requisito para cumplir con el criterio de conformidad saliendo del sitio: 1.3.1 - Información y relaciones

A continuación veremos los distintos métodos para crear asociaciones programáticas usando html semántico.

Asociación implícita

La asociación implícita se hace envolviendo la etiqueta sobre el control.

<label> Nombre <input type="text" /> </label>
Existen saliendo del sitio: problemas en software de reconocimiento de voz como saliendo del sitio: Dragon donde no puedes seleccionar un control por el nombre visible si la asociación es implícita.

Asociación explícita

La asociación explícita se hace a través de los atributos for e id. El valor de los atributos debe ser idéntico e único en la página. Si existen valores duplicados pueden generar un conflicto y las etiquetas podrían quedar asociadas al control incorrecto.

<label for="foo">Nombre<label> <input type="text" id="foo" />

Asociación grupal

Cuando una etiqueta es necesaria para ofrecer contexto a campos de verificación o radiobotones, se hace una asociación grupal con los elementos fieldset y legend:

<fieldset> <legend>Frutas favoritas</legend> <input type="checkbox" id="manzana"> <label for="manzana">Manzana</label> <input type="checkbox" id="naranja"> <label for="naranja">Naranja</label> <input type="checkbox" id="kiwi"> <label for="kiwi">Kiwi</label> </fieldset>

El elemento legend debe ser un hijo directo del elemento legend y debe ser el primer elemento dentro de él.

De ser necesario, es posible usar un encabezado dentro de legend:

<fieldset> <legend><h2>Modo</h2></legend> <input type="radio" id="claro"> <label for="claro">Claro</label> <input type="radio" id="oscuro"> <label for="oscuro">Oscuro</label> <input type="radio" id="sistema"> <label for="sistema">Sistema</label> </fieldset>

Etiquetas descriptivas

El texto de las etiquetas debe describir el propósito del control para que el usuario sepa qué tipo de información debe ingresar. Esto incluye ofrecer instrucciones si los datos a ingresar deben estar en algún formato en particular e indicar visualmente los campos que son obligatorios u opcionales. Ahondaremos más sobre esto en la sección de prevención de errores.

Proximidad

Es importante la proximidad entre etiqueta y control porque hace que sea más fácil poder hacer la asociación entre ambas. En la siguiente imagen las etiquetas están en el costado izquierdo y separada por mucho espacio del control que está en el costado derecho.

2 controles de entrada con sus respectivas etiquetas separadas por mucho espacio entre ellos

Esto dificulta la asociación visual, especialmente para personas que usan magnificadores de pantalla. Es recomendable que campos de texto y listas desplegables cuenten con la etiqueta en la parte superior y con una distancia prudente.

2 controles de entrada con las etiquetas en la parte superior a una distancia cercana

Autocompletado

Llenar los campos de un formulario puede resultar más difícil para personas con discapacidades motoras o cognitivas. Usa el atributo autocomplete para que sea más fácil llenar campos que piden información personal. Este es un requisito para cumplir con el criterio de conformidad saliendo del sitio: 1.3.5 - Identificación del propósito de entrada . Puedes encontrar los valores a usar en la siguiente saliendo del sitio: lista de propósitos de componentes de interfaz .

<label for="name">Nombre</label> <input type="text" autocomplete="given-name" id="name"> <label for="apellido">Apellido</label> <input type="text" autocomplete="family-name" id="apellido">
No es un requisito usar autocompletado en todos los campos de un formulario, solo los que piden información personal y estén definidos en la lista de propósitos.

Contraste

Un contraste de color suficiente entre texto y fondo ayuda a que sea más fácil leer el contenido para personas con discapacidades visuales y baja visión. Las pautas de accesibilidad para el contenido web establecen una relación de contraste mínima para estos casos de 4.5:1 y 3:1 para texto grande (superior a 24 pixeles o 18.667 pixeles y negrita).

En el caso de los formularios, asegúrate de que los botones, etiquetas o instrucciones tengan un contraste mínimo suficiente. Puedes usar la siguiente saliendo del sitio: herramienta online para comparar contraste .

Captura de pantalla de herramienta para comparar contraste mostrando los campos de color de fondo, texto y la relación de contraste

Contraste en elementos de interfaz

No todo el contenido es texto, por eso existe el saliendo del sitio: criterio de conformidad 1.4.11 - Contraste no textual que aborda el contraste de color en elementos de interfaz. Esto para asegurar que personas con baja visión también perciban contenido que es considerado importante para entender cierta información, pero que no necesariamente está en formato de texto. El criterio establece que elementos de interfaz y objetos gráficos esenciales para entender el contenido deben tener una relación de contraste de 3:1 con colores adyacentes.

Radio botones

Si un borde es usado para identificar el control, este debe tener un contraste mínimo de 3:1 con el color adyacente. En el siguiente caso el radiobotón en su estado normal tiene un borde de color #939393 y el color adyacente es el color de fondo #fff. La relación de contraste es de 3:1 y por tanto cumple con el criterio de conformidad.

radio botón con un borde gris

Cuando el radio botón se encuentra seleccionado, el elemento que distingue dicho estado también debe cumplir con el requisito de contraste mínimo. En el siguiente caso, el círculo al estar seleccionado tiene un color #D4284D y el color adyacente que es el color de fondo es #fff. La relación de contraste es de 5:1 y por tanto cumple con el criterio de conformidad.

radio botón con seleccionado con un borde gris y un circulo rojo

Casilla de verificación

Si un color de fondo es usado para identificar el control, este debe tener un contraste mínimo de 3:1 con el color adyacente. En el siguiente caso la casilla de verificación cumple con el requisito de contraste mínimo puesto que el color del elemento #232946 tiene un contraste de 14.2:1 en relación con el fondo #fff.

casilla de verificación con forma de cuadrado y color de fondo azul oscuro

En su estado seleccionado, el elemento que distingue dicho estado también debe tener un contraste mínimo de 3:1. En el siguiente caso el cuadrado interior tiene un color #ff5277 y el color adyacente es #232946. La relación de contraste es de 4.6:1 y por tanto cumple con el criterio de conformidad.

casilla de verificación seleccionada con forma de cuadrado, color de fondo azul oscuro y un cuadrado interior de color rojo

Lista desplegable

Si se usa una lista desplegable personalizada, el elemento que la identifica como tal, muchas veces un ícono en forma de flecha, debe tener una relación de contraste mínimo de 3:1. En el siguiente caso el ícono tiene un color #fff y el color adyacente es #d4284d, cumpliendo con el criterio al tener una relación de contraste de 5:1.

lista desplegable con un color de fondo rojo, texto y flecha de color blanco
No es un requisito que la lista desplegable tenga un perímetro visible como un borde o un color de fondo para cumplir con el criterio de conformidad, pero es altamente recomendable dado que ayuda a personas con discapacidades cognitivas a identificar y reconocer el control.

Campos de texto

Si el único indicador visual del elemento es un perímetro como un borde o un color de fondo, este debe tener una relación de contraste de 3:1 con colores adyacentes. En el siguiente caso el campo de texto tiene un borde con un color #888 y el color adyacente es #fff, cumpliendo con el contraste mínimo al tener una relación de contraste de 3.5:1.

campo de texto con un borde gris

Si el campo tiene un color de fondo y un borde en un solo lado, uno de ellos sirve como su indicador visual y debe cumplir con el contraste requerido. En el siguiente caso el campo de texto tiene un color de fondo que no cumple con el contraste mínimo, pero tiene un borde en uno de sus lados que sí lo cumple y por tanto no es considerado un fallo.

campo de texto con un color de fondo gris, y un borde en el lado bajo de color gris oscuro
Es recomendable que los campos de texto tengan un perímetro claramente visible, y si se usa un borde, que sea en todos sus lados para que sea más fácil identificarlo correctamente.

Botón

El texto de un botón o un ícono cuenta como un indicador visual, y por tanto no es necesario que el botón tenga un perímetro como un borde o color de fondo. En caso de que el botón sí tenga un borde o color de fondo, este no necesita cumplir con el contrasta mínimo de 3:1 dado que el texto del botón ya cuenta como su indicador visual. El texto sí debe cumplir con el saliendo del sitio: criterio de conformidad 1.4.3 - Contraste (mínimo)

botón con color de fondo azul y texto enviar de color blanco
Es recomendable que los botones tengan un perímetro claramente visible y con buen contraste para que sea más fácil identificarlo como un botón.

Elementos enfocados

Es importante que los elementos interactivos tengan un foco claramente visible para que personas que dependen del uso de un teclado puedan identificar qué elemento se encuentra enfocado. Este foco también debe cumplir con el requisito de tener una relación de contraste de 3:1, con la excepción de los estilos de foco por defecto del navegador. En la siguiente imagen el campo de texto tiene un foco usando la propiedad outline con un color ##F7CA18 y una relación de contraste de 3.3:1 con el fondo de color #1D70B8.

campo de texto con fondo blanco en estado enfocado. El foco es un borde sólido de color amarillo sobre un color de fondo de la página azul
Si bien no es una falla al criterio de conformidad usar los estilos de foco por defecto del navegador, es recomendable utilizar un estilo de foco personalizado para que este sea consistente y nos aseguremos que tenga un buen contraste.

Uso del color

Hay que evitar ofrecer información que sea presentada únicamente a través del color. Un ejemplo de esto es sólo cambiar el color del borde de un campo para comunicar que tiene un error. Hay personas con deficiencias en la percepción del color, y que tienen problemas para distinguirlos. Para eso existe el saliendo del sitio: criterio de conformidad 1.4.1 - Uso del color que establece que el color no debe ser usado como el único medio para transmitir información.

Es importante hacer una distinción en lo que las pautas de accesibilidad para el contenido web consideran como uso del color. WCAG hace una distinción entre matiz, y luminancia. Si existe un contraste mínimo entre colores de 3:1, WCAG considera que eso cuenta como un indicador visual adicional, y por tanto no se estaría usando solo el color. A pesar de esto, la recomendación es ofrecer otro tipo de indicador visual para garantizar una mejor percepción de la información.

Mensajes de error

Debemos asegurarnos que el indicador visual de un error no consista únicamente del uso del color. En este caso se usa el color rojo para indicar que el campo tiene un error.

campo de texto largo para una descripción con un borde rojo y un mensaje de error con el mismo color

En el caso de la imagen anterior, para una persona con deficiencia en la percepción del color, el texto “Debes ingresar una descripción” podría confundirse con una instrucción, en vez de un mensaje de error. Para evitar dicha ambigüedad, debemos agregar otro indicador visual, como por ejemplo un ícono o un borde. En la siguiente imagen incluímos además la palabra “Error” para dejar en claro su significado a personas que usan un lector de pantalla. Aunque también es posible esconderla visualmente, o definirla como el nombre accesible del ícono.

campo de texto largo para una descripción con un borde rojo, un mensaje de error y un ícono con el mismo color

Nombre accesible

El nombre accesible de un elemento es el nombre que es expuesto a tecnologías de asistencia a través del API de accesibilidad. En algunos casos, el nombre accesible y el nombre visible no son el mismo. En estos casos hay que asegurarse que el nombre visible esté contenido en el nombre accesible. Esto permite que usuarios de software de reconocimiento de voz puedan activar el control al hablar el nombre visible de este. También es un requisito del saliendo del sitio: criterio de conformidad 2.5.3 - Etiqueta en nombre .

A continuación veremos un ejemplo de un fallo al criterio:

<button aria-label="Cotizar">Solicitar presupuesto</button>

En el ejemplo anterior el nombre visible es “Solicitar presupuesto”, pero el nombre accesible es asignado al usar el atributo aria-label cuyo valor es “Cotizar”.

Validación

Aun siguiendo los estándares establecidos por WCAG y buenas prácticas para crear formularios que sean accesibles, los usuarios a veces cometerán errores. Debemos tomar medidas para intentar prevenir esos errores, cuando ocurran deben ser identificados correctamente, y se deben ofrecer sugerencias apropiadas para que puedan ser corregidos.

Prevención de errores

Para prevenir posibles errores es fundamental tener etiquetas que sean claras y descriptivas para que el propósito del control sea entendido, y los usuarios sepan qué información deben ingresar.

Instrucciones

Si es un requisito que la información sea escrita en un formato en específico, por ejemplo si el Rol Único Tributario (RUT) debe ser ingresado con o sin puntos, esto debe ser comunicado.

En casos en que el texto instructivo es breve, puede ser escrito en la misma etiqueta:

<label for="run">RUT (sin puntos ni guíon)</label> <input type="text" id="run">

Otra opción es poner la información abajo de la etiqueta:

<label for="mensaje">Mensaje</label> <div id="descripcion-mensaje">Debe tener un mínimo de 30 caracteres</div> <textarea id="mensaje" aria-describedby="descripcion-mensaje"></textarea>
Cuando existe una asociación visual, también debe existir una programática. Esto permite que dicha asociación sea entendida por todas las personas, no solo alguien que pueda ver la pantalla. En estos caso usamos los atributos for e id para asociar la etiqueta al control, y aria-describedby para asociar la instrucción al control.

Campos obligatorios

Es un requisito indicar visualmente cuando un campo es obligatorio? depende. El texto normativo del saliendo del sitio: criterio de conformidad 3.3.2 - Etiquetas o instrucciones técnicamente no lo exige, aunque es recomendado. En nuestra opinión, se puede omitir en casos donde es claro que es necesario llenar un campo. Por ejemplo, si solo debes ingresar el nombre de usuario y contraseña en un formulario de ingreso, se puede asumir que son campos obligatorios. Si el formulario tiene una mezcla de campos obligatorios y opcionales, uno de ellos o ambos deben ser identificados como tal.

Si utilizas un asterisco como indicador visual de un campo obligatorio, recomendamos mencionar su significado al comienzo del formulario, no al final.

2 campos de texto obligatorios usando un asterisco de color rojo como indicador. Tiene texto en la parte superior explicando el significado del asterisco

Hay que recordar que la asociación no puede ser solo visual, y por tanto también debemos indicar de manera programática que un campo es requerido. Para eso podemos usar el atributo required. Sin embargo, debemos tener en cuenta que en algunas combinaciones de lectores de pantalla y navegadores, el atributo required hará que un campo vacío se anuncie como inválido. Para prevenir esto, debes usar aria-invalid="false", y cambiar su valor a aria-invalid="true" cuando exista un error.

<label for="nombre">Nombre *</label> <input type="text" id="nombre" required aria-invalid="false"> // Cuando exista un error de validación el valor de aria-invalid cambia a true <label for="nombre">Nombre *</label> <input type="text" id="nombre" required aria-invalid="true">
Si haces tu propia validación, tendrás que usar el atributo novalidate en el elemento <form> para prevenir la validación por defecto del navegador.

Si bien es posible usar un símbolo para indicar que un campo es obligatorio, recomendamos escribir la palabra “obligatorio” o “requerido”.

Detección de errores

A pesar de que se tomen medidas para prevenir errores, estos pueden ocurrir. Cuando eso suceda, el saliendo del sitio: criterio de conformidad 3.3.1 - Identificación de errores establece que los errores se deben identificar y presentar en formato de texto. Cabe mencionar que cuando fue creado el criterio de conformidad en la versión 2.0 de WCAG, no existían atributos como aria-invalid o aria-describedby para crear una asociación programática. Por tanto, el texto normativo sólo exige contar con texto (al lado del campo relevante) que identifique que existe un error para cumplir con el criterio. Aun así, es necesario que la identificación de un error no sea solamente visual. De lo contrario, es considerado un fallo al criterio saliendo del sitio: 1.3.1 - Información y relaciones y posiblemente saliendo del sitio: 4.1.2 - Nombre, función, valor .

Usa aria-describedby para asociar el mensaje de error a el control.

<label for="nombre">Nombre *</label> <div id="error-nombre">El campo Nombre no ha sido llenado</div> <input type="text" id="nombre" required aria-describedby="error-nombre">

Usa aria-invalid para identificar que un campo tiene un error.

<label for="nombre">Nombre *</label> <div id="error-nombre">El campo Nombre no ha sido llenado</div> <input type="text" required aria-describedby="error-nombre" aria-invalid="true">

Corrección de errores

Debemos ayudar a los usuarios a corregir los errores cuando ocurran. Identificar que existe un error, y presentarlo en formato de texto no siempre es suficiente dado que personas con discapacidades visuales y cognitivas pueden tener dificultades al no saber como corregirlos.

En caso de que existan errores, debemos ser claros, concisos y ofrecer sugerencias para corregirlos. Es recomendado evitar mensajes genéricos como “este campo está vacío” o “este campo es requerido” dado que no ofrecen mayor información sobre cuál es el error, ni sugerencias para corregirlo de ser necesario.

Tomemos como ejemplo el caso de un campo requerido que pide al usuario ingresar un RUT sin puntos ni guión. Sin embargo, ha sido ingresado incorrectamente e incluye un guión al final. En este caso estamos exigiendo al usuario ingresar datos en un formato en específico, y al existir sugerencias de cómo corregir el error, debemos incluirlas en el mensaje. “Ingresa un RUT sin guión” cumple con los requisitos. Opcionalmente también podemos incluir la palabra “Error:” para reforzar la existencia de un error a personas que usen un lector de pantalla.

Patrón de validación

Existen distintos métodos para validar un formulario. Entre ellos la validación inmediata, el crear un listado de errores, o también enfocar el primer elemento con un error. A continuación haremos un repaso de este último.

Enfocar primer control con error

Este patrón es recomendado cuando tienes un formulario sin muchos campos, por ejemplo un formulario de contacto que contiene campos de nombre, correo y mensaje. El patrón consiste en validar el formulario sólo cuando el usuario ha interactuado con el botón de enviar, y se han encontrado errores. Una vez que se detectan errores, se anuncia la cantidad de errores a través de una región viva, y luego se mueve el foco al primer elemento que tiene un error.

Qué es una región viva?

A veces ocurren cambios dinámicos en una página que contienen información importante. Por ejemplo, si subes una imagen y recibes un mensaje indicando que esta ha sido subida con éxito. Esto es evidente para una persona que puede ver el contenido del sitio, pero no para una persona ciega. Una región viva, en inglés: live region , permite a tecnologías de asistencia anunciar cambios dinámicos que no necesariamente requieran de alguna interacción por parte del usuario.

Anunciar la cantidad de errores

Usando una región viva podemos darle información sobre la cantidad de errores encontrados a usuarios que usen un lector de pantalla. Para eso podemos usar los roles alert o status.

  • role="alert" anunciará los cambios de manera inmediata e interrumpirá otro anuncio que pueda estar haciendo el lector de pantalla.
  • role="status" Esperará a que el lector de pantalla termine de anunciar sin interrupción, y luego comunicará el cambio.

Cómo usar una región viva?

Para que se detecten los cambios, la región debe estar presente en la página, pero vacía:

<div role="alert"> </div>

Sólo se debe introducir el error una vez que estemos validando el formulario:

<div role="alert"> El formulario tiene 2 errores </div>

Una vez que el mensaje se haya introducido, esperamos un par de segundos y lo volvemos a quitar. Esto impide que el usuario lo pueda encontrar por casualidad en otro momento cuando ya no es relevante.

Es además posible esconder el mensaje para que no sea visible, pero siga siendo accesible para personas que usen un lector de pantalla. Para eso podemos usar una clase como la siguiente:

.visualmente-escondido { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; }

Tamaño suficiente

Personas con discapacidades motoras pueden tener problemas para activar elementos de menor tamaño en dispositivos touch o usando un dispositivo apuntador que requiera de mayor precisión. Por esto es considerado una buena práctica que los elementos interactivos, en este caso los controles de un formulario, tengan un tamaño suficiente para que puedan ser activados con facilidad. Es más, WCAG establece en el saliendo del sitio: criterio de conformidad 2.5.5 - Tamaño del objetivo (AAA) que los elementos interactivos (con algunas excepciones) deben tener un área mínima de 44 por 44 pixeles.

El criterio 2.5.5 es del nivel de conformidad triple A, y por tanto no acostumbra ser considerado como un requisito dado que el estándar suele ser doble A. Sin embargo, el deber de uno no debe ser cumplir con lo que dicta un nivel de conformidad en específico, ni seguir WCAG al pie de la letra. De ser posible, es importante abarcar lo que permita crear la menor cantidad de barreras para los usuarios, independiente del nivel de conformidad que intentes alcanzar.

Windows con alto contraste

Windows tiene una opción de accesibilidad que permite mejorar la legibilidad usando un modo de alto contraste. Si un sitio no está desarrollado con esto en mente, es posible que el usuario no pueda identificar correctamente algunos íconos, componentes y sus estados.

Bordes como indicador visual

Asegúrate de que los elementos no dependan de un color de fondo como único indicador visual puesto que este no será visible al activar el modo de alto contraste. Es recomendable usar bordes, y si esto no es posible, puedes crear un borde transparente que solo será visible en Windows con alto contraste. Esto va a prevenir que tus componentes sean invisibles.

input[type="radio"] { border: solid .2rem transparent; }

Estados

Los usuarios esperan que los elementos nativos tengan cierta apariencia que concuerde con la temática de alto contraste. Esto incluye elementos deshabilitados o seleccionados. Para esto debes usar saliendo del sitio: colores de sistema que han sido estandarizados y garantizan una buena legibilidad al usar el modo de alto contraste. Estos colores, junto con la saliendo del sitio: media query forced-colors te permitirán darle el estilo necesario.

Para elementos deshabilitados es recomendable usar el color de sistema GreyText, y para elementos seleccionados como casillas de verificacion, radiobotones y listas desplegables están los colores Highlight para el color de fondo, y HighlightText para el color del texto.

@media (forced-colors: active) { // Botón deshabilitado button { border: solid .2rem GrayText; color: GrayText; } }

A continuación mostraremos ejemplos de elementos nativos deshabilitados, seleccionados y cómo se deben ver al usar la temática de alto contraste negra.

Elementos deshabilitados

muestra de botón, campo de texto, casilla de verificación, radio botón y lista desplegale en estado deshabilitado usando windows con alto contraste. Todos los controles tienen un color verde sobre un fondo negro

Elementos seleccionados

muestra de casilla de verificación, radio botón y lista desplegable usando windows con alto contraste. Los elementos seleccionados tiene un color azul claro sobre un fondo negro

Íconos

Si utilizas un ícono en formato svg para acompañar un mensaje de error o de éxito, puedes usar la propiedad fill con un valor de currentColor y definir el color del ícono con un color de sistema en un elemento padre. Esto garantizará una buena legibilidad al activar el modo de alto contraste:

@media (forced-colors: active) { .icono { color: CanvasText; svg { fill: currentColor; } } } <div class="icono"> <svg></svg> </div>

Para más información sobre cómo funciona y cómo desarrollar un sitio para este modo puedes leer nuestro artículo de saliendo del sitio: introducción a windows con alto contraste .

Resumen

  • Usar etiquetas visibles y evitar el uso del atributo placeholder.
  • Asociar las etiquetas a su control de manera explícita usando los atributos for e id.
  • Posicionar las etiquetas cerca del control al que corresponde.
  • Usar etiquetas claras, que describan el propósito del campo a llenar.
  • Usar el atributo de autocompletado para facilitar llenar los campos de un formulario.
  • Utilizar colores que tengan buen contraste tanto en texto como en elementos gráficos necesarios para entender el contenido.
  • No usar el color como el único medio para transmitir información. Por ejemplo, solo cambiar el color del borde del campo a rojo cuando este contiene un error.
  • Ofrecer instrucciones que permitan prevenir errores cuando hay campos que requieren ser completados en un formato en específico.
  • En formularios con campos tanto obligatorios como opcionales, ofrecer indicadores visuales en formato de texto para determinar cuales son obligatorios u opcionales.
  • En caso de existir sugerencias para corregir errores, ofrecerlas de manera concisa y clara para facilitar la corrección de errores.
  • Los mensajes de errores deben estar en formato de texto, y asociados programáticamente al control correspondiente usando la propiedad aria-describedby.
  • Los mensajes de texto deben idealmente estar posicionados abajo de la etiqueta, y no abajo del campo. Esto permite visualizar el error incluso cuando la lista desplegable del autocompletado está visible.
  • No validar los campos hasta que el usuario active el botón de enviar.
  • Usar una región viva para anunciar la cantidad de errores que existen.
  • Mover el foco al primer elemento que tiene un error cuando se valide el formulario.
  • Se debe utilizar un indicador visual adicional al color. Ejemplos de esto incluyen un ícono o un borde.
  • Optimizar el código para que los elementos sean legibles al activar Windows con alto contraste.
  • Crear elementos con un tamaño mínimo de 44x44 pixeles para facilitar su uso.