Estudio de Caso: Construyendo Componentes Reutilizables y Accesibles de React en GitHub

Hola, soy Sid, y trabajo en el equipo de sistemas de diseño en GitHub. Quiero hablar contigo sobre algo que hacemos en Primer, y la mayoría del código del que hablo hoy es de código abierto. Puedes encontrarlo en GitHub.com barra Primer barra React.

Hablemos sobre cómo construir componentes accesibles de React con un enfoque en los lectores de pantalla. Así que, una advertencia justa primero. No soy un experto en accesibilidad. Solo soy un chico tonto de React. Pero durante el último año y medio, he trabajado con muchos expertos en accesibilidad, y tal vez esta perspectiva de venir de un desarrollador de React en lugar de un ingeniero de accesibilidad, tal vez eso sea solo una mejor o más fácil introducción, una introducción más accesible, si se quiere, para una introducción a la accesibilidad.

Así que, cosas que necesitas para una experiencia accesible, si preguntas en Twitter, obtienes este consejo, que es simplemente no uses un div, usa un botón, y eso es todo. Usualmente viene acompañado de un fondo púrpura con alguna captura de pantalla de código. Así que, ese es el primer paso, supongo. Usa el elemento HTML correcto, y eso es todo. Pero, por supuesto, hay mucho más que entra en esto. Y ligeramente, aunque este consejo es correcto, que uses el elemento HTML correcto, lo encuentro un poco molesto porque es muy reductivo para todo el trabajo que hacen los ingenieros de accesibilidad.

Así que, por ejemplo, esta es una interfaz de usuario que puedes o no haber visto en GitHub. Si presionas el botón de código en el repositorio, obtienes estas tres opciones. Y es algo agradable. Hay estas tres pestañas que puedes alternar. Y cada una de ellas tiene sus propias opciones. Hay un panel debajo. Hemos visto este patrón tantas veces, ¿verdad? Y sabemos que estas son pestañas y que son clicables porque ves esta pequeña colina en la primera. Y la primera es más oscura. Tiene un borde. Así que, sabemos que esta es la seleccionada. Pero no hay nada en la página que diga que es solo un patrón de diseño que hemos visto tan a menudo que se convierte en algo establecido. Y para hacer estas pestañas, uso botones porque soy un profesional. Y, sí, así es cómo funciona. Usando algo de React para conectarlo. Y eso es lo que es. Así que, veamos qué ve alguien que tiene discapacidad visual y usa el lector de pantalla para acceder a este sitio web.

alguien que tiene discapacidad visual y usa el lector de pantalla para acceder a este sitio web. ¿Qué ven? Entonces, voy a activar el lector de pantalla y guiarte a través de lo que sucede. VoiceOver en la aplicación.

React app. Entonces, cada vez que enciendes el lector de pantalla, primero establece el contexto. Te dice dónde estás. En este caso, estoy en la aplicación React. Mi aplicación se llama React app. Y te dice dónde está el foco. Code. Menú emergente. Botón.

Tiene el foco del teclado. Entonces, sé que un botón con la etiqueta code tiene el foco. Y también sé que tiene un menú emergente, lo que significa que puedo presionar la tecla enter y debería abrir el menú emergente y luego puedo navegar dentro de él con mi tecla tab. Botón local. Coda spaces. Botón. Copilot. Botón. Copiar URL al portapapeles. Botón. HTTPS. GitHub. Abrir con GitHub desktop. Botón. Descargar zip. Botón. Local. Botón.

Lo que escuché aquí, si no puedo ver la UI, lo que estoy escuchando es botón, botón, botón, botón. Entrada muy larga. Botón, botón. Y luego vuelves al primer botón.

No se mencionó una pestaña aquí. Como, ¿cuál de estos son pestañas? Y es porque los lectores de pantalla no pueden realmente mirar tu implementación visual, diseño visual, e inferir cosas como estas son pestañas.

Y entonces, si no proporcionas esa información, un lector de pantalla realmente no sabría que pueden cambiar los primeros tres botones, pueden cambiar entre ellos. Y entonces, ¿cómo hacemos...? Probablemente hicimos algo mal aquí, ¿verdad? Porque el elemento botón, tal vez no usamos el elemento correcto. Tal vez deberíamos usar el elemento de pestañas. Pero, por supuesto, no hay un elemento de pestañas. Eso no existe en la web, al menos aún. Así que, todavía solo tenemos estos divs y botones.

