Construyendo Componentes React Accesibles

Así que, hola a todos. Hoy hablaré sobre cómo construir aplicaciones web para todos. ¿Cómo cuidas la accesibilidad en el mismo campo? Así que, permítanme presentarme rápidamente. Soy Manjula Dube. Básicamente trabajo en Vanguard. Vanguard es la única empresa de gestión de activos más grande que es propiedad exclusiva de los inversores y no tiene propietarios ni accionistas. Esta estructura de propiedad por parte de los clientes nos ayuda a enfocarnos en los mejores resultados para nuestros clientes. También soy una experta en desarrollo web de Google. También soy organizadora en React India y JSConf India. Y así es como me encontrarán en Twitter y GitHub.

Algunas cosas sobre Vanguard. Estamos creciendo en Europa, Australia y también en Asia. Una cosa de la que me gustaría hablar es que, aunque somos una empresa enfocada en las finanzas desde el exterior, internamente nos enfocamos mucho en la tecnología y la accesibilidad en general. Un muy buen ejemplo de esto es que tenemos alrededor de 7,000 personas trabajando en el equipo de tecnología. Lo que creemos es que todos los usuarios tienen acceso igualitario a la información y funcionalidad independientemente de su capacidad. Una cosa en la que siempre creemos en Vanguard es que todos los usuarios tienen acceso igualitario a la información y funcionalidad independientemente de su capacidad. Y si quieres obtener más información sobre lo que hacemos en Vanguard, puedes visitar rápidamente este enlace.

Antes de comenzar, me gustaría decir que, porque lo que creemos en Vanguard es que trabajamos para garantizar que todos los inversores puedan acceder a nuestros productos y servicios para ayudarles a alcanzar sus metas financieras. Y hoy, lo que cubriré en esta presentación es todo sobre qué es la accesibilidad, cuáles son las prácticas comunes que puedes tener en cuenta al construir tus aplicaciones web con React. Y cubriremos todo tipo de prácticas comunes, cómo manejar formularios, manejo de errores, imágenes e iconos, animaciones y cómo puedes probar la accesibilidad. Para comenzar, siempre digo que no es una barrera para la innovación. De hecho, es una innovación para la web porque estás construyendo e incluyendo a todos para usar tu producto. Y cuando hablo de accesibilidad con React, no es algo de lo que debas tener miedo o evitar. Es simplemente cómo escribes tu HTML de manera semántica. ¿Y por qué debería importarte la accesibilidad? Quiero decir, estamos en este mundo donde no solo somos nosotros. Son nuestros amigos. Son nuestros abuelos. También son las organizaciones que están monitoreando nuestros sitios web. Y son personas con diferentes y variados antecedentes. Para comenzar, diría que hay personas con

discapacidades en todo el mundo. Hay discapacidades visuales, cognitivas. Y diría que debemos atender a todas ellas. Y para darte una estadística, diría que uno de cada diez usuarios siempre tendrá algún tipo de discapacidad. Y a veces la discapacidad puede ser situacional. Quiero decir, a menudo digo que la accesibilidad también depende de las situaciones.

