Estudio de caso: Construcción de componentes React reutilizables accesibles en GitHub

Gracias por la introducción. Soy Sid. Mi nombre completo es Siddharth, pero no me gusta que la gente destroce mi nombre. Solo me llaman Sid. Está bien. Es más fácil. Trabajo en el equipo de sistemas de diseño en GitHub y paso mucho tiempo manteniendo la biblioteca de componentes de React que forma parte del sistema de diseño. Quiero hablar sobre la construcción de componentes accesibles en React con un enfoque en la accesibilidad. Muchas de las cosas de las que hablaré hoy son en realidad independientes del framework. Pero una advertencia justa, no soy un experto en accesibilidad. Solo soy un chico de React un poco tonto. Pero pasé mucho tiempo el año pasado trabajando con expertos en accesibilidad y he absorbido muchas cosas y tal vez, como desarrollador front-end, si eres como yo, este tipo de introducción sea más útil que una centrada en la accesibilidad.

Muy bien. Crucemos los dedos. Vamos. Entonces, cosas... ¿Cuáles son las cosas que necesitamos para crear experiencias accesibles? Si escuchas a los influencers en Twitter, deberías usar un botón y no un div. Y generalmente viene acompañado de un ejemplo de código con un bonito fondo morado. Y así tienes que utilizar el elemento HTML correcto. Y si les haces caso, eso es todo. Podríamos ir a almorzar ahora mismo. Pero, por supuesto, eso es... Esta forma de plantearlo es muy reduccionista porque hay mucho más que eso. Esto no es falso. Aún así, debes intentar utilizar el elemento correcto. Y si es una acción interactiva, entonces debes usar un botón. Pero hay mucho más que eso, por ejemplo.

Así que hay esta interfaz, hay este widget emergente en GitHub donde se muestra mucha información de forma densa. Así que tienes espacios de código, copiloto y la pestaña local. Y cuando tienes que mostrar muchos controles en un espacio muy reducido, las pestañas son un patrón realmente bueno y eso es lo que usamos aquí. Y realmente... Creo que funciona muy bien si estás utilizando la UI de esta manera. Y la implementación también es un poco peculiar. Tenemos botones. Sí, usamos botones. Y estoy estableciendo un estado aquí de cuál es la pestaña seleccionada. ¿Puedes ver mi cursor? Genial. Y luego todos estamos de acuerdo en que cuando es una elevación como esta, eso es una pestaña. Y cuando cambias la pestaña, la elevación se mueve. No sé por qué, pero todos lo sabemos, y este es un patrón común de diseño. Así que eso es lo que hago. Doy un nombre de clase. Y eso es lo que hace que el nombre de clase sea una elevación. Pero ¿qué pasa si alguien que no puede ver la pantalla y en su lugar está utilizando un lector de pantalla, qué escucha? ¿Qué percibe? Vamos a probarlo. Además, esto va a ser una prueba del audio. Así que lo descubriremos. Si está demasiado alto, se arreglará. No te preocupes.

De acuerdo. Vamos. VoiceOver en la aplicación. Aplicación React. Perfecto. Cada vez que inicias VoiceOver en Mac, comienza anunciando que VoiceOver ha sido habilitado y está en la aplicación React. Siguiente. Code. El botón emergente del menú tiene el enfoque del teclado. Así que anunciará qué elemento tiene el enfoque del teclado en este momento. Así que si no puedes ver nada y solo estás escuchando esto, sabes que el enfoque está en un botón. Tiene una etiqueta code. Y tiene un menú emergente. Así que porque sabes que tiene un menú emergente, puedes presionar enter y puedes abrir el menú emergente.