Y aquí es donde entra la especificación ARIA. ARIA significa Aplicación de Internet Rica Accesible. Es una especificación. Es una lectura interesante. Y algo que tiene la especificación ARIA son roles. Entonces, ARIA nos proporciona una lista. Es una lista fija de roles que transmite la semántica de la estructura. Así que, por ejemplo, el diseño, la apariencia, cómo está estructurado el contenido, como encabezados, listas, tablas, pestañas. Estos son proporcionados por roles. Y uno de los roles es lista de pestañas. Así que, esto es lo que necesitamos aquí.

Cómo puedes usar estos roles es que volvemos al div y agregamos un rol de lista de pestañas. Y a cada botón aquí, vamos a agregar un rol de pestaña.

Así que, hemos hecho algo interesante. Un botón por defecto tiene un rol de botón. Pero cuando agregas un rol de pestaña a él, en realidad anula la semántica y ya no lo considera un botón. De hecho, podríamos eliminar el elemento botón y simplemente usar un div y transmitiría exactamente la misma semántica.

Lo único que perderíamos es la capacidad de enfocarnos en él con nuestras palabras clave. Y puedes agregar eso de nuevo con un índice de pestaña. Así que, eso es lo interesante aquí, que el rol anula cualquier semántica de HTML, cualquier semántica de elemento HTML que tuvieras.

Ahora, y los paneles tendrían rol de paneles de pestañas. Esa es la conexión aquí. Así que, antes de hacer cualquier otra cosa, primero veamos qué escucharía un usuario de lector de pantalla con nuestros nuevos roles. Lector de Pantalla Lector de Pantalla Botón de menú emergente. Lector de Pantalla Muy bien, vamos a abrirlo. Lector de Pantalla Pestaña local seleccionada uno de tres. Lector de Pantalla Cata spaces pestaña seleccionada dos de tres. Lector de Pantalla Copilot pestaña seleccionada tres de tres. Lector de Pantalla Genial. Hay algunas cosas muy buenas sucediendo aquí. La primera es que ahora estos son identificados como pestañas, no botones. Te dice cuántas pestañas hay en la lista de pestañas. Te dijo uno de dos, dos de tres. Y la tercera cosa que es muy genial es cómo pronuncia code spaces. Siempre dice code spaces, lo cual creo que en este punto deberíamos cambiar de marca. Creo que es un mejor nombre, code spaces.

Pero también hay algo extraño que está sucediendo. El lector de pantalla piensa que cada una de estas pestañas está seleccionada. Y es porque el comportamiento predeterminado de una pestaña es que cuando cambias a ella, se autoenfoca. Así que eso es lo que está esperando aquí. Aunque eso no es lo que estamos haciendo. Lo que estamos haciendo es que tienes que hacer clic o presionar enter en una pestaña para ver el panel de pestañas allí, lo cual es un comportamiento válido, pero no hay forma de que el lector de pantalla lo sepa porque, de nuevo, no puede realmente mirar tus colinas, los bordes en la pestaña.

Así que volvemos a la especificación. Y algo que la especificación también tiene son estados y propiedades, que proporcionan información adicional sobre los elementos. Así que, por ejemplo, sus características actuales o su estado o su relación con otros elementos, incluyendo la selección. Así que podríamos agregar el atributo aria-selected. Y esto toma verdadero o falso.

incluyendo la selección. Así que podríamos agregar el atributo aria-selected. Y esto toma verdadero o falso. Y porque estoy usando React, podría usar una expresión aquí. Y lo que estoy haciendo es básicamente decir si es una pestaña seleccionada, entonces aria-selected debería ser verdadero, de lo contrario falso. Ahora, eso debería arreglarlo. Vamos a comprobar. Pestaña local seleccionada una de tres. Pestaña Cata spaces dos de tres. Pestaña Copilot tres de tres. Bien. Así que solo una de ellas fue seleccionada.

También puedo volver, por supuesto, con un shift más tab. Pestaña Cata spaces dos de tres. Pestaña local seleccionada una de tres. Bien. Ahora que estoy de vuelta en la primera pestaña, lo que quiero hacer es acceder al panel de pestañas. Así que digamos que quiero copiar esta URL. La forma de navegar en el panel de pestañas, supongo, sería simplemente tabular de nuevo. Así que estoy avanzando. Pestaña Cata spaces dos de tres. Pestaña Copilot tres. Copiar URL al portapapeles. Botón. Y esto es muy desorientador, porque estaba en la pestaña local, pero primero tengo que pasar por la lista de todas las pestañas. Y luego recordar, eventualmente volveré a un botón que probablemente esté conectado a la local. Como que algo ha salido mal aquí. Y lo que está sucediendo aquí es que tenemos un grupo aquí con la lista de pestañas antigua. Y luego tenemos otro grupo aquí con el panel de pestañas antiguo. Y necesitamos una forma de saltar entre estos dos.

