Accesibilidad en Discord

Soy Brandon Dale y soy ingeniero de software en Discord trabajando en el equipo de accesibilidad. Estoy aquí para hablar sobre accesibilidad en Discord. Este va a ser un masterclass enfocado en ingeniería donde hablaré sobre algunos de los problemas más interesantes en los que hemos trabajado, los espacios problemáticos alrededor de ellos, y luego mirar los detalles técnicos de las soluciones que hemos construido.

Ahora, antes de hacer eso, quiero dar un reconocimiento al resto de mi equipo porque estoy definitivamente aquí en nombre de muchas personas realmente geniales que han hecho mucho del trabajo del que voy a presumir. Así que solo algunas presentaciones rápidas. Nuestro equipo es Evelyn, nuestra gerente de ingeniería, John es otro ingeniero, Saan es diseñador, Nick nos ayuda con el marketing, Meghan es otra ingeniera, y luego, por supuesto, yo mismo, otro ingeniero.

Ahora, el primer gran proyecto del que quiero hablar es la navegación por teclado. Esto fue algo que hicimos el año pasado y fue un proyecto con un objetivo realmente amplio de simplemente asegurarnos de que puedas hacer cualquier cosa que necesites hacer en Discord solo con un teclado. Esta es una característica de accesibilidad realmente importante porque hay muchas personas que no pueden o tienen dificultades para usar un ratón. Y también encontramos que un buen soporte de teclado es un proxy relativamente bueno de cómo podría funcionar un lector de pantalla en ciertos casos, ya que ambos dependen de navegar un cursor entre elementos enfocables. Así que obtuvimos muchos beneficios en ambos casos.

Así que permítanme mostrarles cómo se ve en Discord la navegación por teclado, en caso de que no estén familiarizados con Discord y no hayan usado la navegación por teclado. Así que aquí lo tengo funcionando, y solo quiero llamar su atención hacia la parte inferior aquí, porque es donde voy a comenzar. Así que voy a enfocar esta entrada de mensaje, presionar tab, y ahora verán este anillo de enfoque azul alrededor de la entrada de mensaje. Si presiono tab de nuevo, puedo moverme a través de otros elementos enfocables, shift tab para moverme hacia atrás. Déjenme ir a un canal que tiene algunos mensajes. Vamos a React Internals. Verán que mi anillo de enfoque persistió porque usé el teclado para llegar a este canal. Y si presiono hacia arriba, puedo moverme hacia arriba a través de los mensajes, hacia abajo me lleva hacia abajo. Puedo usar atajos de teclado mientras estoy enfocado en mensajes como R para responder, y luego puedo usar una navegación similar con las teclas de flecha y todas las otras listas que pueden ver aquí. Así que antes de hablar sobre el proyecto, solo quiero mencionar esta publicación de blog de John. Hizo mucho del trabajo del que voy a hablar y escribió esta excelente publicación de blog sobre el tema. Así que si quieren leer una versión más larga de esto, les recomiendo encarecidamente que la revisen. Tiene muchos detalles realmente interesantes.

Ahora, la primera gran parte de la navegación por teclado de la que quiero hablar son los anillos de enfoque, porque estos son engañosamente simples. Parece algo que debería ser relativamente fácil, pero encontramos que hay muchos casos extremos que hacen esto realmente complicado si quieres escalarlo. Ahora, tradicionalmente, esto es algo que implementarías con la propiedad outline de CSS. Y esto es algo que intentamos hacer, pero encontramos que había muchas complicaciones allí que quiero repasar rápidamente. Así que hubo un puñado de problemas con el uso de outline que encontramos bastante rápido. El primero fue que usar overflow hidden en un contenedor que puede tener elementos enfocables corría el riesgo de recortar el outline.

Así que te mostraré aquí. Si tabulo a este botón, verás que puedes ver el anillo de enfoque en todos los lados excepto en el más a la izquierda. Y eso es porque está justo fuera de esa área de desbordamiento. Y tal como está, los navegadores recortarán ese anillo de enfoque. Esto es algo que generalmente puedes solucionar siendo más cuidadoso con los márgenes y los rellenos. Pero estábamos usando overflow por algunas otras razones, así que fue un poco complicado.