Veamos qué va a hacer. Botón local. Espacios de cata. Botón. Copiloto. Botón. Copiar URL al portapapeles. Botón. HTTPS. GitHub primer React Git. Seleccionar contenido abierto con GitHub desktop. Botón. Descargar zip. Botón. Botón local. Huh. Así que vuelve al principio. Ahora, si estás escuchando esto, creo que todo lo que escuchas es botón, botón, botón, botón, y un botón de entrada y un botón. Así que es tan... Estamos tan acostumbrados a nuestras colinas de diseño que visualmente es un patrón tan claro, pero si no eres un usuario con visión, si eres un lector de pantalla, nada de esto tiene sentido. La jerarquía es simplemente un montón de botones. Averígualo. Y tal vez... No sé qué hicimos mal. Tal vez no usamos el elemento correcto, ¿verdad? Eso es lo que quieren los influencers. Así que tal vez deberíamos haber usado el elemento de pestañas en lugar del elemento de botón. Pero, por supuesto, no existe el elemento de pestañas. Eso no es real. Estamos atrapados con divs y botones en la web. Y aquí es donde entra en juego la especificación de aplicaciones de internet ricas accesibles, o ARIA como se le conoce famosamente. ARIA proporciona un conjunto de roles que transmiten la semántica de accesibilidad de las estructuras en una página. Y específicamente, ya tienen muchos roles definidos. Y uno de ellos es lista de pestañas. Que es exactamente lo que necesitamos. Así que volviendo a esto, realmente no puedo usar el elemento correcto aquí. Pero lo que puedo hacer es usar el rol correcto. Entonces, si le doy a mi div el rol de lista de pestañas y a cada uno de mis botones el rol de pestaña, ahora la semántica... Estoy agregando semántica aquí para transmitir al navegador que esto es una pestaña. Y, por supuesto, estoy anulando el botón y dándole el rol de pestaña. Entonces, ¿importa si es un botón? Realmente no importa. Lo único de lo que debo tener cuidado es que si quiero obtener el enfoque, necesita tener un tabindex. Y finalmente, mis paneles al final, aquellos que tienen contenido, deben tener el rol de panel de pestañas. Estas son las semánticas. Ahora probemos de nuevo con el lector de pantalla. Botón emergente del menú. Local. Seleccionado. Pestaña. 1 de 3. Espacios de cata.

Seleccionado. Pestaña. 2 de 3. Copiloto. Seleccionado. Pestaña. 3 de 3. Hay muchas cosas que me gustan aquí. Está anunciando en qué se encuentra el enfoque. Así que dijo local. Y luego dijo seleccionado. Así que sabe que esta pestaña está seleccionada. Dijo pestaña. Así que ahora sabes que estás en una pestaña. Y dice 1 de 3, 2 de 3. Incluso si estás en la primera, ya sabes que hay 3 pestañas.

Y la cuarta cosa que realmente me encanta es cómo pronuncia codeespacios, como espacios de coda. Creo que deberíamos cambiar de marca. Espacios de coda suena mucho mejor. Pero hay algo peculiar que también está sucediendo aquí, donde piensa que todas las pestañas están seleccionadas. Así que aunque sé desde mi perspectiva que la pestaña local está seleccionada, dice copiloto seleccionado pestaña 3 de 3. Y eso es porque, una vez más, los lectores de pantalla realmente no tienen forma de entender qué está seleccionado visualmente o a qué nos referimos cuando decimos que una perspectiva significa una pestaña seleccionada. Así que tenemos que decírselo.

Y aquí es donde volvemos a la especificación. Y en lugar de roles, miramos los estados y propiedades. Los estados y propiedades proporcionan información específica sobre un elemento, como sus características actuales. Por ejemplo, la selección. O su relación con otros elementos en la página. Entonces, aquí lo que debemos hacer es agregar aria-selected. Y esto te permite dar aria-selected a varios roles. Y la especificación tiene un mapa de relación muy bueno de qué roles esperan qué propiedades. En este caso, aria-selected. Y estoy utilizando la misma lógica de React donde la misma que estoy usando para decorar mi clase. Estoy usando la misma para decir cuál de estos está seleccionado. Bien. Probémoslo de nuevo. Local. Seleccionado. Pestaña. Uno de tres. Espacios de coda. Pestaña. Dos de tres. Copiloto. Pestaña. Tres de tres. Perfecto. Ahora solo piensa que una de ellas está seleccionada. Y solo si presiono enter en cualquiera de estas pestañas, esa pestaña se seleccionará y el panel de pestaña correspondiente se mostrará. Perfecto.

De acuerdo. Veamos. ¿Qué sigue? Creo que quiero copiar la URL. En este momento, puedes ver que mi enfoque está en 'copilot'. Si quiero ir a 'copy', eso es parte de 'local'. Así que volvamos a 'local'. Espacios de coda. Pestaña. Dos de tres. Local. Seleccionado. Pestaña. Uno de tres. Genial. Y ahora que estoy aquí, quiero ir al panel de pestañas y seleccionar el primer botón. ¿Cómo lo haría? Supongo que solo tendría que presionar la tecla de pestaña nuevamente. Espacios de coda. Pestaña. Dos de tres. Copilot. Seleccionar la URL al portapapeles. Botón.