Para comenzar rápidamente, diría qué es WCAG. A menudo nos encontramos con estos términos, ya sabes, cuando hablamos de accesibilidad en general. WCAG es un conjunto de directrices o técnicas publicadas por un grupo de trabajo en la iniciativa de accesibilidad del consorcio de la World Wide Web, también conocido como W3C. Y ves estas siglas AA y triple A. Estos son los tres niveles de cumplimiento para WCAG 2.1. Y cada nivel incluye directrices que deben cumplirse para determinar si tu sitio web es accesible o no. Estos niveles no son más que tres principios, que significan debe, debería y podría. Entonces, si tu sitio web desea cumplir con la accesibilidad, al menos debes seguir el nivel A. De lo contrario, si no lo sigues, es posible que tengas que lidiar con varios `A` en tu vida. Así que es mejor comenzar a seguir los estándares AA. Para darte un breve informe, lo que también descubrí es que en 2020, Web AIM realizó una pequeña investigación aleatoria en todos los principales sitios web y descubrieron que el 98.1% de las páginas de inicio de los principales sitios web tienen fallas en WCAG2, lo que significa, ya sabes, ¿cuáles son estos problemas comunes? Los problemas comunes son, ya sabes, texto de bajo contraste, texto alternativo faltante para imágenes o tal vez tienen enlaces vacíos, les faltan etiquetas de entrada de formulario. Entonces, aunque estos sitios web son de primera categoría, aún tienen fallas en WCAG2. Y cuando digo que tenía una visión muy equivocada de la discapacidad, siempre pensé que se trataba solo de personas ciegas, pero va mucho más allá de eso. Quiero decir, todos tenemos diferentes perspectivas, pero debemos comenzar a pensar y construir para todos. Para hablar rápidamente sobre los principios de la accesibilidad, hay cuatro principios fundamentales, lo que significa que tu sitio web debe ser perceptible por todos, lo que significa que deben estar disponibles subtítulos y otras alternativas. Debe ser operable. Quiero decir, la funcionalidad está disponible desde el teclado. Cualquier cosa aleatoria que intentes usar es utilizada y accesible para todos. Debe ser comprensible, lo que significa que el texto es legible, el contenido aparece y funciona de manera predecible. Y debe ser robusto, lo que significa, ya sabes, que el contenido es compatible con las herramientas actuales y futuras de los usuarios. Entonces, construir para todos, independientemente de qué marco estés utilizando, ya sea React, Angular, no importa realmente. ¿Cómo te imaginarías tu componente de entrada? Quiero decir, supongamos que tienes un componente de entrada, ¿cómo lo diseñarías? La forma en que yo lo diseñaría es, ya sabes, tendría mi ID, tipo, nombre, todas las cosas pasadas como una propiedad. Lo que debes notar aquí es que has pasado required igual a true. Ahora, cuando veo este componente de entrada, se ve algo así. Entonces, todos los componentes de entrada están básicamente vinculados mediante una etiqueta y un campo de entrada y créeme, es bueno

idea es siempre tener una etiqueta con el campo de entrada. Y si ves aquí, ya que pasé requerido igual a true como una propiedad, ya sabes, ya sabe que este campo es obligatorio. Y cuando pasas requerido igual a true, ya se encarga de indicar a los lectores de pantalla, si están navegando por tu componente de entrada. Y así es como lo harías básicamente. Entonces, si estás pasando una entrada, si estás pasando requerido como una propiedad, asegúrate de que, ya sabes, tus propiedades de entrada sean requeridas true. Ahora, una cosa, si ves aquí, es, ya sabes, también mencioné que el área requerida debería ser true. Entonces deberías hacer esto, ya sabes, como respaldo, porque podría haber, podría haber veces en las que, ya sabes, no tengas soporte de HTML5. Así que es bueno incluir también el área requerida como true. Entonces digamos que tienes múltiples campos requeridos. ¿Y cómo manejarías eso? La forma en que lo harías es, ya sabes, proporcionando información previa a los usuarios de lectores de pantalla. Diciendo que, ya sabes, todos los campos marcados con un asterisco son obligatorios. Así que ya sabes, ya tienen el contexto mientras navegan por tu aplicación web. Proporciona más instrucciones con más frecuencia. Puede haber un campo que sea requerido y que tenga un formato específico. Por ejemplo, un muy buen ejemplo es la fecha. Así que digamos que tenemos este componente de entrada al que le pasamos requerido. Y esto tiene, ya sabes, todas las propiedades que deben pasarse. Ahora, lo que sucede aquí es que, ya sabes, le estás dando una fecha, pero no sabes dónde se especifica cuál debería ser el formato de tu fecha. Entonces, aquí, lo que hago es, ya sabes, básicamente paso etiquetado por. Diciendo que, ya sabes, instruye. Y esta instrucción no es más que un ID de un elemento span donde dices, ya sabes, tu fecha debe tener el formato DDMMYY. Ahora, esto le dará a los lectores de pantalla suficiente información sobre este campo en particular. Entonces, ya sabes, estás proporcionando más información porque tus usuarios de lectores de pantalla pueden no saber cómo debe ser y cuál debe ser el formato. Entonces, cuando usamos etiquetado por, generalmente se utiliza para identificar el elemento que etiqueta el elemento actual. Lo que significa, ahora, veamos lo que hicimos aquí. Entonces, estábamos tratando de proporcionar más información sobre la etiqueta. Así que siempre prefiero hacerlo de una manera en la que use el atributo descrito por en lugar de etiquetado por. Te contaré rápidamente la diferencia entre ellos también. Entonces, aquí, en lugar de usar etiquetado por, usaría descrito por, y pasaría instruir a él, nada, un elemento span, y le doy un ID. ¿Por qué usé descrito por? Porque estoy proporcionando más información sobre la etiqueta. Y se usa etiquetado por generalmente cuando quieres sobrescribir la etiqueta y no proporcionar