Y también queríamos evitar la potencial batalla cuesta arriba de tener que arreglar siempre, ya sabes, usos de overflow hidden para evitar esto. Lo siguiente con lo que nos encontramos es que el outline solo se puede aplicar al elemento objetivo. Así que, el elemento que está siendo enfocado. Así que, si miras a la derecha aquí, tenemos una entrada de chat que se parece mucho a lo que tenemos en Discord, donde tenemos una entrada y luego un botón, y están todos en este tipo de contenedor lógico. Y idealmente, lo que queremos es, cuando enfoco esta entrada, no queremos que ese anillo de enfoque se aplique a la entrada real. Queremos que se aplique en ese contenedor con el borde negro. Y si miras Discord, esto es lo que hacemos. Pero con CSS y la propiedad outline, no hay una buena manera de hacer eso ahora mismo. Hay esta pseudo clase focus within que te permite decir aplica un estilo si cualquier descendiente está enfocado. Y si habilitamos esto y hacemos clic aquí, puedes ver que nos da lo que queremos, pero la advertencia es que se aplica si cualquier descendiente está enfocado. Así que, si presiono tab para salir de la entrada, verás que el botón está enfocado, y ese anillo de enfoque en el contenedor permanece. Así que, esta propiedad simplemente no es lo suficientemente granular para nosotros.

Otra cosa es que esta propiedad outline no puede adaptarse automáticamente a diferentes colores de fondo. Así que verás aquí que tenemos un botón, y esto es generalmente lo que tenemos, es un botón a nivel de sistema de diseño que se usa en muchos contextos diferentes. Y si tabulo al primero, ese anillo de enfoque azul se ve bastante bien. Pero en el siguiente con este fondo borroso, no realmente. Sabes, es difícil de ver. Y queríamos una solución donde los diseñadores e ingenieros no tuvieran que pensar siempre manualmente y aplicar diferentes anillos de enfoque dependiendo del contexto. Y con outline, eso simplemente no es posible actualmente. Ahora, hay algo en lo que se está trabajando llamado la función de contraste de color en la especificación de nivel cinco del módulo de color de CSS, pero eso todavía es un trabajo en progreso temprano, y no tiene soporte en ningún navegador todavía. Pero realmente estamos esperando esto cuando llegue, porque esto ayudará a resolver muchos de estos problemas de adaptación de color de anillos de enfoque. Y luego este es un problema más pequeño y más molesto, la propiedad outline offset, que es lo que puedes usar para desplazar el outline del elemento objetivo ya sea hacia afuera o hacia adentro. Solo puede tomar un solo valor, por lo que solo puedes aplicarlo uniformemente. Así que, a diferencia de margin y padding y border radius, no te permitirá aplicar un outline que sea diferente en cualquiera de los lados.

Y tuvimos un par de casos donde queríamos un desplazamiento más asimétrico. Ahora, este último aquí, outline no respeta border radius, esto ha sido cierto durante mucho tiempo, pero si tabulo a este botón aquí, que tiene un borde redondeado, verás que en realidad está respetando el border radius. Y eso es porque esto fue realmente solucionado. Cuando escribimos nuestra solución, cuando estábamos trabajando en esto, ese no era el caso. Sabes, los navegadores todavía siempre mostraban este contorno rectangular alrededor de botones circulares, pero cuando estaba escribiendo esta charla, lo probé y he aquí, los navegadores han resuelto este problema. Así que creo que este es un gran ejemplo de cómo realmente estamos tratando de trabajar alrededor de muchas de las limitaciones de la plataforma, pero la plataforma también sigue evolucionando. Y con suerte, algún día algunas de las soluciones que hemos construido aquí serán manejadas nativamente por el navegador.

Así que esos son los problemas con los que nos encontramos. Ahora esta es la solución que construimos. Así que construimos un sistema unificado de focus ring y puedes ver aquí que también lo hicimos de código abierto. Así que si estás interesado en usar esto, es realmente fácil de usar y ha funcionado muy bien para nosotros. Así que déjame mostrarte cómo se ve al adoptar esto.

Así que aquí está la aplicación de ejemplo del repositorio de focus rings. Verás que hay dos importaciones principales, focus ring y focus ring scope. Focus ring es la API principal y es lo que usarás para renderizar el focus ring alrededor de un elemento interactivo o enfocable. Y luego focus ring scope es una especie de punto de referencia para focus ring. Así que si lo miramos aquí, todo lo que tienes que hacer con focus ring scope es proporcionar un contenedor ref que apunte a un elemento DOM y eso se usará como punto de referencia para cosas como la posición para asegurarse de que cosas como la oclusión al desplazarse funcionen como se espera. Así que querrás poner uno de estos en la raíz de tu aplicación, así como cada vez que hagas un contenedor desplazable o un contenedor absolutamente posicionado.