Hay algo en eso que se siente muy extraño. Estabas en una pestaña y luego tienes que pasar por todas las demás pestañas para ingresar al panel de pestañas. Esto parece que algo está mal. Parece que usamos los elementos correctos, agregamos los roles correctos, pero aún algo parece estar mal. Y eso se debe a que si miras esto, hay dos roles distintos aquí. Está la lista de pestañas y está el panel de pestañas. La navegación entre ellos no tiene que ser solo a través de las teclas de pestaña. De hecho, la especificación de ARIA tiene una sección muy breve al respecto, donde dice que para enriquecer las aplicaciones de Internet, el usuario usa la tecla de pestaña para navegar por widgets complejos y significativos, como un menú o una hoja de cálculo, o una lista de pestañas, y usa las teclas de flecha para navegar dentro del widget. Entonces, si estás en un widget significativamente complejo como una lista de pestañas, no tienes que usar la tecla de pestaña en el widget, puedes usar las teclas de flecha dentro de él y cuando presionas la tecla de pestaña, sales de la lista de pestañas y entras al siguiente widget.

Entonces, ¿cómo lo implementamos? No hay un rol ARIA para esto, no hay una propiedad ARIA, no hay un elemento correcto. Tienes que hacerlo tú mismo. Para sacarlo del orden de pestañas, voy a restablecer el índice de pestaña a menos uno, eso lo saca del enfoque del teclado, pero necesito alguna forma de ingresar a este widget. Así que voy a mantener uno de ellos con un índice de pestaña cero para que se mantenga en el orden de pestañas y todo lo demás sea menos uno. Entonces, cuando ingreses a la lista de pestañas, ingresarás a través de la pestaña seleccionada, podrás usar las teclas de flecha y luego podrás salir. ¿Cómo hacemos que las teclas de flecha funcionen? Bueno, es bueno cuando agregas un escuchador de eventos en 'keydown', y luego, si la tecla del evento es la flecha derecha, enfoca en la siguiente pestaña. Si es la izquierda, enfoca en la pestaña anterior. Dentro de estas funciones, 'focusNextTab', literalmente parece que miras el elemento DOM, encuentras la siguiente pestaña y luego llamas a '.focus' en ella. Es una consulta JS muy antigua, un tipo de código iterativo. Solo una demostración rápida. Así es como funciona. Abres la pestaña, puedes usar las teclas de flecha para navegar entre ellas y luego puedes presionar la tecla de pestaña para ir a la siguiente cosa. Ahora puedo presionar shift + tab para subir, y ahora estoy de vuelta en la lista de pestañas y puedo usar las teclas de flecha nuevamente. Este es un patrón lo suficientemente común como para que lo hayamos abstraído en un hook, un hook de React, y lo llamamos 'useFocusZone', y puedes indicar qué teclas necesitas vincular. En este caso, es algo horizontal, así que decimos 'focusKeys.arrowHorizontal'. Está bien tipado. Es un enum. Y luego devuelve una referencia que puedes agregar a un contenedor. Esta parte, quiero decir, 'Primary Act' es de código abierto. Si quieres robar nuestro código, por favor hazlo.

Si quieres informar errores, no lo hagas. Por favor, simplemente arréglalos. Bien, veamos. Lo último aquí es que en lugar de hacer clic, ¿cómo sería si cambiamos la pestaña al enfocar? Observa que a medida que me desplazo por las pestañas con las teclas de flecha, el panel de pestañas también cambia. Y eso es casi como una forma más agradable, y de hecho, la especificación ARIA ni siquiera menciona eso. No menciona cuándo cambiar la pestaña. Eso queda en ti, si debería ser enter, si debería cambiar instantáneamente. Todo lo que dice es que cuando cambie la pestaña, asegúrate de actualizar ARIA seleccionado para que el lector de voz pueda anunciar cuando se selecciona una pestaña.