más información al respecto. Entonces, prefiero usar área descrita por aquí. ¿Cómo manejarías los errores? Veamos rápidamente porque todos tenemos este error en los forms. Resulta que área descrita por es perfecta cuando quieres lidiar básicamente con el manejo de errores. Veamos rápidamente cómo lo harías. Así que este es un ejemplo muy pequeño donde dices dirección de correo electrónico no válida. Así que vamos a tener un componente de entrada. Asegúrate de que tu componente de entrada y el componente de error siempre estén vinculados juntos porque así es como debería ser, ya sabes. Cuando el lector de pantalla navega por tu sitio web, deben saber dónde está el error, cuál es el contexto. Qué campo tiene el error. Y como estos usuarios son usuarios de lectores de pantalla, necesitan tener ese contexto de dónde está el error. Así que siempre asegúrate de pasar un área descrita por, y el error no es más que un componente, que te mostraré más adelante en la siguiente diapositiva, es básicamente un componente y tiene un ID de errores de correo electrónico. Esto significa que tu entrada y errores siempre están vinculados juntos. Así que cada vez que haya un error, siempre dará una referencia de que este campo tiene un error. Cómo se verá tu componente de error es que tendrás un div con un rol de alerta, que es muy importante porque, ya que el lector de pantalla podría encontrar este elemento, necesita tener esa información. Ok, hay algo más importante que necesito corregir y el atributo de rol que pasas al div proporcionará esa información. Así que cosas muy importantes. Todo lo que digo es que un campo siempre debe estar mapeado al contenedor de error por área descrita por, y eso es como lo primero importante cuando estás lidiando con errores. Y también viste en el código que pasé un área no válida a eso. Así que ves aquí área no válida y la longitud de errores es mayor que cero. ¿Por qué hice eso? Porque área no válida siempre debe usarse en conjunto con la asociación y un array, lo que significa, ya sabes, siempre verificará. Quiero decir, si has pasado un campo requerido, definitivamente verificará el campo requerido. Si hay un error, verificará, ok, si la longitud del error es mayor que cero, ahora mostraré el error. Así es como funciona el área no válida. Y básicamente es una pista para el lector de pantalla de que el campo tiene un error.

¿Cómo manejarías los botones deshabilitados? Hablando de botones deshabilitados, quiero decir, ya sabes, todos hemos pasado por esto, que cuando deshabilitas el botón de envío, luego quieres que el usuario espere hasta que suceda lo que sea. Así que solo lo habilitarás entonces. Pero esto no es una buena idea. Quiero decir, no deshabilitar el botón. En primer lugar, a menudo

se elimina del árbol de accesibilidad. Así que no es realmente una buena idea. Lo que sugiero es, quiero decir, si tienes un componente, digamos, ya sabes, un componente de acción, que es como un botón para mí, y paso un atributo disabled, cómo deberías, ya sabes, lidiar con eso. Entonces, harías algo como esto, ¿verdad? Y tan pronto como le pases un atributo disabled, ya sabes, se elimina del árbol de accesibilidad, lo que significa que si los lectores de pantalla están pasando por ese botón deshabilitado, ya no tendrán idea de si este botón ya está allí o no. Entonces, para solucionar este problema, el botón de envío nunca debería estar deshabilitado, lo que significa que debería estar deshabilitado, pero de una manera, ya sabes, solo visible para los usuarios visuales. Entonces, lo que haría es deshabilitar el botón para los lectores de pantalla utilizando el área disabled y

aplica algunos estilos visuales para evitar el toque y el clic. Entonces, veamos rápidamente cómo harías esto. Lo que significa que tengo un botón. He pasado un atributo disabled en el área. Lo que significa que ahora mis lectores de pantalla sabrán, okay, este botón está desactivado. Pero para que se vea visualmente desactivado, le pasaré algunos CSS. Y, ya sabes, el CSS que usarías es cursor, not allowed, opacity, para que no se puedan tener eventos de puntero. Veamos qué harías para los usuarios de teclado. Evitarías el clic, ¿verdad? Quieres que el clic sea evitado. ¿Ya hemos terminado? No. Entonces, querrías habilitar el botón en algún momento. Asegúrate de establecer el atributo disabled en false, eliminar las clases de desactivado para que se vea visualmente habilitado.

y así es como lo harías. Hay algunos casos raros en los que podrías usar el atributo desactivado, quiero decir, definitivamente. Puede haber algunos escenarios en los que no puedas omitir. Entonces, estos escenarios son a menudo, ya sabes, tal vez tengas un carrusel y quieras llegar al primer o último elemento, tiene sentido usarlo. También puede haber algunos controles fuera de pantalla que no deben ser enfocables, tiene sentido también. A continuación, pasaría a los indicadores de enfoque. Quiero decir, a menudo, por defecto, si tienes algunos enlaces o botones y presionas la tecla tabulador, a menudo ves esto, ya sabes, un anillo de enfoque alrededor de tu elemento, y esto es proporcionado por defecto por los navegadores. No los elimines a menos que tengas una alternativa. Y incluso si tienes una alternativa, por ejemplo, ya sabes, lo que harías, ya sabes, tu diseñador viene y dice, okay, ya sabes, elimina el contorno predeterminado y, ya sabes, hazlo más personalizado para que sea consistente en todos los navegadores. Lo que harías es, en lugar de establecer el contorno en ninguno, diría que lo hagas transparente para que, ya sabes, en el modo de alto contraste, a veces la sombra del cuadro se comporta un poco extraño. Así que diría que no lo elimines. Quiero decir, haz que el contorno sea transparente.

¿Cómo probarías programáticamente tu enfoque? Diría que, ya sabes, cuando estés tratando con un componente de enlace, debes ser consciente de dónde está el enfoque. Entonces, ya sabes, toma el control de tu enfoque. Así que simplemente, si llego de una página a otra, asegúrate de que en esa página estás enfocando algún elemento principal que debería estar enfocado. Toma el control de tu enfoque. Si realmente quieres probar, ya sabes, prueba tus sitios web favoritos presionando la tecla tabulador, lo que significa que comenzarás a moverte hacia adelante en todos los elementos interactivos presentes en tu aplicación web. Y si quieres retroceder, shift más tabulador. A menudo digo que el manejo de diálogos es muy difícil porque, ya sabes, debes asegurarte de que también sean accesibles. Lo que significa que una vez que abres un diálogo, ya sabes, el enfoque debería estar en algún lugar del elemento principal. Y el modelo de área React es el que prefiero, es uno de los modelos accesibles que ya existen en la comunidad de React. Échale un vistazo. El modelo de diálogo de UI de React también es algo que he probado. Pero hay algunos problemas con los lectores de pantalla. Se comportan de manera un poco extraña. Así que también hay un problema adjunto a esto. Así que ve y revisa. Quiero decir, hay un problema adjunto en GitHub