Ahora, en cuanto a focus ring, es realmente fácil de usar. Todo lo que tienes que hacer es encontrar el elemento interactivo enfocable al que te gustaría aplicar el anillo y luego envolverlo alrededor. Puedes añadir algunos props adicionales para configurarlo como una propiedad offset, que funcionará con un número singular, al igual que outline offset, o puedes proporcionarle un objeto como top four, left three, etc. También podrías usar el valor within para tratarlo como un focus within. Así que el anillo se renderizará cada vez que cualquier descendiente esté enfocado. Y luego hay props como ring target y focus target, que ambos toman refs y te permiten configurar a qué elemento se aplica el focus ring y a qué elemento estamos escuchando para eventos de enfoque. Así que eso nos da ese comportamiento del que hablaba antes al apuntar a un elemento diferente al que está enfocado como en nuestro ejemplo de entrada de chat.

El siguiente proyecto del que quiero hablar es el saturation slider, que fue un proyecto relativamente reciente donde añadimos la opción de desaturar colores en la aplicación de escritorio. Esto se añadió porque después de nuestro re-brand, tuvimos algunas quejas de usuarios de accesibilidad de que la alta saturación era un poco difícil para ellos. Queríamos asegurarnos de que hubiera una opción para garantizar que su experiencia en Discord fuera aún cómoda. Así que déjame mostrarte cómo puedes usar el saturation slider y cómo afecta a la UI. Así que si entro en Discord, abro mis configuraciones y voy a accesibilidad, verás el slider aquí en la parte superior actualmente configurado al 100 por ciento y puedes arrastrarlo hacia abajo hasta cero. Y hay alguna UI de ejemplo debajo de él que puedes usar para ver cómo los cambios de saturación afectan las cosas. Así que si lo bajo a, digamos, 50 por ciento, verás que los botones y el enlace y todas esas otras cosas, el slider se ha vuelto un poco menos saturado. Y puedo incluso bajarlo todo el camino hasta cero para darte una especie de experiencia en escala de grises. Así que lo subiré a, digamos, 100. Luego tenemos esta opción debajo, aplicar a elecciones de color personalizadas, donde también puedes aplicar esto a cosas como colores de roles, que son colores definidos por el usuario. Cuando creas un rol, puedes elegir tu propio color. Así que verás aquí donde dice Ultron, es este bonito rosa brillante.

Y si arrastro esto hacia abajo con eso habilitado, también se desatura. Pero si desactivo esto, permanece de ese color brillante.

Ahora, la parte interesante sobre el problema del color de los roles es que estos colores son definidos por el usuario. Y simplemente cambiar la saturación no garantiza que se vea bien. Podrías estar introduciendo algunos problemas de contraste realmente difíciles.

Así que notarás aquí que a medida que ajusto la saturación hacia abajo, los colores de estos roles a la derecha tienden a normalizarse hacia este color gris oscuro o negro. Pero si voy al tema oscuro, verás que todos se han normalizado a este color más blanco. Así que hemos aplicado un nivel adicional de lógica para asegurarnos de que estos sigan siendo legibles. Así que déjame mostrarte cómo implementamos eso. Inicialmente, nuestros colores se implementaron simplemente como valores hexadecimales. Así que lo que hicimos fue traducirlos al formato HSL. Si no estás familiarizado, eso significa hue saturation lightness y te permite definir un color en esos términos.

Ahora, en lugar de usar simplemente el valor de saturación predeterminado, aplicamos un poco de matemáticas. Así que lo que hacemos es multiplicarlo por esta variable CSS de saturación. Ahora, este será un valor entre 0 y 1, y es lo que controla ese slider de saturación. Así que cuando el slider está al 50%, esto será 0.5 y multiplicará ese valor por eso. Así que, al 0%, esto terminará siendo cero dándonos un valor en escala de grises, y al 100%, será uno, dándonos el color original. Así que esa es toda la lógica que se requiere para aplicar saturación a nuestros propios colores. Ahora, para los colores definidos por el usuario, las cosas se complican debido a los requisitos de contraste. Así que lo que hacemos es también ajustar un valor de brillo, y hacemos cosas diferentes entre el modo oscuro y el modo claro. En el modo oscuro, a medida que la saturación se acerca a cero, nos acercamos a 1.

