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. Hablemos sobre la construcción de componentes accesibles de React con un enfoque en los lectores de pantalla. Usa el elemento HTML correcto para la accesibilidad. Por ejemplo, en GitHub, hay tres pestañas con opciones. Estas pestañas están hechas usando botones. Veamos cómo una persona con discapacidad visual que usa un lector de pantalla accedería a este sitio web. ¿Qué ven? Voy a habilitar el lector de pantalla y guiarte a través de lo que sucede. Al encender el lector de pantalla, establece el contexto y te dice dónde estás. Por ejemplo, en la aplicación de React, un botón etiquetado como 'Code' tiene el foco y un menú emergente. Dentro del menú emergente, hay varios botones con diferentes etiquetas. Algo interesante sucede. Si no puedo ver la interfaz de usuario, estoy escuchando botones pero no pestañas. Los lectores de pantalla no pueden inferir cosas como pestañas a partir del diseño visual. Para proporcionar esta información, podemos usar la especificación ARIA y sus roles. Al agregar un rol de lista de pestañas al div y un rol de pestaña a cada botón, se transmiten los semánticos. El rol anula los semánticos de HTML. El lector de pantalla identifica las pestañas, pronuncia 'code spaces'. El comportamiento predeterminado de una pestaña es el autoenfoque. Podemos agregar el atributo aria-selected para especificar la selección. Usando React, estoy usando una expresión para establecer aria-selected basado en la pestaña seleccionada. La navegación en el panel de pestañas es desorientadora. Hay grupos separados para la lista de pestañas y el panel de pestañas, y hay una necesidad de navegación entre ellos. Usa las teclas de flecha para navegar dentro del widget. Elimina las pestañas del índice de pestañas, solo la pestaña seleccionada debe ser enfocada. Implementa las teclas de flecha para la navegación. Presiona tab para entrar en el panel de pestañas. Presiona shift tab para volver arriba. La navegación por teclado es un patrón común extraído en un hook. Decide qué teclas vincular según el tipo de widget. Cambia la pestaña seleccionada al enfocarse. Considera la guía de prácticas de autoría de ARIA para interacciones de teclado. Diferencia entre pestañas instantáneas y activadas. Sigue la especificación ARIA y usa el APG como un recurso informativo. Los lectores de pantalla pueden no seguir siempre la guía de prácticas de autoría de ARIA. Usa los elementos HTML correctos, agrega roles, propiedades y estados ARIA. Implementa la navegación por teclado. Usa un ejemplo de GitHub de configuraciones de notificación con elementos semánticos adecuados. Al seleccionar canales de notificación, las opciones se presentan en un menú emergente. El foco está en la primera casilla de verificación, indicando que es la primera opción. El lector de pantalla lee el estado de cada opción. Después de seleccionar la opción deseada, el formulario puede ser enviado. El cambio se guarda y se notifica al usuario. El foco se recontextualiza en el botón del menú emergente colapsado. No renderizar la cuarta opción en ciertas condiciones la oculta de los usuarios de pantalla. Eliminar la condicional y deshabilitar la cuarta casilla de verificación hasta que sea necesario elimina este problema. Usar IR disabled en lugar de disabled hace que el elemento sea accesible para los usuarios de lectores de pantalla y teclado sin afectar el estilo o la cancelación de clics. Tienes que agregar tu propio nombre de clase y asegurarte de que esté deshabilitado. Es accesible por teclados. Voiceover en Mac usa 'dimmed' para significar IR disabled. Agregar otro span que requiera al menos un canal. Se pueden agregar descripciones adicionales usando aria-describeby. LECTOR DE PANTALLA Solo notificar para flujos de trabajo fallidos. Requiere al menos un canal para ser seleccionado. Atenuado sin marcar. Casilla de verificación. Ahora conoces la etiqueta, por qué está deshabilitada y que está atenuada. Y veamos si es lo que quiero decir. Nunca. Menú emergente colapsado. Este flujo parece más intuitivo. Conoces todas tus opciones por adelantado. Una opción estaba deshabilitada, habilitaste otra cosa, y se habilitó de nuevo. Mucho más claro. Se siente como una mejor interfaz de usuario. Necesitamos diseñar con la accesibilidad en mente. La accesibilidad no es algo que puedas simplemente espolvorear al final. Tenemos que llevarlo mucho antes en la etapa. Ten cuidado al deshabilitar elementos. Usa RLDisabled. Lista corta de seis cosas a considerar. Enlaces en mi sitio web. Sígueme en Blue Sky.