Para esto, necesitamos consultar la guía de prácticas de autoría de ARIA, o APG. El APG tiene muchos patrones y en realidad habla sobre uno de ellos para las pestañas, donde tiene interacciones con el teclado y es casi como una especificación más agradable de leer. Es como una lista de verificación de todas las cosas a seguir. Pero ten en cuenta que si bien la especificación ARIA es una recomendación para los navegadores, para el accesibilidad software, para autores como tú y yo, llaman al APG un recurso informativo, que es una forma más agradable de decir que es solo un blog con algunos ejemplos de código para que nadie tenga que seguirlo. Los navegadores no tienen que seguir el APG, mientras que sí tienen que seguir la especificación ARIA. Algunas de estas prácticas, como ocurre en nuestra industria, algunas de estas prácticas comienzan por personas que intentan mejorar la especificación y luego se convierten en algo común. Todos las hacen. Las pestañas, y eventualmente vuelven a la especificación. El APG también tiene algunos de esos patrones. Cosas que hemos aprendido hasta ahora. Utiliza el elemento correcto. Eso sigue siendo cierto. Pero también necesitas utilizar reglas que transmitan semántica y estructura. Necesitas utilizar propiedades y estados ARIA que agreguen relaciones y estado actual. Necesitas implementar la navegación con el teclado tú mismo para que las interfaces sean accesibles. Y, por supuesto, hay más.

Así que aquí tengo otro ejemplo donde intento cambiar mi configuración de notificaciones en GitHub. Esto está en la página de configuración. Y hay un formulario pequeño donde puedo seleccionar el correo electrónico, y luego me da una opción adicional si solo quiero recibir notificaciones para flujos de trabajo fallidos, lo cual tiene sentido. Y luego lo selecciono. Es realmente agradable porque muestra en el botón lo que has seleccionado. Y el código para esto es bastante bueno. Estoy usando un botón. Estoy usando un formulario. Tengo un fieldset. Tengo una leyenda. Tengo un input tipo checkbox. Hay un ID. Hay una etiqueta. Todo en esto está hecho de manera perfectamente semántica. Pero veamos qué anuncia el lector de pantalla. Yo. Nunca. Menú emergente colapsado. Botón. De acuerdo. Nuevamente, es un menú emergente. Dice `notificarme nunca`. Así que sabemos cuál es la configuración actual. Y al igual que en el ejemplo anterior, si es un menú emergente, puedo presionar enter y abrir el menú emergente. En GitHub. Marcar.

Casilla de verificación. Seleccionar canales de notificación. Grupo. Genial. Eso es útil. Dice que el enfoque actual está en la etiqueta llamada en GitHub. Es una casilla de verificación sin marcar. Entonces, la casilla de verificación es un checkbox. Y me dice que actualmente no está marcada. Y también me dice que esto es parte de un grupo llamado seleccionar canales de notificación. Entonces, si no estoy mirando esto en absoluto, aún sé dónde está mi enfoque en este momento. Y estoy en parte de un grupo. Entonces, hay más casillas de verificación para seleccionar canales de notificación. Entonces puedo tocar para ver cuáles son mis otras opciones. Sé que hay en GitHub. Correo electrónico. Sin marcar. Casilla de verificación. De acuerdo. Aplicación. Sin marcar. Casilla de verificación. De acuerdo. Cancelar. Botón. Guardar. Botón. Genial. Después de las tres opciones, voy a guardar y cancelar. Entonces sé que hay tres opciones. Me gusta el correo electrónico. Así que voy a seleccionar correo electrónico. Voy a retroceder. Cancelar aplicación. Correo electrónico. Sin marcar. Casilla de verificación. Cancelar aplicación. Correo electrónico. Casilla de verificación. De acuerdo. Y ahora que he seleccionado mi opción, es un formulario. Puedo presionar enter y guardar, que es lo que voy a hacer. El cambio se ha guardado. Notifícame. Correo electrónico. Menú emergente colapsado. Botón. Perfecto. Hice muchas cosas bien aquí y guardé un formulario accesible.

Pero algunos de ustedes, los veo sonriendo muy tímidamente. Como si los viera. Los atrapé. Así que hay algo que estamos haciendo aquí.

Una de las casillas de verificación solo aparece cuando se selecciona otro canal, porque es una casilla de verificación condicional. No puedes tenerla a menos que selecciones otra cosa. Y esto es simplemente, como, bastante design. Si es falso, no lo muestres. Pero cuando es verdadero, ahí es cuando lo muestras. Y creo que es muy común en React hacer este tipo de representación condicional. Pero si eres un usuario de lector de pantalla, en realidad no verías esta bonita animation de, como, Paso tanto tiempo en CSS animando esto sin movimiento de cuadro. Pero no importa, porque no se anunciaría. La gente ni siquiera sabría que existe. Entonces, lo primero que tenemos que hacer es no ocultar cosas a los usuarios. Eso parece lógico. Así que vamos a mostrarlo siempre.