Y usa la tecla de flecha para navegar dentro del widget. Lo que significa que cuando estamos dentro de la lista de pestañas, deberíamos poder navegar entre las otras pestañas con las teclas de flecha. Pero cuando presionas tab, debería saltar al siguiente widget, que en este caso es perfecto porque el siguiente widget es el panel de pestañas.

Así que para hacer esto, estoy eliminando todas las pestañas del índice de tabulación. Les estoy agregando menos uno. O en este caso, debido al div, podría simplemente eliminar el índice de tabulación, mismo efecto.

Y necesito una forma de entrar en este widget de lista de pestañas. Así que voy a decir que solo la pestaña seleccionada debe ser enfocada para que puedas entrar en ella. Y luego el resto no son parte del índice de tabulación. Así que no puedes navegar con la tecla tab. Pero voy a implementar las teclas de flecha. Y cómo funciona es que agregas un evento de key down. Y esencialmente, si la tecla del evento es flecha derecha, enfoca la siguiente pestaña. Haces element.focus en ella. Y si es la anterior, entonces encuentras la pestaña anterior, llamas a element.focus en esa pestaña. Así que es muy problemático. Y es muy, como, se siente muy manual. Y así es como es. Y es un patrón tan común que de hecho lo hemos extraído. Bien. Primero, déjame mostrarte. Así que teclas de flecha para navegar entre las pestañas. Y una vez que sabes dónde estás, presionas tab para entrar al panel de pestañas. Y luego, por supuesto, puedes presionar shift tab para volver arriba. Y una vez que estás en el widget de lista de pestañas, puedes nuevamente navegar. Así que navegación por teclado. Y este es un patrón común del que creamos un hook. Nuevamente, código abierto primario. Puedes usar el código. Puedes copiar el código.

Y algo interesante es que necesitas decidir qué teclas enlazar. Así que en este caso, necesitamos teclas de flecha horizontal. Pero si esto fuera un list box, que suele ser vertical, puedes usar focus keys dot arrow vertical. Y lo curioso aquí es que incluso si estás usando un lector de pantalla, no eres un usuario visual, no tienes un concepto de que las pestañas son horizontales, las listas son verticales. Pero como estos se convierten en patrones comunes en nuestra industria, si son pestañas, los usuarios de lectores de pantalla esperarían casi que probablemente sean horizontales y usen las teclas de flecha de izquierda a derecha. Intentarían eso primero. Así que si te pones creativo con esto, si quieres pestañas verticales, casi rompes una cierta expectativa, aunque no estás haciendo nada mal. Nada sobre las pestañas dice que deberían ser horizontales. Pero los patrones tienden a establecer comportamientos.

Bien. Pasando de eso. Algo que también podemos hacer es cambiar la pestaña seleccionada al enfocarla. Así que luego usas tus teclas de flecha y a medida que te mueves, la pestaña también cambia. El panel cambia. Así que en la que estés, cuando presionas tab, saltas directamente a ella. Y cómo decides si algo debería tener, como cuándo debería cambiar la pestaña? ¿Debería cambiar al hacer clic o debería simplemente cambiar en vivo cada vez que te enfocas? Y la especificación ARIA en realidad no tiene opiniones sobre esto. Lo deja bastante abierto. Pero hay otro recurso que es la guía de prácticas de autoría ARIA llamada APG que tiene una lista de patrones, patrones comunes, incluidas las pestañas. Y eso en realidad tiene una lista de cosas como cuáles son las interacciones de teclado a las que deberías prestar atención. ¿Cuándo deberías decidir cuándo debería cambiar el enfoque? Y solo para darte una pista aquí, necesitas decidir en función de si la pestaña va a cargar algunos datos. ¿Puede ser instantáneo? Si no puede ser instantáneo, entonces probablemente debería ser activado. ¿Y cómo transmites eso? Así que te lo voy a dejar a ti. Dejar eso para que lo leas.

Pero solo algo a considerar. Este es el recurso adicional. Así que mientras la especificación ARIA es una recomendación de W3C, la recomendación es importante porque los navegadores, el software de accesibilidad y autores como tú y yo deberíamos implementar la especificación, ¿verdad? Como que necesitamos seguir la especificación y esa es la expectativa. Por otro lado, el APG es un recurso informativo. Así que es solo una forma más agradable de decir que esto es solo un blog. Esto no es la especificación.

