Construyendo Componentes React Accesibles

Rate this content
Bookmark

Con la creciente comunidad y los excelentes tutoriales, hoy en día es bastante fácil comenzar a construir aplicaciones web con React. Sin embargo, a menudo se pasa por alto el aspecto vital de la accesibilidad, lo que lleva a que las aplicaciones web creen exclusiones. Nada en React nos impide construir experiencias web accesibles, pero debemos aprender a aprovechar su poder de la manera correcta mientras enfrentamos algunos desafíos únicos causados por la creación de páginas web con JavaScript. Esta charla se centrará en cómo resolver estos problemas en el contexto de React. También enfatizará por qué es importante construir aplicaciones web accesibles. Al final, también compartiré algunas cosas interesantes y herramientas para hacer que tu aplicación web sea más accesible.

Manjula Dube
Manjula Dube
34 min
14 May, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla de hoy se centró en la accesibilidad en las aplicaciones web, abordando temas como las pautas WCAG, el manejo de campos requeridos y formatos de campo, el manejo de errores y botones deshabilitados, y la importancia del orden DOM y visual. La charla también discutió la accesibilidad de elementos y enlaces ocultos, el impacto de las animaciones en la accesibilidad y el uso de herramientas de desarrollo para pruebas de accesibilidad. La sesión de preguntas y respuestas abordó preguntas sobre asteriscos en campos requeridos, entradas de fecha y herramientas de prueba automatizadas. En general, la charla enfatizó la importancia de construir aplicaciones web accesibles para todos los usuarios.

Available in English

1. Introducción a la Accesibilidad en Aplicaciones Web

Short description:

Hoy hablaré sobre cómo construir aplicaciones web para todos y cómo cuidar la accesibilidad. Soy Manjula Dube, una experta en desarrollo web de Google. Vanguard es una empresa de gestión de activos propiedad de los clientes y enfocada en la tecnología y la accesibilidad. Creemos en el acceso igualitario para todos los usuarios. En esta presentación, cubriré qué es la accesibilidad, prácticas comunes en la construcción de aplicaciones web con React y cómo probar la accesibilidad. La accesibilidad es una innovación que incluye a todos y debería importarte porque afecta a personas con diferentes antecedentes y habilidades.

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

2. Comprensión de la Accesibilidad y las Directrices WCAG

Short description:

Existen diferentes tipos de discapacidades y es importante considerar todas ellas. WCAG es un conjunto de directrices publicadas por W3C para garantizar la accesibilidad de los sitios web. Seguir los estándares AA es crucial para cumplir con la accesibilidad. Muchos sitios web importantes aún tienen fallas en WCAG2, como texto de bajo contraste y texto alternativo faltante para imágenes. La accesibilidad no se trata solo de personas ciegas, se trata de construir para todos. Los cuatro principios fundamentales de la accesibilidad son perceptible, operable, comprensible y robusto. Al diseñar componentes de entrada, es importante incluir etiquetas.

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

3. Manejo de Campos Obligatorios y Formatos de Campos

Short description:

Cuando se pasa la propiedad requerida a un componente de entrada, automáticamente indica a los lectores de pantalla que el campo es obligatorio. Además, se recomienda incluir el atributo requerido en el área como respaldo. Para múltiples campos requeridos, proporciona información previa a los usuarios de lectores de pantalla indicando que los campos marcados con un asterisco son obligatorios. Para campos con formatos específicos, utiliza el atributo etiquetado por para dar instrucciones a los lectores de pantalla sobre el formato. Alternativamente, se puede utilizar el atributo descrito por para proporcionar más información sobre la etiqueta.

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

4. Manejo de Errores y Botones Deshabilitados

Short description:

Prefiero usar área descrita por para el manejo de errores. Siempre vincula el componente de entrada y el componente de error juntos. Pasa un área descrita por para dar una referencia cuando hay un error. El componente de error debe tener un div con un rol de alerta. No se deben usar botones deshabilitados, ya que a menudo se eliminan del árbol de accesibilidad.

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

5. Manejo de Botones Deshabilitados

Short description:

Si tienes un componente como un botón y pasas un atributo disabled, se elimina del árbol de accesibilidad, lo que lo hace inaccesible para los lectores de pantalla. Para solucionar esto, deshabilita el botón para los lectores de pantalla utilizando el área disabled y aplica estilos visuales para evitar el toque y el clic.

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