Pero realmente no podemos permitir que las personas seleccionen esto. Hay una condición sobre cómo... Cuando puedes seleccionar esto. Así que voy a agregar disabled. A menos que se seleccione algo, estará desactivado. Sin embargo, hay un problema con disabled. Entonces, si navego por mi interfaz con la tecla Tab, disabled en realidad lo saca del orden de tabulación. Así que ahora no solo está oculto, sino que está, como, oculto para siempre. Ni siquiera puedes acceder a él. Entonces, disabled es malo. Fue una novedad para mí. No pensé que disabled. La forma correcta de hacer esto es algo llamado Aria disabled. Y Aria disabled es interesante, porque aún obtienes el enfoque del teclado. Aún puedes darle estilo tú mismo. Así que aquí estoy agregando mis propios estilos desactivados, cuando es Aria disabled. Y ahora... Puedo acceder a él.

Solo notificar para flujos de trabajo fallidos. Atenuado sin marcar. Casilla de verificación. Entonces, no solo está en el orden de tabulación, también anuncia atenuado sin marcar casilla de verificación. Y atenuado es la forma en que VoiceOver dice que está desactivado. No sé por qué no dice desactivado. Dice atenuado. Pero está bien. Los usuarios de VoiceOver saben que atenuado significa esto. Así que eso es algo bueno. Y luego, la sorprendente cosa de la que tienes que ocuparte tú mismo es también actualizar tu on change. Porque Aria disabled no es lo mismo que disabled. Aún puedes registrar eventos en él. Así que tienes que capturar esos eventos y agregar tus comprobaciones a eso. Muy bien. Lo último que voy a hacer es agregar una descripción de por qué esto está desactivado.

Y puedo agregar este texto suplementario adicional adjuntándolo con Aria described by. Entonces, en esta entrada, tengo una etiqueta que está conectada por IDN4. Y tengo una descripción que solo se muestra a veces. Así es como se ve. Y... Solo notificar para flujos de trabajo fallidos. Requiere que se seleccione al menos un canal. Atenuado sin marcar. Casilla de verificación. Entonces también te dice por qué está desactivado. Y estoy usando Aria described by en lugar de ponerlo en la etiqueta. Porque, como puedes ver, este es mucho texto. Y puede volverse largo. Entonces, algunos usuarios de lectores de pantalla prefieren no tener descripciones. Y esa es la configuración que tienes. Solo puedes mostrar etiquetas o puedes mostrar etiquetas y descripciones. Como autores de sitios web, no tenemos ese control. El usuario del lector de pantalla tiene ese control. Lo cual creo que es bastante bueno. Muy bien. Entonces, después de hacer todo esto, hagamos una demostración rápida de cómo es de principio a fin. Defíname. Nunca. Menú emergente colapsado. Botón. En GitHub. Sin marcar. Casilla de verificación. Seleccionar canales de notificación. Tengo una opción. Sé que está en GitHub. Correo electrónico. Sin marcar. Casilla de verificación. Aplicación. Sin marcar. Casilla de verificación. Solo notificar para flujos de trabajo fallidos. Requiere que se seleccione al menos un canal. Atenuado sin marcar. Casilla de verificación. Cancelar. Botón. Genial. Entonces sé que hay cuatro. Y el cuarto tiene una condición. Dice que requiere al menos un canal. Así que voy a volver hacia arriba, seleccionar al menos un canal, que es el correo electrónico. Y luego también voy a seleccionar flujos de trabajo fallidos.

Solo conozco la aplicación. Correo electrónico. Sin marcar. Casilla de verificación. Marcar. Correo electrónico. Casilla de verificación. Aplicación. Solo notificar para flujos de trabajo fallidos. Sin marcar. Casilla de verificación. Marcar. Solo notificar para flujos de trabajo fallidos. Casilla de verificación. El cambio se guarda. Notifícame. Correo electrónico. Solo flujos de trabajo fallidos. Perfecto. Ahora tengo todo anunciado. Es muy claro. También anuncia cuando está marcado. La descripción puede ser condicional. Por lo tanto, desaparece cuando ya no es necesario. Y personalmente, creo que esto es en realidad un mejor diseño para los usuarios videntes también. Es más claro. En realidad te dice por qué algo está desactivado. Y aún puedes tener esa pequeña animación cuando no necesitas el error. Así que solo yo, pero creo que en realidad hemos mejorado la interfaz de usuario al hacer esto.