Así que realmente no puedes enojarte con los screen readers cuando no siguen realmente el APG y diferentes screen readers podrían tener un comportamiento diferente incorporado para eso. Solo una advertencia.

Así que cosas que necesitamos para una experiencia accesible. Todavía necesitamos usar un elemento HTML correcto tanto como podamos. Pero también necesitamos añadir roles ARIA para transmitir semántica y estructuras. Necesitamos añadir propiedades y estados ARIA para que el usuario sepa lo que está sucediendo en vivo. Necesitamos implementar la navegación por teclado por nuestra cuenta para ayudar al usuario a navegar. Y por supuesto, hay más.

Así que usemos un segundo ejemplo. Este es de las configuraciones de notificación en GitHub. Así que este es un pop up donde te da las opciones de dónde te gustaría notificar. Me gusta el email. Y luego revela esta opción adicional que solo puedes ser notificado para flujos de trabajo fallidos. Y creo que eso es muy útil. Así que y también muestra qué configuración fue guardada. Interfaz de usuario bastante agradable. La forma en que escribí esto es que usé un button, usé un popover, usé un form, hay un field set, hay un legend. Cada input tiene un label, el save y cancel, submit y cancel Muy semántico, todos los elementos correctos. Pero veamos qué vería un usuario de screen reader. O escucharía. Así que comenzamos con el enfoque. Me. Never. Menu pop up collapsed. Button. Notify me never. Lee el estado actual. Es un button pop up collapse. Puedo abrirlo con la tecla enter. En GitHub.

with the enter key. On GitHub. On tick. Tick box. Select notification channels. Group. Interesante. Entonces abres el pop-up, el enfoque está en la primera casilla de verificación. Así que eso es lo que leerá primero. Dice en GitHub, es una casilla de verificación sin marcar tick box tick box. Lo mismo. Y luego te dice dónde está esto en GitHub.

Así que es parte de un grupo llamado seleccionar canales de notificación. Y eso establece lo que estás haciendo aquí, de qué se trata este popover. Y puedes tabular para ver cuáles son las otras opciones en el mismo grupo. Así que sabemos que hay una opción, que es en GitHub. Email on tick tick box. App on tick tick box. Cancel button. Save button. Bien, así que sabemos que hay tres opciones, y luego hay un botón de guardar y cancelar. Como te dije, me gusta el email, así que voy a volver al email. Y luego voy a guardar eso, supongo. Cancel app email on tick tick box. Tick email tick box. Genial. Incluso me dice que lo ha marcado. Y ahora, como esto es un formulario y he visto todas las opciones, voy a presionar enter para enviar mi formulario. El cambio está guardado. Notifícame.

Muy bien porque me dice que el cambio está guardado. Me dice cuál es la nueva configuración, notificarme por correo electrónico. Y me dice dónde está mi enfoque. Me recontextualiza en la página. Está en el menú emergente, que está colapsado. Está en el botón que tiene un menú emergente colapsado.

Así que algunos de ustedes ya saben qué salió mal aquí, y este es un patrón bastante común en lenguajes de plantillas, incluyendo React, frameworks de plantillas, incluyendo React. Tendemos a no renderizar elementos basados en condiciones. Así que en este caso, si ninguna de las opciones está seleccionada, no renderizamos la cuarta opción. Solo la renderizamos cuando uno de los canales está seleccionado.

Y es muy común renderizar null en React cuando tu condición es falsa. Pero esencialmente están ocultando la cuarta opción del usuario de pantalla, y solo la descubrirán por accidente cuando naveguen por todos los canales nuevamente, o si les gusta navegar hasta el botón de guardar al final. Pero revelar cosas progresivamente más tarde suele ser un mal patrón cuando se trata de usuarios de datos de pantalla, y sería bueno si simplemente no ocultamos cosas a los usuarios. Así que estoy eliminando la condicional. Y por supuesto, mi botón debería... El cuarto botón solo debería... La cuarta casilla de verificación solo debería activarse cuando una de las otras tres esté... No se puede usar en aislamiento. Así que tal vez podamos deshabilitarla hasta que sea necesario.

Y eso nos da las fichas agradables, y no puedes hacer clic en ella en el navegador. Pero disable tiene sus peculiaridades. No puedes acceder realmente a elementos deshabilitados con el teclado. Se saltaría directamente sobre ellos. Así que nuevamente, los usuarios de lectores de pantalla nunca llegarían a un elemento deshabilitado. La solución para eso es no usar disabled, usar IR disabled. Y lo que eso hace es que lo trae de vuelta al... Lo hace accesible nuevamente para los usuarios de lectores de pantalla, para los usuarios de teclado. Pero no hace el estilo. No hace la cancelación de clics. Así que tienes que implementarlo tú mismo.

