Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Forms Everyone Can Use
- 1. Forms everyone can use Daniel Marin
- 2. Lo primero es el idioma
- 3. Configurar el idioma A nivel de la aplicación: A nivel de un elemento:
- 4. No olvides dar etiquetas a los campos
- 5. Importancia de las etiquetas
- 6. Configurar etiquetas Opción #1: Atributo for Opción #2: Atributo aria-labelledby Opción #3: Atributo aria-label
- 8. En caso de error, debemos saber qué ocurrió
- 9. Incluyendo Validación - Definimos un FormGroup con los campos deseados. - Luego debemos agregar la validación deseada. - Presentar errores de validación al usuario.
- 10. Presentar errores - Agregar sección para mostrar errores del campo. - Asignar id a cada error de validación. - Agregar todos los ids de errores de validación separados por espacio. - Asignar la propiedad aria- invalid cuando el campo posee algun error.
- 11. Escuchando errores de un campo Luego de unos ajustes al CSS.
- 13. Acciones fuera del formulario Esto es lo que debes evitar hacer.
- 14. Acciones dentro del formulario Esto es lo que debes intentar hacer.
- 16. Opciones de autocompletado name - Nombre completo del usuario. honorific-prefix - Prefijo o titulo (Sr, Sra). given-name - Primer nombre del usuario. family-name - Apellido del usuario. new-password - Nueva contraseña Y muchos más...
- 18. Obtener campos inválidos - Crear propiedad para guardar los campos fallidos. - Crear propiedad para tener referencia a la sección de errores. - Al hacer submit obtener campos fallidos. - Al hacer submit enviar focus a la sección de errores.
- 19. Sección de errores - Agregamos una nueva sección a nuestra plantilla. - Le damos el atributo tabindex a la nueva sección. - Recorremos los campos fallidos y muestras un vínculo apuntando al campo respectivo.
- 20. Resultado final
- 21. Conclusión
Notas del editor
- Los formularios son parte clave del desarrollo web, Angular no es la excepción. El objetivo principal de un formulario es permitir a los usuarios interactuar con nosotros, como desarrolladores pasamos horas trabajando con aplicaciones, hemos diseñado muchos formularios y hemos usado aún más, pensamos que usar un formulario es fácil y que todos los usan con igual de facilidad. La verdad es que para muchos usuarios los formularios son un dolor de cabeza. Para nosotros como desarrolladores, puede que no, pero para personas con menor contacto con la tecnología o que sufren de una discapacidad, formularios pueden representar obstáculos que les impiden cumplir su objetivo, usar tu aplicación. Así que el día de hoy vengo a hablarles sobre “Forms everyone can use” o su traducción “formularios que todos pueden usar”. No les voy a dar la solución a todos sus problemas, pero les voy a enseñar algunas cosas que quizás no sabían aún y que pueden ayudar a muchos de sus usuarios. Mi nombre es Daniel Marin, soy Ingeniero de Software en This Dot y Co-Organizador de Angular Montevideo.
- Lo primero es el idioma. Esta charla es en español pero el título está en inglés, antes de empezar debía traducir el título. Tus aplicaciones deberían comportarse de la misma manera. Por suerte, HTML nos permite especificar el lenguaje de nuestro documento, solo debemos preocuparnos por especificar el idioma. Esto es especialmente importante para usuarios con Lectores de Pantalla y para asegurarme de convencerlos acá les traigo un trabalenguas en español: Ruidosos truenos rodaban por una rocosa región, las rocas cayeron al río, el río se arremolinó. Y así se lo lee un Lector de Pantalla configurado en Inglés. Me imagino en este momento la cara de más de uno, como diciendo: “queeee”. La verdad es que esa fue mi reacción, el hecho de pensar que mis aplicaciones podrían “sonar” de esta manera me hizo dudar de todo lo que sabía de HTML y me hizo investigar más sobre la accesibilidad.
- Configurar el idioma es bastante sencillo, lo primero que debemos tomar en cuenta es que podemos hacerlo a nivel de la aplicación o a nivel de un elemento. En el ejemplo de la izquierda configuramos el idioma a nivel de la aplicación; usando el atributo “lang” con el valor “es” para indicar que nuestro documento es en español. Lo más común es que una aplicación tenga un solo idioma, pero en caso de excepción, podemos asignar otro idioma a un elemento específico como podemos observar en el ejemplo de la derecha.
- No olvides dar etiquetas a los campos. Una etiqueta es el nombre que damos a un campo para que los usuarios puedan identificarlos, por lo general tratamos de usar nombres autodescriptivos que le indiquen al usuario el propósito de dicho campo. Sin etiquetas los usuarios tendrían muchos problemas al llenar formularios, lo que lleva a usuarios descontentos que NO ES LO QUE QUEREMOS, cierto? Muchas veces nos dejamos llevar por lo que vemos, el hecho de que un campo tenga un texto encima NO quiere decir que tenga una etiqueta, las etiquetas deben ser configuradas de la manera apropiada o estamos haciendo el trabajo a medias.
- Acá les traigo el perfecto ejemplo de lo que les explicaba en la diapositiva anterior. Tenemos dos campos, ambos “se ven” iguales pero les pregunto, sonarán igual? Si se preguntan a qué me refiero, les muestro como un Lector de Pantalla, en este caso NVDA usando Chrome lee dos campos que se ven igual. Como ven, el primer caso ignora totalmente el texto, la razón es que “Nombre” no es más que un simple texto, mientras que en el segundo caso el “Nombre” fue configurado apropiadamente haciendo uso de etiquetas.
- Aprendamos a configurar etiquetas de la manera apropiada. Nuestro objetivo durante la configuración de etiquetas es darle un “significado” a cada campo. Antes de continuar, quiero aclarar que las opciones a continuación “suenan” igual pero tienen ciertas diferencias que evaluaremos ahora: La opción #1 es la más conocida. El único problema de este método es que necesitamos crear un id único para cada input, en el caso de Angular es común crear elementos reutilizables y si no lidiamos con el id de la manera apropiada podemos llegar a tener inputs con id repetido, lo cual es un anti patrón. La opción #2 es bastante parecida a la anterior pero con la relación invertida, seguimos teniendo el problema de los ids. La opción #3 tiene una diferencia clave, aunque “suene” igual a las opciones anteriores y no tenga que mantener un id único, no cuenta con la etiqueta como texto, en otras palabras, no hay un indicador visual del propósito del campo. Esta opción es la que menos van a usar.
- Si me preguntan, Daniel y cuál opción usas tu? Yo les diría; Ninguna de las anteriores. La opción que les recomiendo es esta. Lo primero que quiero que noten es que no hay un “id”. Al agregar un “input” dentro de un “label” HTML los vincula automáticamente. Eso significa que no tenemos que preocuparnos “ids” únicos. El texto dentro del “span” es agregado como el contenido textual del elemento “label”. Lo más interesante es que esto se “ve” y se “escucha” igual que las opciones anteriores pero sin la necesidad de agregar “ids”. Y por eso es mi opción preferida siempre que sea posible.
- En caso de error, debemos saber qué ocurrió. Es común que un formulario tenga restricciones, de esa manera es posible garantizar cierto nivel de consistencia cada vez que el formulario es enviado. Si ocurre algún error, decimos que el formulario es invalido y que al menos uno de sus campos tiene un “error de validación”. Estos errores suelen ser mostrados justo debajo del campo. Pero al igual que las etiquetas, sin la debida configuración los lectores de pantalla ignoran esta información adicional, afectando la experiencia de estos usuarios.
- Veamos cómo incluir validación en nuestras aplicaciones. Antes de continuar quiero aclarar que esta charla no es sobre ReactiveForms, así que no entraré en detalle, si están interesados en aprender más al respecto pueden contactarme y les envío algunos recursos interesantes. Empecemos definiendo nuestro formulario usando ReactiveForms. Suponiendo que tengamos un formulario bastante sencillo con tan solo 2 campos; nombre y apellido. Definimos un FormGroup con los campos. Luego configuramos la validación usando los Validators de ReactiveForms. La única restricción que agregaremos es que cada uno de los campos será obligatorio. Lo siguiente es asegurarnos de presentar los errores al usuario de la manera adecuada.
- Cómo presentar los errores. Una vez configurado el formulario con validación, queremos asegurarnos de mostrarle al usuario cuando hay un error. Para esto creamos una sección donde agrupamos todos los errores encontrados, a cada error le agregamos un id que agregamos al elemento input usando “aria-describedby”. > aria-describedby recibe uno o más ids separados por espacio. En caso de que los elementos no sean encontrados, estos son > simplemente ignorados. No se preocupen si tienen un id haciendo referencia a un elemento que no está presente en el DOM. Finalmente, no olviden agregar el atributo “aria-invalid” cuando el input está inválido. Los validadores de Angular hacen varias cosas por nosotros, pero lamentablemente no modifica el atributo “aria-invalid” del input por lo que tenemos que hacerlo nosotros manualmente.
- Luego de unos simples ajustes en CSS, podemos lograr que el campo de la lámina anterior se vea asi. De seguro se preguntarán para que todas esas propiedades “aria”? Para responder esa pregunta “escuchemos” la validación sin esas propiedades. Que sorpresa, no? El mensaje fue totalmente ignorado… Imaginen lo complicado que es llenar un formulario usando lectores de pantalla y que además los campos no te indiquen los errores. Ahora escuchemos la versión que tiene nuestros ajustes.
- Agrupar acciones dentro del formulario es importante. Los formularios vienen con acciones predeterminadas como lo son “submit” y “reset”. Si las acciones se manejan fuera del formulario, haciendo uso del evento “click”, los usuarios con lectores de pantalla tendrán dificultades al interactuar con el formulario. Un pequeño detalle que no deben olvidar es que un formulario tiene un solo “submit” y aunque hay maneras de tener varios “submit”, debes tratar en todo momento de no tener más de uno.
- Esto es lo que debes evitar hacer. Muchas veces estamos tentados a extraer las acciones del formulario, un caso bastante común es cuando el formulario tiene varios pasos y queremos reutilizar el layout, dejando los botones para saltar entre pasos fuera del formulario. Esto es algo que puede implicar cambios estructurales en tu aplicación y por esa razón la recomendación es tener en cuenta la accesibilidad durante el proceso de diseño. Un detalle importante es que al hacer esto que ven acá, pierden la habilidad nativa de hacer “submit” al formulario cuando presionas “Enter”. Si deseas mantener dicha funcionalidad debemos hacerlo manualmente utilizando javascript.
- Esto es lo que debes intentar hacer. Hay casos donde no es posible debido al diseño o a la estructura del HTML. En esas situaciones, la recomendación es asegurarse de que al presionar “enter” hacen submit del formulario aunque no haya un botón de “submit” debidamente definido. Esto es útil para todos los usuarios, a diferencia de los atributos ARIA que benefician principalmente a usuarios con lectores de pantalla. Este es un claro ejemplo de la estrecha relación que existe entre la accesibilidad y la usabilidad.
- El autocompletado es tu amigo. Los navegadores tienen la capacidad de llevar registro de la información que agregas a formularios, con esta información es posible dar opciones de autocompletado para campos. Pero esto no es todo, el autocompletado provee a los campos de información adicional sobre su propósito, y además contamos con una serie de opciones que podemos usar. Yo siempre he pensado que llenar formularios es aburridisimo, una vez me fracture la mano izquierda y aprendí que pueden ser una pesadilla. El autocompletado empezó a ser mi mejor amigo, no sabes cuando tus usuarios lo puedan necesitar, así que no puedes olvidar habilitarlo.
- Acá les traigo algunas opciones de autocompletado, la verdad es que es una larga lista y lo último que quiero es que se duerman. Entre las opciones tenemos: Name: Nombre completo del usuario. Honorific-prefix: Prefijo o título. (Por ejemplo, Señor o Señora) Given-name: Primer nombre del usuario Family-name: Apellido del usuario. new-password: Nueva contraseña. Y muchas más opciones… Todo lo que tienen que hacer es agregar el atributo autocomplete con el valor más adecuado. Si quieren aprender sobre el resto de las opciones, pueden ingresar a la documentación de WCAG 2.1, en la sección de “Input Purposes”. https://www.w3.org/TR/WCAG21/#input-purposes
- Que tal si les digo que además de todo esto, podemos hacer algo extra. Como habrán notado hasta ahora, mucho de lo que les comente no requiere programación adicional. Pero quiero que piensen nuevamente en la validación y en los errores. Hasta ahora hemos hablado de tener errores por campo, esto es genial desde el punto de vista visual porque al ver el formulario automáticamente identificamos que campos tienen problemas. Usuarios con lectores de pantalla perciben esto de una manera muy diferente, pues en este caso tendrían que recorrer cada campo para saber cuáles tienen problemas, este es un proceso que puede ser engorroso en formularios con muchos campos. Ayuda a tus usuarios creando una sección donde se listan los campos fallidos como vínculos, de esta manera el usuario puede leer el campo fallido y automáticamente saltar a el.
- Para esto debemos agregar una nueva propiedad llamada camposFallidos donde almacenaremos una lista de los campos fallidos e inicializamos como un arreglo vacio. Por otra parte, creamos una propiedad usando el decorador ViewChild para tener una referencia a la sección que contendrá la lista de campos fallidos en el archivo HTML. Al hacer submit, si el formulario es invalido recorremos todos los campos y agregamos los campos inválidos a la propiedad campos fallidos. También nos aseguramos de que si algún error es encontrado hacemos focus al elemento en HTML. NOTA: Vean el atributo id de los campos fallidos, este nos va a permitir que el usuario sea redirigido al campo respectivo al interactuar con el mensaje de error. Estoy haciendo uso del hash del URL, el componente “AmigableComponent” se encuentra en la ruta “/amigable” por lo que no hay cambio de ruta, solo del focus. Otra cosa, esta no es la única manera de hacerlo, es probable que no puedas copiar y pegar esto para que sirva en tu caso. El aprendizaje detrás de este ejercicio es que entiendan la importancia de una funcionalidad como esta.
- Lo primero que debemos hacer es crear una nueva sección con un div para contener la lista de campos fallidos. A esta sección le vamos a dar el atributo “tabindex” igual a “-1”. El Atributo tabindex nos permite darle a un elemento la capacidad de recibir focus, el valor -1 hace que no podamos hacer focus en el elemento al navegar usando “TAB”, pero podemos hacer focus de manera imperativa con la ayuda de javascript. Si hay al menos un campo fallido, mostramos un texto descriptivo indicando al usuario que hay errores. Luego para cada campo fallido; agregamos un vínculo con un mensaje. Lo más interesante es que ahora el usuario tiene una clara indicación de que ocurrió un problema y una lista de los campos con problemas, puede recorrer la lista y saltar a cada campo fácilmente. No solo eso, además al hacer submit, si se encuentra un error hacemos focus en esta sección dando una indicación casi inmediata al usuario sobre lo ocurrido.
- Y bueno, así se ve y se escucha nuestro resultado final.
- Al final de la charla espero que los siguientes puntos les hayan quedado claros: No todos los usuarios son iguales y debemos preocuparnos por darles la mejor experiencia posible a todos. Que “se vea” bien, no indica que “se escuche” bien, vimos lo fácil que es hacer algo que parece estar bien pero que tiene muchos errores desde el punto de vista de la accesibilidad. Pensar en la accesibilidad durante el diseño nos ahorra dolores de cabeza Con agregar unos atributos podemos mejorar drásticamente la experiencia de los usuarios.
- Muchas gracias a todos por haber escuchado y gracias al equipo de organización por todo. Acá les dejo mis redes sociales en caso de que tengan alguna duda, por esos medios comparto mi contenido.