Genial. Volviendo a la lista. Las cuatro cosas son ciertas. Pero también tenemos que diseñar teniendo en cuenta la accesibilidad. No hay roles, no hay elementos. Mientras diseñamos, tenemos que pensar en esto.

Y finalmente, ten cuidado al deshabilitar elementos. Si puedes, usa ARIA disabled. Por supuesto, hay más. Pero el ticker es algo muy aterrador. Así que voy a parar aquí.

Estas son las seis cosas que, si quieres una foto, esta es la diapositiva para tomar una foto. Y todos los... Este enlace en realidad no funciona. Porque hice mis diapositivas y puse esto y olvidé poner algo allí. Así que revisa esto después del almuerzo. Y todos los enlaces de los que hablé estarán aquí. Y si quieres ver basura, sígueme en Twitter. Eso es suficiente de ambos. Estropeado. Voz en off.

Gracias. Alguien en la audiencia, dijeron... ¿Qué software usaste para tus diapositivas? Se ve increíble. Esto es Keynote para Mac. Pero la cosa de la izquierda es solo un área de texto con sintaxis. Y la derecha son videos. Como un montón de videos que grabé. Porque tengo demasiado miedo de hacer esta demostración en vivo. Bastante justo. Las demostraciones en vivo siempre son intimidantes.

Volveremos a la segunda mitad de esta pregunta en un momento. Pero empecemos por arriba, la primera pregunta que llegó. Y las personas que entran y salen, muchas gracias por mantener sus voces bajas, para que los que todavía están aquí puedan escuchar la pregunta. Entonces esto es una de las cosas que cubriste. Porque para mí, especialmente cuando se trata de accesibilidad, estoy pensando... Ok. Ser semántico. Y eso tendrá muchos efectos secundarios. Y cuando lo quitaste del botón y lo cambiaste con Tim, pensé... Eso está haciendo sonar las alarmas. Y esta es más o menos la pregunta. ¿No es mejor seguir usando el elemento semántico más cercano para las pestañas? Como todavía un botón. Porque eso podría manejar el enfoque. Sería interactivo con el teclado. Debo decir que esta pregunta llegó antes de que abordaras la interactividad del teclado y demás. Así que la verdad aquí es que... Es un poco mejor. Porque si usas botones para las pestañas, vas a anular todos los estilos. Vas a anular el orden de las pestañas.

Porque no siempre quieres que sea enfocable. Hay una condición en enfocable. Entonces estás quitando casi toda la semántica de ello. Y en ese punto, no importa si era un botón, un div o un span. Porque estás anulando todo de todos modos. Pero diría... Es mejor intentar comenzar con algo que se sienta más semántico. Porque al anular, tal vez te pierdas algo. Por ejemplo, habría olvidado agregar un estado deshabilitado a la pestaña. Pero mis botones aún tendrían un estado deshabilitado. Así que depende. Es mejor. Pero eventualmente verás que no tiene sentido. No hay diferencia.

Muy bien. Voy a llevar un contador de cuántas veces se menciona esto. Estamos en uno. Estamos en uno. Muy bien. Pasemos a la siguiente pregunta. Que pregunta cómo se haría esto sin JavaScript. Sé que a veces la gente trata de evitar usar JavaScript para hacer todo esto. Y muchas veces, tenías los elementos básicos... Los elementos reales. Pero luego tenías que agregar manualmente esta accesibilidad con JavaScript. Antes de que lo eliminaras e introdujeras el principal... Pensé, esto se está volviendo bastante pesado para un componente. ¿Pero tienes alguna sugerencia?