Tienes que añadir tu propio nombre de clase, y también tienes que asegurarte de que la gente no pueda entrar o hacer clic en él, y no dispare cosas, porque debería estar deshabilitado ahora mismo. Pero es accesible por teclados de nuevo. Eso es bueno.

SCREEN READER Solo notificar para flujos de trabajo fallidos. Dimmed sin marcar. Casilla de verificación. Así que mencionó cuál es la etiqueta, y luego dice dimmed, casilla de verificación sin marcar. Dimmed es una forma para que voiceover en Mac diga que está IR disabled. Y diferentes voiceovers pueden tener diferentes formas de decir esto. Y típicamente los usuarios en un OS sabrían lo que esto significa. Está dimmed. Saben que está deshabilitado por alguna razón. En este caso, realmente no puedes decir cuál es la razón. Así que sería bueno si también pudiéramos añadir eso.

Así que estoy añadiendo otro span aquí, que dice requiere al menos un canal. Y este no se renderiza condicionalmente. Y estoy añadiendo un aria-describeby en el input. Así que esto es bastante interesante, que puedes añadir etiquetas y descripciones adicionales en la mayoría de los elementos. Y en este caso, el input está etiquetado por mi elemento de etiqueta con el defecto. Pero puede ser descrito condicionalmente por una descripción adicional.

Así es como se renderizaría. SCREEN READER Solo notificar para flujos de trabajo fallidos. Requiere al menos un canal para ser seleccionado. Dimmed sin marcar. Casilla de verificación. Bien. Así que ahora sabes cuál es la etiqueta. También sabes por qué está deshabilitado. Y sabes que está dimmed. SCREEN READER Y ahora veamos todo el flujo de una vez.

Y veamos si es{{^}} Si quiero decir.

Nunca. Menú emergente colapsado.

Botón. En GitHub. Sin marcar. Casilla de verificación. Seleccionar canales de notificación. Grupo. Email. Sin marcar. Casilla de verificación. App. Sin marcar. Casilla de verificación. Solo notificar para flujos de trabajo fallidos. Requiere al menos un canal para ser seleccionado. Atenuado sin marcar. Casilla de verificación. Cancelar. Botón. SCREEN READER Bien. SCREEN READER Solo no. App. Email. Sin marcar. Casilla de verificación. Marcado. Email. Casilla de verificación.

App. Solo notificar para flujos de trabajo fallidos. Sin marcar. Casilla de verificación. Marcado. Solo notificar para flujos de trabajo fallidos. Casilla de verificación.

SCREEN READER El cambio se guarda. Notifícame. Email. Solo flujos de trabajo fallidos.

SCREEN READER Bien. Así que es. Esto es como mucho más descriptivo. Pasas por el flujo. Conoces todas tus opciones por adelantado. Sabes que una estaba deshabilitada. Volviste. Habilitaste otra cosa. Se habilitó de nuevo. Así que puedes volver a ella. Mucho mucho mucho más claro. Ahora, esta es solo mi opinión. Pero creo que incluso para personas que son usuarios videntes. Este flujo parece más intuitivo. O al menos más claro donde ves todas las opciones. Y puedes ver una opción habilitarse. Cuando algo más cambia. Así que creo que esto es en general para todos. Esto se siente como una mejor UI.

Volviendo a las cosas que necesitamos. Así que todavía necesitamos las otras cuatro cosas. Pero además, necesitamos diseñar teniendo en cuenta la accesibilidad. Así que la accesibilidad no es algo que puedas simplemente añadir al final. Tenemos que diseñar. Tenemos que incorporarla mucho antes en la etapa. Todo el camino hasta la etapa de diseño.

Y por último, necesitamos tener cuidado al deshabilitar elementos. Así que a menos que quieras deshabilitar completamente no accesible. No visible para los usuarios de lectores de pantalla. Deberías usar RLDisabled.

Por supuesto, hay más. Pero creo que podríamos estar aquí todo el día toda la noche. Así que voy a parar aquí. Y esta es como mi lista corta de seis cosas a considerar. Todos los enlaces de las cosas que mostré están en mi sitio web en este enlace. Puedes seguirme en Blue Sky. Es donde estoy más activo. No tanto en Twitter estos días. Y eso es suficiente de ambos, Groob. Muy bien, eso es suficiente. Voice over off. Adiós.