Sistema de Componentes Accesibles a través de la Personalización

Rate this content
Bookmark

La mayoría de las bibliotecas de UI actuales brindan una gran experiencia de usuario con una amplia variedad de componentes. Pero cuando se trata de personalización intensiva y escenarios no estándar, especialmente para el comercio electrónico, se vuelven difíciles de gestionar, escalar e incluso ralentizan el rendimiento.


¿Cómo crear una biblioteca de UI que brinde a los usuarios la mayor libertad posible para personalizar los componentes, al tiempo que mantenemos nuestro rendimiento y escalabilidad al máximo? ¿Cuánta accesibilidad podemos proporcionar de forma predeterminada a nuestros usuarios? ¿Cuánta libertad de personalización es suficiente?


Eso es de lo que trata mi charla.

30 min
01 Jun, 2023

Video Summary and Transcription

La charla aborda la importancia de construir una biblioteca de componentes de UI accesible, centrándose en la reutilización, personalización y capacidad de respuesta. Se enfatiza la necesidad de consistencia visual y funcional al desarrollar componentes y se destacan los aspectos clave de la accesibilidad, incluida la navegación por teclado, el contraste y la estructura del contenido. La charla también cubre la construcción de diálogos accesibles y brinda consejos para mejorar la experiencia del usuario. Se enfatiza la importancia de la documentación, la escalabilidad y la personalización en la planificación de componentes. La charla concluye discutiendo el uso de ARIA, las pruebas de accesibilidad y las estrategias para persuadir a las organizaciones a priorizar la accesibilidad.

Available in English

1. Introducción a la Biblioteca de Componentes de IU Accesibles

Short description:

¿Sabes qué? Todavía... Necesito recuperarme un poco de toda la noche de conseguir un Switch. Este es mi nuevo lema ahora, la Accesibilidad te traerá un Switch. Hablamos sobre la biblioteca de componentes de IU. ¿Qué define un componente en una biblioteca de componentes? Tiene que ser reutilizable, estilizable y personalizable. La accesibilidad es algo muy difícil y no relevante para la biblioteca de componentes en absoluto, pero esto es incorrecto. También significa que tienes un sitio web que se ve bien en escritorio, móvil y cualquier dispositivo, vista de pantalla, 200, 400 por ciento, todos hoy en día necesitan hacer zoom de todos modos, y eso se reduce a la capacidad de respuesta.

[♪ música ♪ y aplausos de la multitud ♪ ¿Sabes qué? Todavía... Necesito recuperarme un poco de toda la noche de conseguir un Switch. Aunque sé que no lo usaré, no sé quién lo usará.

De todos modos, ¿cómo están todos? ¿Están pasando un buen rato? ¡Sí! ¿Y sabes qué? Este es mi nuevo lema ahora, la Accesibilidad te traerá un Switch. De acuerdo. Ese es mi objetivo, hablar sobre componentes accesibles. Permíteme tomar un poco de agua. Disculpen. Woo, okay. Adelante.

Entonces, rápidamente sobre mí, porque tenemos 20 minutos, así que no tengo tiempo para hablar mucho sobre mí, Soy Maya Chavin, soy Ingeniera de Software Senior en Microsoft, y sí, no voy a arreglar la ventana por ti, así que no lo esperes. También escribo libros, tengo más para ver, React, cualquier cosa sobre diseño de componentes, puedes seguirme, o también puedes probar mi libro de forma gratuita.

De todos modos, hablamos sobre la biblioteca de componentes de IU. ¿Cuántas personas aquí han usado alguna vez un componente de IU en su vida? Oh, eso es mucho. ¿Cuántos de ustedes han escrito alguna vez una biblioteca de componentes? Wow, eso es bueno. Eso es exactamente lo que esperaba, porque si no levantas la mano, significa que o no haces bien tu trabajo, o no escribes ningún código frontend, y probablemente no deberías hacerlo.

De todos modos, ¿qué es exactamente una biblioteca de componentes? ¿Qué define un componente en una biblioteca de componentes? En primer lugar, tiene que ser reutilizable, lo que significa que si tienes una barra lateral, debe poder mostrar un menú o una tarjeta. Puedes reutilizarlo de muchas maneras, pero la funcionalidad sigue siendo la misma. Tiene que ser estilizable, lo que significa que tienes una notificación emergente. Se puede estilizar con diferentes colores y estilos para representar para qué está destinado. Además de esto, también necesitas asegurarte de que el componente que ofreces sea personalizable según las necesidades de los usuarios. Digamos que no quiero tener un ícono como el ícono predeterminado, puedo cambiarlo. O puedo decidir que el botón X no es lo suficientemente accesible, así que lo cambio por un botón de texto. Esto es personalizable. Y hablamos de eso, accesible.

Muchas personas, muchos desarrolladores, tienden a pensar que a nadie le importa la accesibilidad. La accesibilidad es algo muy difícil y no relevante para la biblioteca de componentes en absoluto, pero esto es incorrecto. Desarrollas un componente, debe ser accesible según algún estándar para que todo el sistema funcione en base a lo que haces. Y hablando de accesibilidad, también significa que tienes un sitio web que se ve bien en escritorio. También tiene que verse bien en móvil y no solo en móvil, en cualquier Zoom, cualquier dispositivo, vista de pantalla, 200, 400 por ciento, todos hoy en día necesitan hacer zoom de todos modos, y eso se reduce a la capacidad de respuesta.

2. Construyendo una Biblioteca de Componentes

Short description:

Y por último, los componentes que ofreces deben ser aislados y probables. Cuando desarrollas una biblioteca de componentes, debes asegurarte de tener consistencia visual y consistencia funcional. La biblioteca de componentes es solo una pequeña parte de todo el sistema de diseño que estás construyendo. Al construir una biblioteca de componentes, debes planificar y decidir qué, quién y por qué la construyes. Un ejemplo es Storefront UI, una biblioteca de componentes diseñada específicamente para la industria del comercio electrónico.

Y por último, los componentes que ofreces deben ser aislados y probables. Bueno, nadie usa una biblioteca de componentes sin ser probada adecuadamente, ¿verdad? Porque de lo contrario no quieres despertarte por la mañana y ver que alguien reportó otro error que pertenecía a la biblioteca de componentes porque la biblioteca de componentes no se probó y no tienes idea de cómo solucionarlo.

Y eso se refiere a estas categorías divididas en cosas. Una es la consistencia visual. Eso significa que cuando desarrollas una biblioteca de componentes debes asegurarte de tener un estándar a seguir. Colores, paletas, pintura, tipografía todas estas son cosas visuales. Ningún usuario querrá experimentar algo que no sea consistente, tanto el desarrollador como el usuario final. Esta es la parte de IU de la biblioteca de componentes.

Y la segunda categoría es la consistencia funcional. ¿Qué significa eso? Si el usuario ve un botón de cerrar en una barra lateral significa que, cuando haga clic en él, espera que se cierre. No importa lo que el diseñador te diga, un botón de cerrar solo necesita hacer una cosa. Cerrarlo. No sorprendas a nadie. A nadie le gustan las sorpresas. A mí no me gustan las sorpresas. Así que, simplemente no hagas nada adicional. Y esa parte es la experiencia de usuario de la biblioteca de componentes. Y estas dos categorías se reducen a una cosa.

La gente piensa que una biblioteca de componentes es algo así como, solo una gran cosa. Algo que ofreces y la gente lo usará. De hecho, una biblioteca de componentes es solo una pequeña parte de todo el sistema de diseño que estás construyendo. Y la biblioteca de componentes es en realidad el código de implementación después de que definas todas estas guías de estilo, sistema de diseño, temas, tipografía, todo lo demás. Y cuando desarrollas una biblioteca de componentes no es solo sentarte ahí y escribir código. Es sentarte ahí y planificar un buen sistema de diseño. Entonces, ¿cómo vamos a construir una biblioteca de componentes? Todo eso. Bueno, en primer lugar, no puedes decidir que quieres construir una biblioteca de componentes genérica que tenga todo lo demás, que tenga múltiples, muchos componentes para cada caso de uso individual. No, ese no es el caso. Cuando construyes una biblioteca de componentes debes planificar y decidir qué, quién y por qué la construyes. Y uno de los ejemplos es de uno de mis proyectos llamado Storefront UI. Construimos una biblioteca de componentes diseñada específicamente para un usuario de la industria del comercio electrónico.

3. Understanding Accessibility and Design

Short description:

De esta manera nos mantenemos más enfocados y basamos nuestro componente en cuatro categorías: personalización, escalabilidad, accesibilidad y facilidad de uso. La accesibilidad se trata de más que solo la apariencia visual. Incluye la navegación por teclado y asegurarse de que los elementos sean enfocables y utilizables. La navegación por teclado puede ser un desafío y es importante considerar las necesidades de accesibilidad de los usuarios con movilidad limitada. Otro aspecto importante de la accesibilidad es el contraste, que es crucial para los usuarios con discapacidades visuales. Además, es esencial considerar el diseño y la estructura del contenido para una experiencia amigable para el usuario.

De esta manera nos mantenemos más enfocados y basamos nuestro componente en cuatro categorías. Personalización, scalability, accessibility y facilidad de uso. Y hoy vamos a hablar solo de estas cuatro categorías. Bueno, deberíamos hablar más pero no tenemos tiempo. Así que empecemos. Accesibilidad, todos saben qué es la accesibilidad, ¿verdad? Bueno, entonces dime cómo vas a hacer clic en este botón. Necesitamos hacer clic en esto para continuar. ¿Alguien? ¿Alguna idea de cómo hacer clic en él? ¿Mi ratón? Ven, toma tu ratón y haz clic en él. ¿Por cualquier cosa? ¿Toque? ¿Puedes tocarlo desde aquí, desde lejos? No puedes porque no es accesible. Es la imagen. Así que no importa lo bien que se vea, no es enfocable, no es utilizable, no es accesible. Y eso significa accesibilidad, cuando hablamos de accesibilidad, hablamos de la navegación por teclado además de todo lo demás. Navegación por teclado, esta es en realidad una imagen divertida porque si prestas atención, no tendrás el botón de eliminar aquí. Así que si quieres hacer clic en control y eliminar, no podrás hacerlo. Esta es en realidad el teclado real que fue diseñado hace mucho tiempo. Así que tienen el teclado y luego tienen otro teclado adicional para el botón de eliminar y así sucesivamente. Y está diseñado para que tengas que usar ambas manos para hacer control y eliminar. Pero luego no es accesible porque estas personas no tienen suficientes manos. Es por eso que más tarde bajaron y diseñaron esto nuevamente y colocaron control en y están en el mismo lado para que podamos usar una mano para hacer clic en ellos.

Lo siguiente se llama contraste. Vi aquí a mucha gente en clase. Y por eso es muy importante porque cada uno de nosotros aquí tiene un problema con el contraste de color. De lo contrario, no necesitaríamos el modo oscuro o el modo claro. No estarían gritando que es demasiado claro. Soy un vampiro. Algo así. Un hito y diseño de contenido. Cómo se verá tu sitio web cuando no haya CSS. En qué terminarás... La primera cosa en tu aplicación y lo que atraerá más al usuario cuando haya 10 aplicaciones.

4. Understanding Accessibility and Component Building

Short description:

La disposición de los elementos y el diseño del contenido son muy importantes también para los lectores de pantalla. Y por último, ¿dónde aterrizo cuando uso la tecla de tabulación? Cuando presiono la tecla de tabulación por primera vez, ingreso a tu aplicación. La capacidad de enfoque. Todo esto se convierte en las directrices de accesibilidad.

La disposición de los elementos y el diseño del contenido son muy importantes también para los lectores de pantalla. Y por último, ¿dónde aterrizo cuando uso la tecla de tabulación? Cuando presiono la tecla de tabulación por primera vez, ingreso a tu aplicación. La capacidad de enfoque. Todo esto se convierte en las directrices de accessibility.

Y no solo eso, tienes más. La disposición del contenido que usas hoy en día en el teléfono. Siempre tienes que hacer zoom para acercar y alejar. El 200%, 40% es el estándar para que sea legible en términos de accessibility. Localización de contenido comprensible. No todos son hablantes nativos de inglés. Y también asegúrate de que las personas entiendan correctamente tu sitio web. Manejo de formularios, tipografía de medios, enlaces externos, órdenes de tabulación, todo esto, mucho. Y más. Esa no es una lista completa. Todo esto se convierte en accessibility.

Y probablemente en este momento pienses que es muy, muy molesto y muy, muy difícil de hacer. Sí, todos en mi equipo dijeron lo mismo. Es muy difícil cumplir con ello. Pero si lo divides en un alcance más pequeño, será más fácil. Todos aquí trabajan con el sistema de design. Aquí tienes un ejemplo de design atómico. Que descompone el componente en subcomponentes y piezas más pequeñas del sistema completo. Y luego construyes tu aplicación sobre cada pieza.

Entonces, para accessibility, diría que si estás en el componente inferior, que es el componente atómico, como un botón. Lo que debes enfocar aquí no es el cumplimiento completo de accessibility. Solo necesitas enfocarte en el color, el uso del enfoque del marcador donde estás usando el botón o estás usando algo que no es un botón. Contenidos informativos, ¿tienes texto alternativo para un botón de icono y así sucesivamente? Tipografía, todo esto es desde el nivel más bajo. Y solo cuando comienzas a construir un componente más complejo sobre este componente, debes ser más consciente del flujo de navegación. Marcador de diseño, una tabla de formulario, cómo controlarlos, flujo de enfoque entre la conexión entre diferentes componentes juntos para proporcionar la experiencia completa y así sucesivamente.

5. Building Accessible Dialogues

Short description:

El equipo de OneArea desarrolló una página de patrones con patrones de accesibilidad comunes y código listo para usar. Me centraré en tres ejemplos comunes: diálogos, enfoque automático, navegación por teclado y reenfoque. La implementación es sencilla, utilizando atributos como aria-modal, tabindex, keydown y ref. Evita usar z-index y considera utilizar el elemento de diálogo nativo de HTML para una mejor accesibilidad.

La buena noticia es que el equipo de OneArea desarrolló una página muy buena llamada la página de patrones que te proporcionará todos los patrones comunes para la accesibilidad con código listo para usar y lo que necesitas implementar para que funcione. Puedes echarle un vistazo, todavía está en progreso, pero tienen muchas características interesantes.

En esta charla no tenemos suficiente tiempo para hablar de todas estas cosas así que me centraré en tres ejemplos más comunes. Un diálogo es un diálogo complejo donde puedes hacer muchas cosas como completar el formulario, enviar el formulario o simplemente un diálogo de alerta para decirte que estás haciendo algo mal y si estás seguro de que sabes que estás haciendo algo mal, haces clic en OK y listo. Para que el diálogo sea accesible, primero debes enfocarte automáticamente en el primer elemento enfocable En la navegación por teclado, al presionar Escape, debe cerrar el modal o haces clic en el fondo o haces clic en el botón, debe cerrar el modal primero. Y por último, cuando cierres el modal, es importante que se restaure el enfoque. Lo que sea que active el modal debe volver a enfocarse.

¿Cómo lo estamos haciendo? ¿Cuántas personas aquí están usando Vue? Vamos, vamos. De todos modos, este es en realidad el código de una de las bibliotecas de componentes, la de store-from-UI. Entonces, si UI react o Angular es similar, ya sabes, es JavaScript al final. Aquí, la implementación es bastante sencilla. Entonces, tienen aria-modal, que muestra solo un tab-index, key-down y ref, algo así. Y luego, para hacer todo el clic, haces clic-afuera, key-down y trap-focus. Recuerda esto, trap-focus. Todo en el diálogo se queda en el diálogo. No tienes enfoque fuera del diálogo en absoluto. Así que cuando implementes el diálogo, recuerda eso. Lo mismo ocurre con TuneTick.

¿Y funciona? Veamos. Aquí tienes un ejemplo. Vas a pagar, haces clic en él, ves que el diálogo está oculto. Porque el diálogo se implementó justo debajo del botón y, según el orden de aparición en el sitio web, no funciona. Para solucionarlo, debes cambiarlo a un z-index para asegurarte de que aparezca al frente. Pero ya sabes, usar un z-index no es la forma adecuada de manejar las cosas porque terminas con un z-index 9999 al final. Entonces, otra forma de hacerlo, y aquí, si haces clic en el botón de cerrar, no tienes el reenfoque. El usuario no tiene idea de dónde está. Y esta es una implementación incorrecta porque no es lo suficientemente accesible. En su lugar, lo que puedes hacer es intentar usar el elemento de diálogo. Este es el elemento de diálogo nativo de HTML, que te permite obtener la funcionalidad del diálogo sin hacer nada. Y luego puedes usar el formulario con el método de diálogo y no tienes que hacer clic en la cosa de cerrar.

6. Enhancing User Experience

Short description:

Lo hace automáticamente. Solo agrega un reloj y funcionará. Asegúrate de que cuando un usuario regrese al flujo, regrese al mismo lugar. Los toontips se pueden mostrar utilizando pseudocódigo CSS, enfoque ranurado o el evento de enfoque. Evita poner enlaces dentro de los toontips. Al tratar con la carga, mantén la referencia del botón para mantener el enfoque y activar el reenfoque cuando termine la carga.

Lo hace automáticamente. Y lo que estás haciendo aquí, solo agrega un reloj. Eso es todo. Ahora funcionará. Veamos. Tengo un minuto. Debería estar bien. ¿Puedes ver eso? Se enfoca automáticamente en la primera cosa, y luego, cuando lo cierras, puedes continuar el flujo hacia el siguiente elemento navegable. Y esta es la forma en que debes hacerlo. Cada vez que un usuario se vea interrumpido por algo, cuando el usuario regrese al flujo, asegúrate de que regrese al mismo tiempo y al mismo lugar. De acuerdo. El siguiente ejemplo son los toontips. Todos conocemos los toontips, ¿verdad? El toontip es muy simple, solo un texto. Cuando pasas el cursor sobre él, se muestra. Pero esto es con enfoque, pero no hay toontip. ¿Por qué? Porque no hay evento de pasar el cursor sobre nada. No hay evento de pasar el cursor sobre. No puedes agregar el evento para mostrar un toontip al pasar el cursor sobre él. En una pantalla táctil, no hay pasar el cursor sobre. En un teclado, no hay pasar el cursor sobre. Para hacer eso, puedes usar pseudocódigo CSS, enfoque ranurado, o simplemente usar el evento de enfoque para escuchar y mostrar el toontip según corresponda. Y recuerda, en el toontip, solo se muestra información, y no debes poner ningún enlace dentro. No. Ningún enlace, porque eso es muy inapropiado para un toontip. Y el último ejemplo trata sobre la carga. Digamos que tienes un vestíbulo, carga. De acuerdo, ¿dónde está mi enfoque? ¿Por qué volver arriba? Entonces, ahora, aquí estoy usando visual, así que para solucionarlo, tendré que decirle a `if`, lo cual no sé por qué, en Vue, funciona de esta manera. En React, si usas `if`, nunca recuperarás el enfoque, porque el elemento ya está desmontado del dominio, el navegador no sabe que está funcionando allí. Aquí, funciona de tal manera que cuando terminas, cuando haces el siguiente paso, volverá a enfocarse en el anterior, lo cual es bueno, de acuerdo, más o menos.

7. Soluciones, Personalización, Escalabilidad, Documentación

Short description:

Algunas soluciones para solucionar esto: mantener la referencia del botón, no desmontar el botón y simplemente ocultarlo, activar el reenfoque cuando termine la carga. La personalización es importante para los diseñadores, considera el uso de variables CSS o consultas de contenedor. La escalabilidad se logra mediante el diseño de un buen sistema de diseño con lógica y componentes separados. La documentación es crucial, define la única fuente de verdad y mantén una buena estructura de código.

De todos modos, algunas de las soluciones para solucionar esto es mantener la referencia del botón, no desmontar el botón y simplemente ocultarlo, así siempre lo tendrás de vuelta, y activar el reenfoque cuando termine la carga. Y algunas de las guías aquí son definitivamente vistas invisibles. No uses dip, número uno. No uses dip cuando no tengas que usar dip. Y prueba todo. Prueba todas las combinaciones, ¿de acuerdo?

Lo siguiente, personalización, dado que solo me queda un minuto, tengo que avanzar rápido. Entonces, la personalización, tenemos, bueno, como diseñador, sabes, tenemos un millón de cosas en las que pensar, e iconos, tamaño de fuente, tema de color, todo está aquí. Personalización de utilidad, nadie está contento con lo que haces. Incluso tú. Siempre quieren cambiarlo. Lo segundo es cómo vas a cambiar el contenido del botón. Puedes hacerlo usando variables CSS o consultas de contenedor para estilizar el contenedor específicamente. Y esto mantendrá tu componente lo suficientemente aislado y sin romper nada de las aplicaciones. Y para cambiarlo, puedes usar muchas props como aquí. Tienes un icono, muchas props de icono aquí. Todo lo que puedes hacer es cubrir un único caso de uso, para mejorarlo y dejar el 20% restante para el usuario en lugar de proporcionar muchas props. Pero nuevamente, presta atención. Si haces esto, puede terminar perjudicándote porque un usuario sobrescribe tu design predeterminado. Tu sistema de design se arruina. Y no hay accessibility.

Escalabilidad. Aquí, si diseñas el sistema de design lo suficientemente bien, tendrás lógica y componentes por separado y luego puedes combinarlos para convertirlos en un design final, una aplicación funcional con menos trabajo por hacer. Y por último, ¿cómo lo vas a usar? Esto habla sobre la documentación. La documentación se trata de escribir, hay muchas cosas que manejar, pero Copilot está aquí para ayudar, pero no confíes al 100% en Copilot. Primero, debes definir cuál es la única fuente de verdad. Storyblock es una buena opción. Segundo, siempre debes tener una estructura de código muy buena porque la accessibility siempre es para el desarrollador. La siguiente persona que llegue a tu equipo debe entender cómo puede navegar por tu código. E instrucciones, cortas y concisas.

QnA

Importancia de la Accesibilidad y Planificación de Componentes

Short description:

No nos des 3,000 ensayos de documentación porque nadie los leerá. Un ejemplo siempre es bueno. Un consejo de accesibilidad en el ejemplo siempre es algo que hacer. Y por último, para tu equipo, puedes diseñar algunas pautas de accesibilidad con consejos, trucos y errores comunes. Cómo solucionarlo les ayuda a ayudarte a hacer tu trabajo y construir un componente. Todo esto se reduce a una cosa, planificar tu componente con anticipación.

No nos des 3,000 ensayos de documentación porque nadie los leerá. Un ejemplo siempre es bueno. Un consejo de accesibilidad en el ejemplo siempre es algo que hacer. Ayuda a las personas a navegar, copiar y pegar, a saber cómo funciona el componente. Y por último, para tu equipo, puedes diseñar algunas pautas de accesibilidad con consejos, trucos y errores comunes. Cómo solucionarlo les ayuda a ayudarte a hacer tu trabajo y construir un componente. Y por último, usar un copiloto para automatizar lo que se pueda automatizar.

De acuerdo, conclusión clave. Todo esto se reduce a una cosa, planificar tu componente con anticipación. Y aquí tienes algunos recursos, y eso es todo. Gracias. APLAUSOS

Tenemos muchas preguntas, y como es un tema muy querido para mí, las priorizo según mi interés. Dices que no uses div si no es necesario. ¿Puedes darme más detalles sobre por qué no deberías usar div si hay algo mejor para usar? De acuerdo, ¿todos aquí saben qué significa div? Es un elemento de división en HTML. Lo cual significa que es más como una persona anónima y aleatoria en la calle. Entonces, si estás usando a esa persona anónima y aleatoria en la calle para mostrar alguna aplicación, el lector de pantalla no podrá detectar para qué se va a utilizar. Y esa es la segunda cosa, tenemos elementos dedicados para tipos especiales, como una caja de búsqueda. Ese aún no está soportado, pero tienes una sección, tienes un coche, tienes un input, un botón. Es para botones, así que úsalo. Sí, si alguien está interesado, más tarde tuitearé. Hace un par de años hice un videocast con una mujer llamada Leonie Watson, que es una desarrolladora web ciega. Solía ser diseñadora y quedó ciega en sus veintes. Y le pedí que me mostrara cómo navega por un sitio web con un lector de pantalla. Y es un video de seis minutos que muestra cómo usar el elemento nav en lugar de div class equals nav significa que un usuario de lector de pantalla puede presionar un botón y el enfoque irá inmediatamente a la navegación o saltará directamente a la parte principal del contenido. Mientras que si solo usas un div, esos atajos no están disponibles para alguien que usa un lector de pantalla. Y si no eres un usuario de lector de pantalla, entonces esas cosas te son completamente indiferentes y no te importan. Entonces, si escribir nav tiene la misma cantidad de bytes que div, pero al escribir nav estás brindando a las personas ciegas una experiencia mucho mejor, lo siento, esa era una pregunta para ti y estoy hablando, así que. Lo siento. Pero no me invitan a hablar en estas cosas. ¿Pueden tener las diapositivas, Maya? ¿Vas a tuitear un enlace para las diapositivas? Bueno, si me imprimes una copia, te daré mis diapositivas.

Creación de una Biblioteca de Componentes de IU y Uso de ARIA

Short description:

¿Por qué crear una biblioteca de componentes de IU desde cero? Depende del caso de uso. Para un sistema o aplicación de una sola vez, no es necesario construir desde cero. En un entorno corporativo, la construcción interna se vuelve necesaria. El uso de una biblioteca externa puede ser problemático. No uses ARIA si no es necesario. Úsalo cuando no haya alternativa. ARIA agrega complejidad al código. Usa botones cuando algo sea clickable. Evita usar div role equals button. Se discutirá la mejor herramienta automatizada para la accesibilidad mínima.

De acuerdo. Soborno y corrupción para la mitad de Microsoft aquí. Si le compras un café a Maya, puedes tener una copia de las diapositivas. No, estoy bromeando. Tengo que tuitear mis diapositivas después. Solo necesito convertirlas en una presentación de PowerPoint adecuada y accesible, así que.

Aquí hay una pregunta interesante. ¿Por qué crear una biblioteca de componentes de IU desde cero cuando podrías hacer algo como tomar algo como Radix UI, que tiene componentes sin estilo a los que luego puedes aplicar tus estilos? Bueno, ¿sabes qué? No es una cosa u otra. No es blanco o negro. Básicamente, realmente depende de tu caso de uso, si solo necesitas construir un sistema o una aplicación una vez para las personas. No necesitas escribir todo el sistema de componentes desde cero. Pero si estás trabajando en una empresa como una empresa corporativa, por ejemplo, como Microsoft, entonces tenemos que construirlo nosotros mismos o cosas que sean reutilizables por diferentes equipos internamente. Y a medida que la empresa crece, el uso de una biblioteca externa será un poco más problemático en términos de corrección de errores, mantenibilidad, y testing, y así sucesivamente. Porque siempre tienes que depender de alguien para proporcionar tu servicio. Incluso con Microsoft, todavía tenemos problemas al trabajar con las bibliotecas de componentes internas.

Dijiste que no uses ARIA, ¿por qué ARIA es la especificación de aplicaciones web ricas accesibles que puede estar por encima de HTML? ¿Por qué dijiste que no uses ARIA cuando ARIA está destinado a la accesibilidad? Bueno, la regla es no usar ARIA cuando no tienes que usar ARIA. Esa es la única regla. Básicamente, debes usar ARIA cuando no tienes alternativa. Por ejemplo, conoces las filas, botón, ¿verdad, fila como botón? Pero si tienes un elemento de botón, no necesitas fila como botón porque eso es simplemente sobreingeniería. ARIA solo está destinado a proporcionarte cosas de apoyo adicionales para que los lectores de pantalla puedan captar correctamente tu elemento, tu componente. Entonces, si tienes una forma de hacerlo sin él, hazlo. De lo contrario, solo agrega mucha complejidad a tu código. Sí, estoy de acuerdo. Básicamente, si tienes algo que se supone que debe ser clickable y se supone que debe hacer algo, si parece un botón, si huele como un botón, simplemente usa un botón. No uses div role equals button, tab index equals minus 1, escucha la barra espaciadora. Todo eso, ¿puedo decir mierda? Sí, toda esa mierda. Solo usa un botón. Los botones son buenos.

La pregunta que todos reciben cuando hablan de accesibilidad, ¿cuál es la mejor herramienta automatizada para verificar al menos la accesibilidad mínima?

Pruebas de Accesibilidad y Convencer a las Organizaciones

Short description:

Simplemente no tengo suficiente tiempo en mi charla. Si estás utilizando playwrights o pruebas, hay una biblioteca de código abierto desarrollada por el equipo de XCore. Puedes integrarla en tu sistema de automatización para pruebas de accesibilidad de extremo a extremo. Después de la charla, puedo mostrarte la herramienta. Si quieres comenzar las pruebas, instala Accessibility Insights for the web, una extensión que escanea páginas web en busca de cumplimiento y orden de pestañas. ¿Cómo convences a las organizaciones de que se preocupen por la accesibilidad? En Microsoft, el cumplimiento se basa en políticas, pero en otras empresas, proporciona un buen ejemplo y demuestra la importancia de la accesibilidad. El comercio electrónico es un buen ejemplo de cumplimiento de accesibilidad, ya que excluir a posibles clientes no es rentable. Muéstrales el impacto realizando demostraciones y enfatizando la experiencia del usuario. Si a tus jefes no les importa la accesibilidad, considera trabajar para una empresa que priorice los derechos humanos y la experiencia del usuario.

Oh, quiero hablar de eso. Simplemente no tengo suficiente tiempo en mi charla. Bien, para eso, si estás utilizando playwrights o probablemente también pruebas o cualquier prueba de automatización, hay una biblioteca desarrollada por el equipo de XCore que es de código abierto. Puedes integrarla en tu sistema de automatización. Y luego la ejecutarás en la prueba de extremo a extremo en tu conjunto, y te ayudará a cubrir, creo que casi el 80% de tus pruebas de accesibilidad.

Bueno, puedes hablar conmigo después de la charla y te mostraré la herramienta. Además, si realmente quieres hacer pruebas y no sabes por dónde empezar, puedes instalar Accessibility Insights for the web. Ese es el proyecto de Microsoft. Es una extensión que te permite ejecutar el escaneo de toda la página web y te muestra exactamente qué es compatible y qué no es compatible, y el orden de pestañas de tu sitio web para que sepas si el flujo de la pestaña es correcto o no.

Esta es la última pregunta, y es una pregunta para Maya, pero será una pregunta para Maya y Bruce porque tengo opiniones. ¿Cómo persuades a las personas de niveles superiores en la organización para que se preocupen por la accesibilidad y te permitan el tiempo y el costo de implementar la accesibilidad? Una de las cosas buenas de trabajar en Microsoft es que no tienes que hacer eso porque es una política de cumplimiento. Solo necesitas decir que no lanzarás este producto porque no cumple con la política de la empresa, y eso detiene a todos. Pero, bueno, lo siento, fuera de Microsoft, en otras empresas, diría que necesitas darles una muy buena experiencia, un muy buen ejemplo de por qué es importante que el usuario tenga accesibilidad para que la aplicación sea accesible.

Por ejemplo, puedes hacer una pequeña demostración con todo en negro y pedirles que naveguen por la aplicación y vean si funciona, y luego también puedes mostrarles que los usuarios de accesibilidad son muy importantes para la industria. Por ejemplo, el comercio electrónico es un muy buen ejemplo de cumplimiento de accesibilidad porque todos usan sitios web para comprar cosas, aplicaciones para comprar cosas, no quieres excluir a nadie que pueda traerte ganancias, sin importar cuán pequeñas sean, así que solo necesitas mostrarles. Quiero decir, solía, lo que hice fue poner una página en blanco completa y les pedí que navegaran por esa página en negro, y les pedí que me contaran su experiencia, y funcionó.

Sí, lo que dijo Maya. Básicamente, si necesitas persuadir a tus jefes para que se preocupen por la accesibilidad, lo mejor que puedes hacer es irte y trabajar para una empresa que se preocupe por los derechos humanos, que se preocupe por no discriminar, que se preocupe por la experiencia del usuario. Y por eso no estoy empleado en este momento. Amigos de JS Nation, por favor, aplaudan a Maya Chavin. 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

React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.