Sí. Entonces, todo lo que ya está integrado en los navegadores. Por ejemplo, roles y estados de ARIA. Todo eso funcionaría sin JavaScript. Pero para la navegación por teclado, lo predeterminado es la tecla Tab. Entonces, si quieres algo más, si estás creando un widget como una lista de pestañas o un menú, necesitas JavaScript. Es algo complicado. Porque casi quieres asegurarte de que cuando se renderice la UI, ya haya suficiente JavaScript para que la UI sea accesible. Puedes comenzar a usarlo. Y es casi como un... No sé nada sobre rendimiento aquí. Pero hay mucho que pensar sobre qué JavaScript es necesario de inmediato y qué JavaScript se puede posponer. Y mucho de esto lo integramos en nuestros componentes. Por lo tanto, Primer React es una biblioteca de componentes que tiene una pestaña y hay un montón de componentes. Y constantemente nos hacemos estas preguntas sobre qué JavaScript se requiere para integrar de inmediato y qué es algo decorativo o que puede ocurrir más tarde. Entonces, desafortunadamente, no hay una respuesta. Se necesita JavaScript en la web.

Muy bien. Sí, absolutamente. Llegaremos a esta pregunta porque la dejaremos para el final.

Otra persona, como yo, por ejemplo, a veces pienso, oh, mi sitio es accesible, pero tal vez hay algunos casos únicos que no conocía. ¿Hay alguna recomendación de herramientas para ayudar a probar... Para evaluar qué tan accesible es tu sitio web?

Sí. Creo que sí. Hay muchas herramientas, si empiezas a buscarlas. La que realmente me gusta es la familia de herramientas Axe, A-X-E. Y tienen muchos complementos. Tienen un comando de CLI, tienen un complemento para jest, tienen un complemento para storybook. Entonces, en muchos entornos, si estás haciendo algo mal, comienza a mostrarte. Por ejemplo, si estás usando un rol de pestaña sin envolverlo en la lista de pestañas, lo detectará y te advertirá al respecto. Pero luego hay cosas como la design en la que deshabilitamos algo que hace que sea inaccesible. No hay ninguna herramienta para detectarlo. Eso es muy humano... Tienes que probarlo tú mismo. Así que diría que hubo un estudio que analizó cuántos errores de accesibilidad pueden detectar las herramientas. Y creo que llegó a alrededor del 40% o algo así. Es muy bajo. Así que no hay... Diría que te lleva bastante lejos, pero no hay sustituto para las pruebas manuales. Sin duda.

Y porque hablaste de cómo la cosa deshabilitada no necesariamente habría sido detectada por una prueba, esa es otra pregunta, que es si los estados deshabilitados siempre son inaccesibles, ¿es algo en lo que tal vez el navegador debería trabajar para cambiar ese comportamiento incorporado en él?

Sí, esa es la parte difícil de todo esto. Diría que los controles de accesibilidad aún no son tan maduros como los navegadores. Hay una gran brecha. Por ejemplo, todo lo que te mostré funciona en voiceover, en Safari. Pero si estuviera usando Windows y NVDA, el anuncio se vería ligeramente diferente, los problemas podrían ser ligeramente diferentes. Así que todavía estamos en un lugar de esquinas redondeadas de IE6 con las herramientas de accesibilidad. Pero desearía que los navegadores pudieran hacer más, pero si sigues las actualizaciones que ocurren en los navegadores, es muy complicado porque una vez que han construido algo deshabilitado, no hay forma de cambiar eso porque muchos sitios web realmente dependen de la deshabilitación para desactivar algo genuinamente de manera intencional para todos. Así que siempre es como, ahora está aquí, ahora necesitamos un nuevo estado deshabilitado, necesitamos deshabilitado V2 que realmente pueda solucionar esto. Así que desearía que pudieran, pero no veo... Una petición para deshabilitado V2 en el navegador.

Y por último, pero no menos importante, realmente quiero saber las respuestas a esto, Sid, tu estilo de hablar es tan cautivador. ¿Cómo perfeccionaste tus habilidades para hablar en público? Necesito copiar algunas de ellas.

No lo sé. Esa es una pregunta difícil. No sé lo que estoy haciendo. Estoy tan nervioso que solo estoy mirando mi pantalla y hablando. Creo que tal vez algo que funciona para mí es que cada una de mis charlas parece que estoy programando en pareja. Así que estoy programando en pareja con un amigo. Y luego ya no es que esta sea una audiencia que ha venido a escucharme porque eso es aterrador. Esto es solo mostrarte mi código de mierda y espero mejorarlo con cada diapositiva. Así que para convertirte en un gran orador, ten amigos. Voy a luchar.

Muchas gracias, Sid. Aplaudamos una vez más por él.