6. Desactivar y Activar Botones

Short description:

Para desactivar un botón para los lectores de pantalla, utiliza el atributo disabled en el área y aplica propiedades CSS como cursor, not allowed y opacity. Para los usuarios de teclado, evita el evento de clic. Para habilitar el botón, establece el atributo disabled en false y elimina las clases de desactivado.

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.

7. Manejo del Atributo Desactivado y de los Indicadores de Enfoque

Short description:

Hay algunos casos raros en los que podrías usar el atributo desactivado. A continuación, los indicadores de enfoque no deben eliminarse a menos que tengas una alternativa. En lugar de establecer el contorno en ninguno, hazlo transparente. Prueba programáticamente tu enfoque tomando el control de él. Prueba tus sitios web favoritos presionando la tecla tabulador. El manejo de diálogos es difícil, pero hay modelos accesibles en la comunidad de React. Echa un vistazo al modelo de área de React y al modelo de diálogo de UI de React. Hay algunos problemas con los lectores de pantalla, así que revisa el problema adjunto en GitHub.

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

8. Accesibilidad y Orden del DOM

Short description:

Todos estos modelos son accesibles. Considera el orden del DOM y visual para mantenerlos sincronizados. Equilibra el rendimiento y la accesibilidad con la visibilidad automática del contenido. Úsalo con precaución y evita ocultar contenido. En su lugar, utiliza CSS con clip path para ocultar el contenido manteniéndolo accesible.

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

9. Manejo de Elementos y Enlaces Ocultos

Short description:

Podrías crear un ayudante o un componente para ocultar visualmente elementos. Usa el atributo 'area hidden true' para ocultar contenido de los lectores de pantalla mientras proporcionas significado a los iconos. El componente de icono puede mostrar el icono SVG con 'area hidden' si no se proporciona una etiqueta, o ocultar visualmente la etiqueta para los usuarios de lectores de pantalla. Aplica texto alternativo a los componentes de imagen y considera agregar pausas con puntuación para una mejor comprensión. Proporciona una advertencia hablada y visual al abrir enlaces en nuevas pestañas.

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

10. Accesibilidad de Animaciones y Herramientas de Desarrollo

Short description:

Las animaciones deben utilizarse adecuadamente para garantizar la accesibilidad. No todos los usuarios disfrutan de las animaciones y algunos pueden experimentar mareos o náuseas. Evita las animaciones excesivas en tu sitio web y proporciona un interruptor para que los usuarios las desactiven. Puedes desactivar las animaciones en las preferencias del sistema o utilizar una consulta de medios para reducir el movimiento. Ten en cuenta qué elementos animas y considera el movimiento inclusivo. Consulta el artículo de Josh y la charla de Well Had para obtener más información.

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.

11. Herramientas de Desarrollo y Principios de Accesibilidad

Short description:

Las herramientas de desarrollo para accesibilidad incluyen Jxli, aXe core y Peli. Jxli verifica estáticamente los errores de accesibilidad, mientras que aXe core proporciona advertencias en la consola. Peli es una herramienta automatizada de pruebas de accesibilidad. Además, el uso de complementos de Storybook y extensiones del navegador web puede ayudar a verificar problemas de accesibilidad. Manjuta también escribió un libro resumiendo sus aprendizajes. La respuesta correcta a la pregunta es que reproducible no es un principio de accesibilidad.

¿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.

QnA

Preguntas y Respuestas sobre Accesibilidad y Pruebas

Short description:

Recibimos varias preguntas de la audiencia sobre accesibilidad. Una pregunta fue sobre usuarios ciegos o discapacitados que pueden ver el asterisco en los campos requeridos. Otra pregunta fue sobre el método de entrada preferido para los campos de fecha, si es mejor usar campos de texto con instrucciones claras o seleccionadores de fecha. También discutimos el uso de herramientas de pruebas automatizadas como Peli para probar la accesibilidad. Además, se mencionaron los principios para verificar la accesibilidad en una implementación ágil, incluido el uso de herramientas como X-Core y pruebas de usuario con lectores de pantalla.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
(Easier) Interactive Data Visualization in React
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Concurrent Rendering Adventures in React 18
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn