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

[♪ 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.

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.

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.

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.

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.

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.

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.

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.

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?

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.