enlace. También está el diálogo de React LI. Así que vale la pena revisarlo también. Y todos estos modelos son accesibles. Entonces, ya sabes, definitivamente puedes usarlos. A menudo también considero que el DOM y el orden visual siempre deben coincidir porque, ya sabes, a menudo tienes el poder de usar flexbox. Pero, ya sabes, debes tener cuidado de que no desincronice el DOM. Y tu orden visual y del DOM estén sincronizados. Ya sabes, a todos nos encanta el rendimiento. Quiero decir, sí. Pero, ya sabes, con el rendimiento, también debes tener cuidado de no arruinar la accesibilidad. Entonces, todos nosotros, esto es algo nuevo que ha surgido, la visibilidad automática del contenido. Y lo que hace es permitir que el agente de usuario omita la representación de los elementos hasta que sea necesario, lo que significa que la carga de tu página será mucho más rápida y permitirá una interacción más rápida del usuario con el contenido en pantalla. Pero una cosa a tener en cuenta es que debes usarlo en el lugar correcto. Si lo usas en un elemento que no debería estar dentro de él, por ejemplo, encabezados y otros contenidos, será suprimido por la visibilidad del contenido. Así que úsalo con precaución. También hay un buen artículo de Marcy Sutton que siempre le digo a la gente que lo lea. Ocultar contenido. Nuevamente, no lo uses. Porque, ya sabes, se elimina del árbol de accesibilidad. Así que no es una buena idea. Quiero decir, sí. En su lugar, lo que harías es, ya sabes, hay algunos de los casos válidos en los que querrías ocultar y mostrar el contenido. Quiero decir, todos queremos ocultar y mostrar algo en la aplicación web. Ahora, ¿cómo harías algo que sea accesible para los lectores de pantalla y aún así esté oculto para los usuarios? Quiero decir, te dije que no uses display none o, ya sabes, visibility. ¿Cómo lo harías? Me gustaría crear algún tipo de CSS usando clip path. Y una cosa a tener en cuenta aquí es que clip path está realmente obsoleto. Así que han introducido algo nuevo llamado clip. Pero a menudo también mantengo el clip path porque no todos los navegadores admiten clip todavía. Así que siempre es bueno tener un respaldo. Entonces, utilizando el CSS, hará que el contenido sea visible en la pantalla pero aún accesible para los usuarios. Así que es una buena idea. Cuando quieras ocultar algo, ya sabes, cuando quieras ocultar algo

que está oculto visualmente, siempre usa esto. Podrías crear un ayudante. Quiero decir, en el CSS, si estás usando styled components, lo que sea. Podrías simplemente crear un ayudante y siempre usar eso CSS en ese elemento. También podrías crear un componente. Quiero decir, envuelve el componente que tú quieras ocultar visualmente. Y rápidamente, déjame darte un poco de contexto de lo que sucedería cuando tú ocultas algo de los lectores de pantalla también. Entonces, ya sabes, usarías 'area hidden true'. Casos válidos serían contenido visual de tus iconos, lo que significa que aquí quieres dar algún significado a tus iconos y aún así asegurarte de ocultar algo de los lectores de pantalla. Así que esta es una tabla agradable donde, ya sabes, donde digo, ya sabes, a menudo usar ciertos atributos y clases, pero asegúrate de lo visible y accesible que es. Así que es una tabla rápida que resume las cosas. Hablemos del componente de icono. Quiero decir, todos nosotros tenemos iconos en nuestro proyecto, ¿verdad? ¿Cómo lidiarías con eso? Entonces, teniendo un componente de icono, y aquí, si ves, si se pasa un icono y mi flecha arriba a la derecha no es nada, pero es algún tipo de icono, que es como un SVG, y también he pasado una etiqueta como una propiedad. Ahora, cómo manejaría esto es que tendría un componente de icono, ya sabes, verificaría, okay, ya sabes, si no hay una etiqueta, simplemente devuelve el SVG. Quiero decir, devuelve ese icono en particular con 'area hidden', lo que significa que no requerimos que el icono sea conocido por los usuarios de lectores de pantalla. Entonces, ya sabes, esto es por qué queremos usarlo aquí. Y, ya sabes, si ya se ha pasado una etiqueta al componente de icono, simplemente puedes mostrarla y asegurarte de que esté oculta visualmente, porque, ya sabes, quieres dar esta información solo a los usuarios de lectores de pantalla. Y también hay un buen ejemplo de icono de enlace, que puedes revisar más tarde. Si quieres saber más sobre cómo trabajar con iconos SVG, hay un buen artículo de Florence. Definitivamente vale la pena revisarlo. ¿Cómo lidiarías con el componente de imagen? Lo mismo, quiero decir, debes asegurarte de que estás pasando el atributo 'alt' y la fuente. Y si quieres aplicar algún tipo de CSS, hazlo. Ahora, aquí ves lo que he hecho, ya sabes, si estás pasando el texto alternativo, asegúrate de aplicarlo. Y asegúrate, ya sabes, a veces es posible que solo quieras aplicar recorte, te gustaría aplicar recorte porque tiene sentido. Y lo que también ves es que he agregado un punto, lo que significa, ya sabes, el lector de pantalla sabrá que él o ella, ellos deben hacer una pausa aquí para esa oración en particular. Y realmente ayuda a los usuarios de lectores de pantalla a comprender. Cómo tú y, ya sabes, todos nosotros lidiaríamos con abrir un enlace en una pestaña y cómo lidiarías con esto. Entonces, yo prefiero cuando el lector de pantalla está navegando en tu sitio web, cada vez que abren un enlace en una nueva, ya sabes, en tu sitio web, debería haber una advertencia que se pronuncie para que sepan que este enlace en particular se está abriendo en una nueva pestaña. También debería haber una advertencia visual en el texto de que el enlace se está abriendo en una nueva pestaña. Así que cualquiera de las dos cosas, rápidamente, si tomas el componente, he hecho lo mismo. Has pasado algo como una clase 'visual hidden', que solo será visible

que estará, ya sabes, oculto visualmente. Lo que significa que no estará disponible para los usuarios visuales, pero aún así será accesible para los lectores de pantalla. Y dice 'abriendo en una nueva pestaña'. Lo que significa que ahora, cuando estés intentando abrir algo en una nueva pestaña, los lectores de pantalla ya tendrán suficiente información al respecto. Al crear animaciones accesibles, suelo decir, quiero decir, soy un gran fanático de las animaciones, pero debes usarlas adecuadamente. Creo que a muchas personas no les gustan y debes tener en cuenta que no todos las experimentan de la misma manera. Algunos pueden sentir mareos, náuseas. Por lo tanto, no debes tener demasiadas animaciones en tu sitio web. Y si las tienes, haz un interruptor para que el usuario pueda desactivarlas, ya sabes, que estén apagadas y que tengan esa opción en tu sitio web. Ya existe una forma de hacerlo en tus máquinas con Windows o Mac. Puedes ir a las preferencias del sistema y desactivar la opción de reducir el movimiento, lo que significa que todas tus animaciones se desactivarán. O puedes utilizar una consulta de medios que prefiera el movimiento reducido y utilizarla, lo que significa que todas tus animaciones estarán desactivadas en ese sitio web en particular. Hay un buen artículo de Josh. Definitivamente vale la pena leerlo sobre las animaciones. Una cosa que también digo es que debes tener cuidado con lo que animas. Siempre proporciono una opción para que el usuario la desactive si no desea animaciones. Hay una buena charla de Well Had. Habla sobre el movimiento inclusivo. Vale la pena echarle un vistazo.

¿Cuáles son las herramientas de desarrollo que utilizarías? ¿Y cuáles son las verificaciones que utilizarías para la accesibilidad? Entonces, Jxli es una de las herramientas que verifica estáticamente los errores de accesibilidad. Vale la pena verificarlo. Hay aXe core que puedes usar en tu aplicación React y te dará todas las advertencias en la consola de antemano. Si el problema es moderado o grave, puedes comenzar a solucionarlo. Hay pruebas automatizadas de accesibilidad que se llaman Peli. Se ejecutan pruebas de accesibilidad en tus páginas a través de la línea de comandos. Básicamente, NodeJS. Definitivamente vale la pena verificarlo. Asegúrate de que, si estás utilizando sistemas de diseño, estás utilizando complementos de Storybook para que todos tus elementos de accesibilidad se verifiquen correctamente desde el principio. También puedes utilizar extensiones del navegador web para verificar todos los problemas de accesibilidad. También escribí un libro para resumir todo lo que aprendí en los últimos dos años. Ve a echarle un vistazo. Y sí, muchas gracias. Y sí, que todos tengan un hermoso día. Esa fue una charla increíble y muy informativa. Ya aprendí mucho. Un gran agradecimiento a Manjuta. Y vamos a verificar la respuesta a la pregunta. Entonces, Manjuta preguntó cuál de estos no era un principio de accesibilidad. Y ustedes, el 51% de ustedes, dijeron que uno de los principios de accesibilidad principales no es que algo sea reproducible. Bueno, descubramos la respuesta. Tengo a Manjuta conmigo. ¿Cómo estás hoy? Sí, estoy bien. ¿Cómo estás tú? Estoy bien. Gracias. Entonces, ¿puedes decirnos cuál fue la respuesta correcta o incorrecta? Sí, eso es correcto. Reproducible no es un principio de accesibilidad.

Sí, me alegra haberlo acertado también. Estoy súper feliz. Pero tenemos un par de preguntas. En realidad, tenemos muchas preguntas. A la gente le encanta esta charla y quiere aprender mucho más sobre ella. Así que no podré responder a todas estas preguntas, pero solo quiero recordarles que habrá una sala de conferencias donde pueden hacer su pregunta si se les pasó por alto. Así que las responderemos en orden para ser justos. Tenemos una pregunta de Jordan que preguntó si los usuarios ciegos o discapacitados podrían ver el asterisco. ¿Y se indicaría completamente cuando estén enfocados en el campo? No, no podrían verlo, definitivamente. Pero cuando el lector de pantalla lo lea, lo leerá en voz alta diciendo `asterisco`. Pero básicamente, el asterisco tiene algunos problemas con todos los lectores de pantalla, y por eso tenemos estos campos requeridos que pasan por y, básicamente, les indica que este es un campo requerido. No todos los lectores de pantalla leen el asterisco en voz alta, lo que puede ser confuso para el usuario ciego. Sí, es algo en lo que nunca había pensado, pero lo aprendí hoy. Tenemos otra pregunta de Benito sobre las fechas. Entonces, para los campos de fecha, ¿es mejor usar campos de texto con instrucciones claras que los seleccionadores de fecha donde no se puede escribir la fecha? ¿Puedes repetir la pregunta? Entonces, preguntaron sobre los campos de fecha. Y preguntaron si para un campo de fecha, ¿sería mejor usar un campo de texto con instrucciones claras sobre el formato o un seleccionador de fecha? Sugeriría crear tu propio seleccionador de fecha que también maneje texto, porque a veces esto es realmente necesario para los usuarios de lectores de pantalla. Puedes usar una biblioteca de terceros, pero asegúrate de tener una alternativa que admita lectores de pantalla que solo sea visible para los lectores de pantalla, aunque no sea visible visualmente, pero sí, tener un campo de texto es realmente una gran idea. Genial. Ahora hablamos antes sobre testing y llevemos esto al ámbito de la accesibilidad. Tenemos a Hama que preguntó, ¿qué biblioteca sugerirías usar para testing automáticamente la accesibilidad? Creo que también mencioné en mi charla a Peli, que es una especie de herramienta de testing automatizada y se ejecuta básicamente en tu terminal. Entonces, si la incorporas en tu proyecto, puedes ejecutarla, puedes tenerla en tu proceso de compilación y puedes tenerla como un proceso de testing automatizado. Mientras se ejecuta tu compilación, también puedes probar automáticamente si algo falla o si algo no está bien. Así que sugeriría que Peli es una de las grandes herramientas. Bien. Hama también tiene otra pregunta, ¿qué principios tienen en su empresa para verificar la accesibilidad como parte de la implementación ágil? ¿Hay alguna parte específica de ese proceso donde se habla de la accesibilidad? Creo que usamos herramientas y siempre es bueno usar herramientas. Pero, ya sabes, no todos los problemas se pueden resolver usando herramientas. Usamos X-Core, que es una herramienta buena, pero también nos aseguramos de hacer muchas pruebas de usuario utilizando lectores de pantalla, lo cual sugiero a todos, aunque, ya sabes, intenta navegar por tu sitio web utilizando solo el teclado como si fueras un usuario ciego y ve si puedes navegar por tu sitio web. Genial. Creo que es una muy buena idea comenzar si ya estás introduciendo la accesibilidad en tu empresa. Genial. Siempre hay pasos sencillos que las personas pueden seguir. Muchas gracias, Bhanjula. Ha sido genial pasar tiempo contigo. Gracias. Muchas gracias.