5 para el brillo. Así que aumentamos el brillo en un 50%. Ahora, en el modo claro, hacemos lo inverso. A medida que la saturación se acerca a cero, la reducimos a 0.5, así que 50%. Así que lo que esto nos da es el comportamiento donde, en el modo oscuro, las cosas se aclaran. Y en el modo claro, las cosas se oscurecen. Y eso nos da el comportamiento de texto más claro en modo oscuro y texto más oscuro en modo claro.

Y para lograr eso, utilizamos la propiedad CSS filter, donde primero aplicamos la desaturación. Luego también aplicamos algunos ajustes de contraste con el mismo valor de saturación. Y finalmente, hacemos los ajustes de brillo, lo que nos da ese color final oscuro o brillante.

Así que lo siguiente de lo que quiero hablar es de arrastrar y soltar accesible. Arrastrar y soltar es un patrón de interacción bastante común en Discord donde puedes reordenar diferentes cosas. Y hasta hace muy poco, solo podías hacer eso con el ratón. Pero este último trimestre, lanzamos una actualización que añade soporte tanto para teclado como para lectores de pantalla para hacer lo mismo. Así que déjame mostrarte cómo se ve. Si vuelvo a Discord y uso mi teclado para navegar hasta mi lista de servidores en el extremo izquierdo, puedo presionar comando D en un Mac, y ahora puedes ver que puedo usar las flechas hacia arriba y hacia abajo para moverme. Así que voy a poner esto debajo de aquí. Presiona enter y desaparece. También puedo hacer eso con mis canales. Déjame llegar a ellos. Así que si presiono comando D, voy a poner general en la parte superior y debería funcionar. Así que esto debería ser cierto automáticamente para cualquier superficie de arrastrar y soltar en Discord.

Nuestro sistema de arrastrar y soltar está construido sobre React D&D, que ha sido un caballo de batalla de arrastrar y soltar en la comunidad de React durante mucho tiempo, pero en los últimos años se ha atrofiado un poco en términos de accesibilidad y desarrollo de características. Exploramos migrar a una solución más moderna como React Beautiful D&D, pero encontramos algunos problemas debido a la complejidad de nuestra implementación actual. Intentamos encontrar algunas opciones de código abierto que nos permitieran obtener lo que queríamos con React D&D, pero simplemente no pudimos encontrarlas, así que decidimos construirlo. Esta es una biblioteca que acabamos de abrir al público muy recientemente llamada React D&D Accessible Backend. Esto fue escrito por John, e implementa soporte para teclado y lectores de pantalla para React D&D. Si no estás familiarizado con React D&D, utiliza el concepto de un backend para encapsular y manejar los diferentes eventos nativos, por lo que esto es algo que puedes usar junto con los otros backends más establecidos para obtener soporte de teclado y lectores de pantalla de inmediato. Puedes encontrarlo en ese enlace, así que échale un vistazo si estás, ya sabes, actualmente usando React D&D y buscas mejorar tu accesibilidad.

Muy bien. Así que, el último gran proyecto del que quiero hablar es uno experimental, y ese es la verificación de accesibilidad en tiempo de ejecución. Esto es algo en lo que estamos trabajando actualmente y explorando, y tenemos mucha emoción al respecto, y solo quiero mostrarte cómo podría verse para nosotros y luego hablar sobre la implementación técnica del núcleo del sistema de tiempo de ejecución. Ahora, aquí hay un ejemplo de una versión muy temprana en la que hemos estado trabajando, solo para darte una idea de lo que estoy hablando. Ten en cuenta que esto es completamente interno, solo para desarrolladores. Esto no es algo que un usuario de Discord verá alguna vez, pero te da una idea de lo que estamos hablando con las verificaciones de accesibilidad en tiempo de ejecución. Queremos poder encontrar y reportar automáticamente problemas de accesibilidad a los desarrolladores mientras están trabajando en el producto. Existen sistemas de verificación automática de accesibilidad pero casi todos requieren que detengas lo que estás haciendo, abras alguna herramienta de desarrollador, la ejecutes y luego esperes los resultados, y queríamos eliminar ese punto de fricción.

Ahora, el desafío aquí es que queremos que esto se ejecute prácticamente sin interferir en absoluto, por lo que necesitamos asegurarnos de que no estamos haciendo nada que sea demasiado intensivo y que no estamos perdiendo fotogramas ni nada por el estilo, lo cual es realmente difícil porque tenemos que hacer muchos cálculos diferentes para verificar problemas de accesibilidad.

Así que quiero hablar sobre el sistema de tiempo de ejecución central en el que estamos trabajando y la idea detrás de cómo podemos hacerlo eficiente. Así que aquí hay una vista simplificada del código en el que estamos trabajando ahora para el sistema de tiempo de ejecución. Entonces, lo primero que hay que notar aquí es que usualmente habría una gran lista de reglas de accesibilidad, que definen la lógica y el comportamiento para consultar los nodos DOM relevantes y cómo verificar las relaciones que queremos validar, pero eso es mucha complejidad que realmente no nos interesa aquí, así que las he excluido por ahora.

Lo primero que hay que notar es que esto debería ejecutar la constante de verificación. Ahora, lo que hacemos es desactivar todo este sistema si esta API específica no está disponible. Navigator.scheduling.isInputPending. Probablemente no estés familiarizado con esto porque solo está implementado en Chromium. Si quieres leer sobre ello, recomiendo encarecidamente esta URL, web.dev.isInputPending. Es un artículo realmente bueno de Google que está trabajando en ello que explica qué es y por qué queremos integrarlo en la plataforma. En un sentido simple, lo que hace es decirnos si un usuario está interactuando actualmente con la interfaz. Así que, ¿han hecho clic en un botón? ¿Están escribiendo? ¿Están pasando el ratón sobre algo? Y lo que hacemos es usar esto para salir de nuestro tiempo de ejecución porque lo que estamos haciendo no es realmente el trabajo más importante. Queremos que la aplicación siga siendo receptiva. Así que esto nos da una forma de hacer eso, y lo desactivamos si no existe porque realmente no importa. Esta es una herramienta orientada a desarrolladores, y la mayoría de nuestros desarrolladores van a estar al menos verificando cómo funcionan las cosas en Chrome en algún momento.

Después de eso, tenemos algún estado a nivel de módulo donde seguimos cosas, como IDs de tiempo de espera, y luego qué regla estamos verificando actualmente, qué nodo para esa regla estamos mirando, el conjunto actual de nodos, y luego la verificación real que estamos tratando de construir. Ahora, todo esto es a nivel de módulo porque es efectivamente un estado global. Solo queremos una instancia de esto funcionando. Luego tenemos una función aquí para restablecer ese estado a los valores iniciales.

Ahora, aquí está el punto de partida más interesante, nuestra función de registro. Verás que no hacemos nada si nuestra constante de verificación no es verdadera. Luego, nuestro punto de partida es con un observador de mutaciones. Lo que queremos hacer es buscar mutaciones, todas las mutaciones interesantes, en el documento raíz, y ejecutar nuestra verificación cuando eso ocurra. Ahora, esto es algo que sucede con mucha frecuencia. Cualquier actualización del DOM desde la raíz va a activar esto. Así que, tenemos que tener algo más de lógica más adelante para asegurarnos de que esto no esté sucediendo demasiado o no se esté activando con demasiada frecuencia. Pero verás que escuchamos todos los cambios de atributos, lista de hijos y subárboles. Ahora, lo primero que hacemos en este callback de mutación es restablecer nuestro estado. Y eso es porque cada vez que llega una mutación, no podemos estar seguros de que no haya invalidado las verificaciones que ya hemos hecho. No sabemos si es un cambio de atributo o un cambio de subárbol que puede haber corregido o añadido nuevos problemas.

Así que, la forma más fácil de manejar eso es simplemente comenzar desde cero. Luego hacemos una verificación de tiempo de espera, lo que nos da un comportamiento de debouncing. Y por último, simplemente desacoplamos la verificación de programación durante unos 250 milisegundos. Y luego lo que hacemos en esta función de verificación de programación es simplemente llamar a request idle callback. Así que, tenemos algo de debouncing. Y luego, después de que ese desacoplamiento finalmente se ejecute, lo programamos para el próximo período inactivo. Esto nos da una experiencia realmente buena donde probablemente no vamos a ejecutar esto hasta que el DOM esté en un estado tranquilo y haya algún tiempo inactivo que podamos usar.