La mayoría de los sitios y las aplicaciones incluyen un formulario web. Es posible que los sitios de bromas, como DoWebsites<form>.
El elemento HTML <form> identifica un punto de referencia de documento que contiene controles interactivos para enviar información. Anidados en un <form> encontrarás todos los controles de formulario interactivos (y no interactivos) que lo componen.
El HTML es poderoso. Esta sección se centra en la potencia de HTML y abarca lo que este puede hacer sin agregar JavaScript. El uso de datos de formulario del cliente para actualizar la IU de alguna manera suele implicar CSS o JavaScript, lo que no se analiza aquí. Hay un curso completo de Formularios de aprendizaje. No duplicaremos esa sección aquí, pero presentaremos varios controles de formulario y los atributos HTML que los potencian.
Con los formularios, puedes permitir que los usuarios interactúen con tu sitio web o aplicación, validen la información ingresada y envíen datos a un servidor. Los atributos HTML pueden permitir que el usuario seleccione controles de formulario o ingrese un valor. Los atributos HTML pueden definir criterios específicos con los que el valor debe coincidir para ser válido. Cuando el usuario intenta enviar el formulario, todos los valores del control de formulario pasan por la validación de restricciones del cliente y pueden evitar el envío hasta que los datos coincidan con los criterios requeridos; todo sin JavaScript. También puedes desactivar esta función: configurar el atributo novalidate en <form> o, con mayor frecuencia, formnovalidate en un botón, guardar los datos del formulario para completarlos más tarde, evita la validación.
Cómo enviar formularios
Los formularios se envían cuando el usuario activa un botón de envío anidado en él. Cuando se usa <input> para los botones, el "valor" es la etiqueta del botón y se muestra en el botón. Cuando se usa <button>, la etiqueta es el texto entre las etiquetas <button> de apertura y cierre. Un botón de envío se puede escribir de dos maneras:
<input type="submit" value="Submit Form">
<button type="submit">Submit Form</button>
Para un formulario muy simple, necesitas un elemento <form> con algunas entradas de formulario dentro y un botón de envío. Sin embargo, el envío de un formulario requiere de mucho más que eso.
Los atributos del elemento <form> establecen el método HTTP mediante el cual se envía el formulario y la URL que procesa el envío del formulario. Sí, los formularios se pueden enviar y procesar, y se puede cargar una página nueva sin JavaScript. El elemento <form> es tan potente.
Los valores de los atributos action y method del elemento <form> definen la URL que procesa los datos del formulario y el método HTTP que se usó para enviar los datos, respectivamente.
De forma predeterminada, los datos del formulario se envían a la página actual. De lo contrario, establece el atributo action en la URL a la que se deben enviar los datos.
Los datos enviados constan de pares nombre/valor de los distintos controles de formulario del formulario. De forma predeterminada, esto incluye todos los controles de formulario anidados dentro del formulario que tienen un name. Sin embargo, con el atributo form, es posible incluir controles de formulario fuera de <form> y omitir los controles de formulario anidados dentro de <form>. Compatible con los controles de formulario y <fieldset>, el atributo form toma como valor el id de la forma con la que está asociado, no necesariamente la forma en la que está anidado. Esto significa que los controles de formularios no necesitan estar anidados físicamente en un <form>.
El atributo method define el protocolo HTTP de la solicitud: por lo general, GET o POST. Con GET, los datos del formulario se envían como una string de parámetros de pares name=value, adjuntados a la URL de action.
Con POST, los datos se agregan al cuerpo de la solicitud HTTP. Cuando envíes datos seguros, como contraseñas e información de tarjetas de crédito, usa siempre POST.
También hay un método DIALOG. Si un <form method="dialog"> está dentro de un <dialog>, al enviar el formulario se cerrará el diálogo. Hay un evento de envío, pero los datos no se borran ni se enviaron. Nuevamente, sin JavaScript. Esto se analiza en la sección de diálogo. Ten en cuenta que, como no se envía el formulario, te recomendamos que incluyas formmethod="dialog" y formnovalidate en el botón de envío.
Los botones del formulario pueden tener más de los atributos descritos al comienzo de esta sección. Si el botón incluye un atributo formaction, formenctype, formmethod, formnovalidate o formtarget, los valores establecidos en el botón que activa el envío del formulario tienen prioridad sobre action, enctype, method y target configurados en <form>. La validación de restricciones ocurre antes del envío del formulario, pero solo si no hay un formnovalidate en el botón de envío activado ni un novalidate en <form>.
A fin de capturar qué botón se usó para enviar un formulario, otórgale un name. Los botones que no tienen nombre ni valor no se envían con los datos del formulario cuando se envía el formulario.
Después de enviar el formulario
Cuando el usuario envía un formulario en línea completado, se envían los nombres y valores de los controles de formularios relevantes. El nombre es el valor del atributo name. Los valores provienen del contenido del atributo value o del valor que el usuario ingresó o eligió. El valor de una <textarea> es su texto interno.
El valor de un <select> es el value del <option> seleccionado o, si <option> no incluye un atributo value, el valor es el texto interno de la opción seleccionada.
<form method="GET">
<label for="student">Pick a student:</label>
<select name="student" id="student">
<option value="hoover">Hoover Sukhdeep</option>
<option>Blendan Smooth</option>
<option value="toasty">Toasty McToastface</option>
</select>
<input type="submit" value="Submit Form">
</form>
Selecciona "Hoover Sukhdeep" (o no haces nada, ya que el navegador muestra y, por lo tanto, selecciona el primer valor de la opción de forma predeterminada) y, luego, haz clic en el botón Enviar, se volverá a cargar la página y se establecerá la URL de la siguiente manera:
https://web.dev/learn/html/forms?student=hoover
Como la segunda opción no tiene un atributo value, el texto interno se envía como valor. Si seleccionas "Blendan Smooth" y haces clic en el botón de envío, se volverá a cargar esta página y se establecerá la URL de la siguiente manera:
https://web.dev/learn/html/forms?student=Blendan+Smooth
Cuando se envía un formulario, la información enviada incluye los nombres y valores de todos los controles de formulario con nombre que tienen un name, excepto las casillas de verificación no seleccionadas, los botones de selección no seleccionados y los nombres y los valores de cualquier botón que no sea el que envió el formulario. En todos los demás controles de formularios, si el control tiene un nombre, pero no se ingresó ningún valor ni se estableció la configuración predeterminada, el name del control de formulario se envía con un valor vacío.
Existen 22 tipos de entrada, por lo que no podemos abarcar todos.
Ten en cuenta que incluir un valor es opcional y, a menudo, es una mala idea cuando deseas que el usuario ingrese información.
Para los elementos <input> en los que el usuario no puede editar el valor, siempre debes incluir un valor, incluso para los elementos de entrada con un tipo de hidden, radio, checkbox, submit, button y reset.
El uso de objetos name únicos para los controles de formularios simplifica el procesamiento de datos del servidor y es recomendable, ya que las casillas de verificación y los botones de selección son excepciones a esta regla.
Botones de selección
Si alguna vez observaste que cuando seleccionas un botón dentro de un grupo de botones de selección, solo se puede elegir uno a la vez, esto se debe al atributo name. Para crear este efecto de que solo se puede seleccionar uno, se le otorga el mismo name a cada botón de selección de un grupo.
Un name debe ser único para el grupo: si usas por error el mismo name para dos grupos diferentes, cuando eliges un botón de selección en el segundo grupo, se anulará la selección de cualquier selección realizada en el primer grupo con el mismo name.
Los name y el value del botón de selección seleccionado se envían con el formulario. Asegúrate de que cada botón de selección tenga un value relevante (y, por lo general, único). No se envían los valores de los botones de selección no seleccionados.
Puedes tener tantos grupos de botones de selección en una página como desees, y cada uno de ellos trabajará de forma independiente, siempre que cada uno tenga un name único para el grupo.
Si deseas cargar la página con uno de los botones de selección en un grupo con el mismo nombre, incluye el atributo checked.
Este botón de selección coincidirá con la seudoclase de CSS :default, incluso si el usuario selecciona una opción diferente. El botón de selección seleccionado actualmente coincide con la seudoclase :checked.
Si el usuario debe elegir un control de selección de un grupo de botones de selección, agrega el atributo required a al menos uno de los controles. La inclusión de required en un botón de selección de un grupo implica una selección obligatoria para el envío de formularios, pero no tiene que ser la opción de selección con el atributo que se selecciona para que sea válido. Además, indica claramente en el <legend> que se requiere el control de formulario. Más adelante, se describe el etiquetado de grupos de botones de selección junto con cada botón individual.
Casillas de verificación
Es válido que todas las casillas de un grupo tengan el mismo name. Solo se envían los name y value de las casillas de verificación seleccionadas con el formulario. Si tienes varias casillas de verificación con el mismo nombre seleccionada, se enviará el mismo nombre con valores diferentes. Si tienes varios controles de formularios con el mismo nombre, incluso si no son todos casillas de verificación,
todos se enviarán separados por signos de unión.
Si no incluyes un value en una casilla de verificación, el valor de las casillas seleccionadas se establecerá de forma predeterminada en on, lo que probablemente no sea útil. Si tienes tres casillas de verificación llamadas chk y están todas marcadas, no se podrá descifrar el envío del formulario:
https://web.dev/learn/html/forms?chk=on&chk=on&chk=on
Para que la casilla de verificación sea obligatoria, agrega el atributo required. Siempre informa al usuario cuándo se debe marcar una casilla de verificación o cuando se requiere algún control de formularios. Agregar required a una casilla de verificación solo hace que esa casilla sea obligatoria; no afecta a otras casillas de verificación con el mismo nombre.
Etiquetas y conjuntos de campos
Para que los usuarios sepan cómo completar un formulario, este debe ser accesible. Todos los controles de formularios deben tener una etiqueta.
También quieres etiquetar grupos de controles de formularios. Mientras que las áreas de entrada, selección y texto individuales se etiquetan con <label>, los grupos de controles de formulario se etiquetan con el contenido de <legend> del <fieldset> que los agrupa.
En los ejemplos anteriores, es posible que hayas notado que todos los controles de formularios, excepto el botón de envío, tenían una <label>. Las etiquetas proporcionan controles de formularios con nombres de accesibilidad. Los botones obtienen su nombre de accesibilidad de su contenido o valor. Todos los demás controles de formulario requieren un <label> asociado. Si no hay una etiqueta asociada, el navegador procesará los controles del formulario, pero los usuarios no sabrán qué información se espera.
Para asociar de forma explícita un control de formularios con un <label>, incluye el atributo for en <label> (el valor es el id del control de formularios con el que está asociado).
<label for="full_name">Your name</label>
<input type="text" id="full_name" name="name">
Asociar etiquetas con controles de formulario tiene varios beneficios. Las etiquetas permiten que los usuarios de lectores de pantalla accedan a los controles del formulario, ya que proporcionan un nombre accesible al control. Las etiquetas también son "áreas de acierto" y aumentan el área, ya que hacen que el sitio sea más útil para usuarios con problemas de destreza. Si usas un mouse, prueba hacer clic en cualquier lugar de la etiqueta "Tu nombre". Al hacerlo, se enfoca en la entrada.
Para proporcionar etiquetas implícitas, incluye el control de formulario entre las etiquetas <label> de apertura y cierre. Esto es igual de accesible desde la perspectiva del lector de pantalla y del dispositivo apuntador, pero no proporciona el gancho de estilo como la etiqueta explícita.
<label>Your name
<input type="text" name="name">
</label>
Dado que las etiquetas son "áreas de hits", no incluyas elementos interactivos dentro de una etiqueta explícita ni ningún otro componente interactivo en una etiqueta implícita que no sea el control de formulario etiquetado. Por ejemplo, si incluyes un vínculo en una etiqueta mientras el navegador procesará el HTML, tus usuarios se confundirán si hacen clic en la etiqueta para ingresar un control de formulario, pero se los redirecciona a una página nueva.
Por lo general, <label> aparece antes del control de formulario, excepto en el caso de los botones de selección y las casillas de verificación. Esto no es obligatorio.
Es solo el patrón común de UX. La serie de Formularios de aprendizaje tiene información sobre el diseño de formularios.
Para grupos de botones de selección y casillas de verificación, la etiqueta proporciona el nombre accesible del control de formulario al que está asociada; pero el grupo de controles y sus etiquetas también necesitan una etiqueta. Para etiquetar el grupo, agrupa todos los elementos en un <fieldset>, y el <legend> proporciona la etiqueta del grupo.
<fieldset>
<legend>Who is your favorite student?</legend>
<ul>
<li>
<label>
<input type="radio" value="blendan" name="machine"> Blendan Smooth
</label>
</li>
<li>
<label>
<input type="radio" value="hoover" name="machine"> Hoover Sukhdeep
</label>
</li>
<li>
<label>
<input type="radio" value="toasty" name="machine"> Toasty McToastface
</label>
</li>
</ul>
</fieldset>
En este ejemplo, los <label> implícitos etiquetan un botón de selección y el <legend> proporciona la etiqueta para el grupo de botones de selección.
Anidar un <fieldset> dentro de otro <fieldset> es una práctica estándar. Por ejemplo, si un formulario es una encuesta de muchas preguntas divididas en grupos de preguntas relacionadas, el <fieldset> "alumno favorito" puede estar anidado en otra <fieldset> etiquetada como "Tus favoritos":
<fieldset>
<legend>Your favorites:</legend>
<ul start="6">
<li>
<fieldset>
<legend>Who is your favorite student?</legend>
<ul>
<li>
<!-- the rest of the code here -->
El aspecto predeterminado de estos elementos hizo que no se usaran bien, pero <legend> y <fieldset> se pueden diseñar con CSS.
Además de todos los atributos globales, <fieldset> también admite los atributos name, disabled y form.
Cuando inhabilitas un conjunto de campos, se inhabilitan todos los controles de formularios anidados. Ni los atributos name ni los form tienen mucho uso en <fieldset>. Se puede usar name para acceder al conjunto de campos con JavaScript, pero el campo en sí no se incluye en los datos enviados (se incluyen los controles de formulario con nombre anidados).
Tipos de entrada y teclado dinámico
Como se señaló antes, hay 22 tipos diferentes de entradas.
En algunos casos, cuando un usuario usa un dispositivo con un teclado dinámico que se muestra solo cuando es necesario, como un teléfono, el tipo de entrada utilizado determina el tipo de teclado que se muestra. El teclado predeterminado que se muestra se puede optimizar para el tipo de entrada requerido.
Por ejemplo, el tipo tel mostrará un teclado optimizado para ingresar números de teléfono; email incluye @ y ., y el teclado dinámico para url incluye dos puntos y el símbolo de barra. Lamentablemente, el iPhone todavía no incluye : en el teclado dinámico predeterminado para los tipos de entrada url.
Teclados para <input type="tel"> en iPhone y dos teléfonos Android diferentes:
Teclados para <input type="email"> en iPhone y dos teléfonos Android diferentes:
Acceso al micrófono y a la cámara
El tipo de entrada de archivo <input type="file"> permite subir archivos a través de formularios. Los archivos pueden ser de cualquier tipo, definidos y limitados por el atributo accept. La lista de tipos de archivos aceptables puede ser una lista de extensiones de archivo separadas por comas, un tipo global o una combinación de extensiones y tipos globales. Por ejemplo, accept="video/*, .gif" acepta cualquier archivo de video o GIF animado.
Utiliza "audio/*" para archivos de sonido, "video/*" para archivos de video y "image/*" para archivos de imagen.
El atributo capture enumerado, que se define en la especificación de captura de contenido multimedia, se puede usar si se debe crear un nuevo archivo multimedia con la cámara o el micrófono del usuario. Puedes establecer el valor en user para los dispositivos de entrada para el usuario o en environment para la cámara posterior o el micrófono del teléfono. En general, usar capture, sin un valor, funciona porque el usuario elegirá qué dispositivo de entrada quiere usar.
<label for="avatar">A recent photo of yourself:</label>
<input type="file" capture="user" accept="image/*" name="avatar" id="avatar">
Validación integrada
Nuevamente, sin incluir JavaScript, el código HTML puede evitar que se envíen formularios con valores no válidos.
Hay algunos selectores CSS que coinciden con los controles de formulario según la presencia de atributos HTML, incluidos :required y :optional si el required booleano está configurado o no; :default si checked está hard-coded; y :enabled o :disabled, según si el elemento está presente y}.disabled La seudoclase :read-write coincide con elementos con contenteditable establecido y controles de formulario que se pueden editar de forma predeterminada, como los tipos de entrada number, password y text (pero no la casilla de verificación, los botones de selección ni el tipo hidden, entre otros). Si un elemento que normalmente admite escritura tiene establecido el atributo readonly, coincidirá con :read-only.
A medida que el usuario ingrese información en los controles de formularios, se activarán y desactivarán los selectores de IU de CSS, incluidos :valid, :invalid, :in-range y :out-of-range, según el estado. Cuando el usuario sale de un control de formulario, coincidirá la seudoclase :user-invalid o :user-valid que aún no es totalmente compatible.
Puedes usar CSS para proporcionar pistas sobre si los controles del formulario son obligatorios y si son válidos cuando el usuario interactúa con el formulario. Incluso puedes usar CSS para impedir que los usuarios hagan clic en el botón de envío hasta que el formulario sea válido:
form:invalid [type="submit"] {
opacity: 50%;
pointer-events: none;
}
Este fragmento de CSS es un antipatrón. Si bien tu IU puede resultar intuitiva y clara, muchos usuarios intentan enviar un formulario para habilitar los mensajes de error. Hacer que un botón de envío aparezca inhabilitado de esta manera no permite la validación de restricciones, una función en la que muchos usuarios confían.
El CSS aplicado se actualiza de forma continua según el estado actual de la IU. Por ejemplo, cuando incluyes tipos de entrada con restricciones, como email, number, url y tipos de fecha, si el valor no es nulo (no está vacío) y el valor actual no es un correo electrónico, número, URL, hora o fecha válidos, la seudoclase :invalid de CSS coincidirá. Esta actualización constante es diferente de la validación integrada de restricciones de HTML, que solo ocurre cuando el usuario intenta enviar el formulario.
La validación de restricciones incorporada solo es relevante para las restricciones establecidas con atributos HTML. Si bien puedes definir el estilo de un elemento según las seudoclases :required y :valid/:invalid, el navegador proporcionó mensajes de error derivados de errores basados en los atributos required, pattern, min, max e incluso type cuando se envía el formulario.
Cuando intentamos enviar el formulario sin elegir al estudiante favorito obligatorio, la validación de restricciones evita que se envíe el formulario debido a un error validityState.valueMissing.
Si alguna de las propiedades de validityState muestra true, el envío se bloquea y el navegador muestra un mensaje de error en el primer control de formulario incorrecto para enfocarlo. Cuando el usuario activa el envío de un formulario y hay valores no válidos, el primer control de formulario no válido mostrará un mensaje de error y recibirá el enfoque. Si un control obligatorio no tiene establecido ningún valor, si un valor numérico está fuera del rango o si un valor no es del tipo que requiere el atributo type, el formulario no se validará, no se enviará y aparecerá un mensaje de error.
Si un valor de number, fecha o hora es inferior al min mínimo establecido o superior al máximo establecido de max, el control será :out-of-range (y :invalid), y se le informará al usuario del error valididityState.rangeUnderflow,
validityState.rangeOverflow cuando intente enviar el formulario. Si el valor está fuera de pasos con el valor step, ya sea que se establezca de forma explícita o se establezca de forma predeterminada como 1, el control será :out-of-range (y :invalid) y se producirá un error validityState.stepMismatch. El error aparece en forma de burbuja y, de forma predeterminada, proporciona información útil sobre cómo rectificarlo.
Hay atributos similares para la longitud de los valores: los atributos minlength y maxlength alertarán al usuario sobre un error con validityState.tooLong o validityState.tooShort en el envío.
El maxlength también evita que el usuario ingrese demasiados caracteres.
Usar el atributo maxlength puede generar una mala experiencia del usuario. Por lo general, es una mejor experiencia permitir que el usuario ingrese más de la longitud de caracteres permitida con un contador, opcionalmente en forma de un elemento <output>, que no se envíe con el formulario, lo que le permitirá editar el texto hasta que el resultado muestre que no se superó la longitud máxima permitida. El maxlength se puede incluir en tu código HTML. Como todo lo que mencionamos, funciona sin JavaScript. Luego, durante la carga, el valor del atributo maxlength puede utilizarse para crear este contador de caracteres en JavaScript.
Algunos tipos de entrada parecen tener restricciones predeterminadas, pero no es así. Por ejemplo, el tipo de entrada tel proporciona un teclado numérico de teléfono en dispositivos con teclados dinámicos, pero no restringe los valores válidos. Para este y otros tipos de entrada, existe el atributo pattern. Puedes especificar una expresión regular con la que el valor debe coincidir para que se considere válido.
Si un valor es la string vacía y el valor no es obligatorio, no se generará un error validityState.patternMismatch. Si es obligatorio y está vacío, se mostrará al usuario el mensaje de error predeterminado de validityState.valueMissing en lugar de patternMismatch.
Es probable que la validityState.typeMismatch de los correos electrónicos sea demasiado comprensible para tus necesidades. Es probable que quieras incluir el atributo pattern para que las direcciones de correo electrónico de intranet sin un TLD no se acepten como válidas.
El atributo de patrón permite proporcionar una expresión regular con la que el valor debe coincidir. Cuando solicites una coincidencia de patrón, asegúrate de que el usuario tenga muy claro lo que se espera.
Todo esto se puede hacer sin una sola línea de JavaScript. Sin embargo, al ser una API HTML, puedes usar JavaScript para incluir mensajes personalizados durante la validación de restricciones. También puedes usar JavaScript para actualizar la cantidad de caracteres restantes, mostrar una barra de progreso para la seguridad de la contraseña o cualquier otra forma de mejorar de forma dinámica la finalización.
Ejemplo
Este ejemplo tiene un formulario dentro de una <dialog> con un <form> anidado con tres controles de formulario y dos botones de envío, con instrucciones y etiquetas claras.
El primer botón de envío cierra el diálogo. Usa formmethod="dialog" para anular el método predeterminado del formulario y cerrar <dialog> sin enviar los datos ni borrarlos. También debes incluir formnovalidate; de lo contrario, el navegador intentará validar la verificación de que todos los campos obligatorios tengan un valor. El usuario podría querer cerrar el diálogo y el formulario sin ingresar ningún dato. La validación evitaría que esto suceda. Incluye aria-label="close" porque "X" es una indicación visual conocida, pero no es descriptiva.
Todos los controles del formulario tienen etiquetas implícitas, por lo que no es necesario incluir los atributos id ni for. Ambos elementos de entrada tienen el atributo obligatorio que los hace obligatorios. La entrada de número tiene el step configurado de forma explícita para demostrar cómo se incluye step. Como step se establece de forma predeterminada en 1, se puede omitir este atributo.
<select> tiene un valor predeterminado que hace que el atributo required sea innecesario. En lugar de incluir el atributo value en cada opción, el valor se establece de forma predeterminada en el texto interno.
El botón Enviar al final establece el método de los formularios en POST. Al hacer clic en este botón, se verificará la validez de cada valor. Si todos los valores son válidos, se enviarán los datos del formulario, se cerrará el diálogo y es posible que la página redireccione a thankyou.php, que es la URL de acción. Si falta algún valor, si el valor numérico no coincide en los pasos o está fuera del rango, aparecerá un mensaje de error relevante definido por el navegador, no se enviará el formulario y no se cerrará el diálogo.
Los mensajes de error predeterminados se pueden personalizar con el método validityState.setCustomValidity('message here'). Ten en cuenta que, si configuras un mensaje personalizado, el mensaje se debe configurar explícitamente como una cadena vacía cuando todo sea válido o el formulario no se envíe.
Otras consideraciones
Hay toda una sección dedicada a ayudar a los usuarios a ingresar los datos correctos en los formularios. Para que los usuarios tengan una buena experiencia, es importante evitar que cometan errores. Para ello, debes incluir instrucciones y proporcionar sugerencias según sea necesario. Si bien en esta sección se explica cómo el solo HTML puede proporcionar validación del lado del cliente, la validación debe ser del cliente y del servidor. La validación se puede proporcionar de maneras discretas durante el proceso de completar el formulario, como agregar una marca de verificación cuando el valor es correcto. Sin embargo, no proporciones mensajes de error antes de que se complete el control del formulario. Si el usuario comete un error, infórmale dónde está y qué cometió.
Al diseñar formularios, es importante tener en cuenta que no todos son como tú. Alguien puede tener una sola letra como apellido (o ningún apellido), quizás no tenga un código postal, puede que tenga una dirección de tres líneas o quizás no tenga una dirección. Es posible que el usuario esté viendo una versión traducida de tu formulario.
Los controles de formularios, sus etiquetas y los mensajes de error deben ser visibles en la pantalla y ser precisos y significativos, y estar asociados de manera programática al elemento o grupo de formulario adecuado. El atributo autocomplete puede y debe usarse para permitir que los formularios se completen más rápido y mejorar la accesibilidad.
HTML proporciona todas las herramientas para que los controles de formulario básicos sean accesibles. Cuanto más interactivo sea un proceso o elemento de formulario, se debe prestar más atención a la accesibilidad con respecto a la administración del enfoque, la configuración y la actualización de los nombres, las funciones y los valores de ARIA, cuando sea necesario, y los anuncios en vivo de ARIA según sea necesario. Sin embargo, como aprendimos aquí, solo con HTML, puedes lograr un largo camino hacia tu objetivo de accesibilidad y validez sin recurrir a ARIA o JavaScript.
Verifica tus conocimientos
Pon a prueba tus conocimientos sobre formularios.
¿Cómo se hace para que los botones de selección formen parte del mismo grupo?
name.id.¿Qué elemento HTML se utiliza para indicarle al usuario para qué sirve este campo del formulario?
<h1><title><label>