Accesibilidad como un Ciudadano de Primera Clase

Entonces, ¿cuál es el lenguaje más popular? TypeScript. Y, por supuesto, React. TypeScript es el mejor lenguaje para aprender JavaScript. Y realmente no se trata del tipo. Se trata del tipo. Se trata de la palabra. El lenguaje se trata de cómo escribirlo. Se trata de cómo puedes aprenderlo, se trata de la forma de expresarlo, y sí, se trata del lenguaje que viene. Se trata de hacer una conexión. Y, por supuesto, React se trata de eso. La mayoría de las personas no investigan mucho cuando se trata de lenguajes o idiomas. Pero se trata de hacer una conexión. Entonces, si estás trabajando en un curso, se trata de hacer una conexión. Si estás trabajando en un bucle, se trata de hacer una conexión. Y eso es todo.

Hola a todos. Y bienvenidos a mi charla. Accesibilidad como ciudadano de primera clase. Mi nombre es Sophie Au. Los pronombres son ella, ellos o él. No me importa mucho. La gente generalmente usa ella, sin embargo. Soy una desarrolladora full stack de front-end. Proveniente originalmente del back-end, pero durante el último año y medio, aproximadamente, he estado trabajando en el front-end, específicamente en React Native. Y en mi tiempo en el front-end de React Native, también he sido algo así como la persona diversa en mi empresa, lo que también me ha llevado al agujero del conejo de la accesibilidad, que supongo que es parte de la diversidad. Si quieres saber más sobre mí, puedes encontrarme en internet en SophieAu.com. En mi sitio web, entre otras cosas, tengo una serie completa sobre accesibilidad y también puedes seguirme en Twitter en Sophie Au.

Antes de comenzar, solo una nota rápida de que esto es algo así como la parte 1 de 2 junto con la charla de Jean-Luc sobre accesibilidad en la web, que se emitirá, o ella emitirá, en aproximadamente una hora, creo, una hora y media. Así que me voy a enfocar más en la accesibilidad en general en la primera mitad de mi charla, entonces, ¿para quién es? ¿Por qué lo hacemos? ¿Cómo lo hacemos? Y luego me voy a enfocar en la accesibilidad en React Native, específicamente. Así que, comencemos.

¿Para quién es la accesibilidad? Cuando pregunto a mis compañeros ingenieros, generalmente la respuesta número uno que obtengo es para personas ciegas, personas con discapacidades visuales, lo cual técnicamente no está mal, definitivamente es para esas personas, pero eso es solo un pequeño subgrupo de personas para quienes necesitamos construir una accesibilidad.

Cuando intento profundizar más, preguntando para quién más podría ser la accesibilidad, generalmente obtengo que es para personas con discapacidades, que, entre otras cosas, incluye a personas sordas o con discapacidad auditiva, personas con discapacidad motora, personas con trastornos neurológicos o mentales, o personas con discapacidades de aprendizaje. Y nuevamente, definitivamente son personas para quienes necesitamos construir una accesibilidad, pero no son todos, porque la accesibilidad también implica construir para personas que tienen una conexión lenta a internet, o ninguna conexión, o una conexión intermitente, personas que tienen dispositivos antiguos y lentos con diferentes tamaños de pantalla, algunos son pequeños, otros son enormes.

Por ejemplo, personalmente, tengo un Samsung Galaxy S5, que probablemente sea más antiguo que la mayoría de las personas que verán esta charla, y si activo el Bluetooth, mi batería se agota inmediatamente, lo que significa que, por ejemplo, no puedo usar la aplicación COVID alemana porque mi teléfono se apaga de inmediato. Pero también debes tener en cuenta las sensibilidades personales de las personas. Algunas cosas que crees que son normales y aceptables pueden resultar ofensivas o hirientes. Y también, especialmente en el desarrollo móvil, debes tener en cuenta que algunas personas son zurdas y algunas personas tienen manos pequeñas, y debes asegurarte de que tu aplicación pueda ser utilizada por todos, es decir, que todos puedan alcanzar las esquinas de la aplicación.

Ahora que tenemos la lista de personas para quienes construimos accesibilidad, ¿por qué deberíamos preocuparnos? Y realmente hay dos cosas importantes. En primer lugar, es lo correcto. No quieres excluir intencionalmente a las personas. Por supuesto, si no estás al tanto de los problemas de accesibilidad de tu aplicación, está bien. Todos comenzamos en algún lugar. Haz lo mejor que puedas. Llega allí. Pero si eres consciente de tus problemas, debes solucionarlos para ayudar a otras personas. Y luego, el punto que generalmente es bien recibido por los altos directivos, tus gerentes, es que no ser accesible puede resultar muy costoso. ¿Y por qué es eso? Porque si tu accesibilidad es deficiente, corres el riesgo de ser demandado. En Estados Unidos, existe la Ley de Estadounidenses con Discapacidades, hay diferentes tipos de legislación en la mayoría de los países de todo el mundo, donde si tu aplicación o tu sitio web no son accesibles, puedes ser demandado, y esos costos legales pueden ser muy altos. Le sucedió a Beyoncé. Le sucedió a Domino's Pizza, y no quieres unirte a ese club. Y no solo son los costos legales los que pueden hacer que sea costoso. También es costoso solucionar ese problema si no quieres ser demandado dos meses después. Solucionar el problema requiere tiempo de ingeniería, requiere tiempo de diseño, es posible que debas rediseñar toda la función porque simplemente no es posible hacerlo de manera accesible. Y también te llevará tiempo, lo que podría darle a tu competidor la ventaja de avanzar y tomar parte de tu mercado. Y no solo es costoso en esa situación, también es costoso en el futuro, donde, ya sabes, hoy en día, las personas quieren trabajar para empresas que hacen el bien, y los usuarios quieren usar aplicaciones de empresas que hacen el bien, y para atraer a un usuario valioso, para atraer a buenos empleados, quieres mostrarles que eres una empresa que valora a las personas, lo cual también incluye hacer que tu aplicación sea accesible, hacer que tu sitio web sea accesible. Y hablando de usuarios, según la Organización Mundial de la Salud, alrededor del 50% de las personas, dependiendo de la estadística, sí, el 50% de las personas de la población mundial tienen alguna discapacidad. Y eso no incluye, por ejemplo, a tus padres, que aunque apenas necesiten usar gafas de lectura porque no son tan mayores y pueden leer perfectamente, o tus abuelos, que aunque no puedan oír nada, simplemente te dicen que no, que hables más alto, que está bien, que no necesitan un audífono. Esas personas ni siquiera se cuentan en esa estadística.

Entonces, ya sabes, si realmente atiendes a las personas que tienen necesidades de accesibilidad, de repente tienes una gran base de usuarios sin explotar que a menudo serás una de las pocas empresas que realmente atienden a ellos y, por lo tanto, obtendrás algo así como un monopolio en tu industria.

Entonces, a partir de ahí, has convencido con éxito a tus ejecutivos de nivel C, a tus gerentes de que necesitas incluir la accesibilidad, pero ¿cómo nos volvemos más accesibles? Y lo más importante es que debes construirlo desde el principio.

Si agregas la accesibilidad más tarde, puedes llegar a cierto punto, pero en algún momento te encontrarás con un obstáculo y llevará mucho más tiempo, mucho más esfuerzo hacer que sea accesible si solo intentas agregarlo más tarde.

Entonces, debes comenzar con el descubrimiento de funciones o el descubrimiento de productos, dependiendo de en qué estés trabajando específicamente. Y eso significa que para cada función, cada producto que construyas, debes considerar todas las implicaciones de accesibilidad.

Por ejemplo, ¿quieres incluir un gráfico interactivo? ¿Cómo puedes hacerlo accesible para las personas que usan un lector de pantalla? ¿O quieres incluir un video o una animación genial? ¿Cómo puedes hacerlo accesible para las personas que, nuevamente, usan un lector de pantalla? ¿O incluso para las personas que pueden ser muy sensibles a ciertas animaciones parpadeantes? ¿Puedes incluir alternativas para que las personas aún puedan usar la aplicación?

Y luego, cuando tengas todas esas implicaciones enumeradas, estima tus historias, estima toda la función teniendo en cuenta la accesibilidad. Lo último que quieres es que construyas tu aplicación, pero termines llegando tarde. La fecha límite fue la semana pasada. Y tienes que decirles, bueno, sabes, todavía no hemos hecho la parte de accesibilidad. Porque eso solo les señala que la accesibilidad lleva tiempo, la accesibilidad es costosa. Y la próxima vez que hagas el descubrimiento de funciones, ellos pensarán, sabes, tal vez deberíamos ser más ligeros en cuanto a la accesibilidad. Y eso no es algo que quieras que suceda.

Entonces has hecho el descubrimiento, has enumerado todo lo que necesitas hacer. Por lo general, en mi experiencia, el siguiente paso es que la función llegue al diseño. Y aquí hay un gran inconveniente, no soy diseñador.

Entonces, si eres diseñador, si hablas con tu diseñador, realmente el mejor recurso para ellos es buscar en Google, hay toneladas de excelentes publicaciones de blog, hay libros sobre accesibilidad y diseño que pueden leer.

Pero aquí hay una selección rápida de cosas a las que los diseñadores deben prestar atención para asegurarse de que su aplicación, su sitio web sea accesible. Cosas como tener colores de alto contraste, especialmente entre el texto y el fondo, poder adaptarse a los niveles de zoom. Cuando haces zoom en la fuente, el diseño no debería romperse. Las áreas de toque, las áreas interactivas deben ser lo suficientemente grandes como para poder hacer clic fácilmente en ellas. Debes construir para los estados de carga y error. Cuando los datos se están cargando o no hay conexión a internet, por ejemplo, y los flujos de tu aplicación deben ser simples y cortos para que las personas no se pierdan a mitad de camino. Como dije, esta es solo una selección breve. Búscalo en Google. No soy un experto. Probablemente no sea la persona indicada para pedir una lista completa.

En cierto sentido, al igual que en el diseño, cuando se trata del contenido, debes mantenerlo a un nivel de escuela secundaria. En general, esto es algo que es fácil de entender tanto para hablantes nativos de inglés como para aquellos que no lo son y tienen un nivel razonable de fluidez.

Por supuesto, esto depende de tu usuario objetivo, ¿verdad? Si tu aplicación está dirigida a estudiantes de doctorado en inglés, probablemente el nivel de lenguaje pueda ser más alto, pero si está dirigida al público en general, debería estar a un nivel de escuela secundaria.

También algo de lo que debes estar consciente, que ya mencioné anteriormente, es asegurarte de que tu lenguaje no sea ofensivo o hiriente para las personas, lo que significa evitar el lenguaje sexista, evitar el lenguaje religioso y especialmente evitar bromas, especialmente si son sarcásticas o un poco provocativas. Porque las personas se ofenderán, las personas las malinterpretarán y de repente te encontrarás en una tormenta en Twitter y eso es algo que tu equipo de relaciones públicas no quiere.

Y de manera similar, debes evitar el lenguaje condescendiente incluso si es accidental. No le digas a tu usuario que haga algo rápido en cinco pasos y se quede atascado durante cinco horas, porque eso solo los hace sentir estúpidos. Alguien que se siente estúpido no va a recomendar tu aplicación a nadie. En el peor de los casos, les dirán a sus amigos y familiares: `Oye, no uses esta aplicación, es una porquería`, cuando en realidad podrías tener una buena aplicación, pero hacer que un usuario se sienta mal no ayudará a tu marketing.

Ahora finalmente estamos en la etapa de ingeniería, donde también entra en juego la principal razón por la que todos parecen pensar que estamos construyendo para personas ciegas. Porque la ingeniería es la parte de la cadena que se construye específicamente para el lector de pantalla. Los diseñadores no tienen mucha influencia en el contenido del lector de pantalla. El equipo de contenido no tiene mucha influencia, excepto por suministrar obviamente el contenido, pero como ingenieros, nuestro trabajo es asegurarnos de que la aplicación, el sitio web, sea utilizable en un lector de pantalla. Pero eso no es todo lo que hacemos. También debemos asegurarnos de que tu aplicación funcione con poca potencia de cómputo, que funcione con una conexión a internet lenta e intermitente, y también que no agote por completo la batería del usuario.

Y finalmente, una cosa en la que nosotros, como ingenieros, tenemos mucha suerte es que hay muchas herramientas disponibles, especialmente para la web, que Jen va a explicar más adelante, que nos permiten verificar que el diseño sea accesible, que el contenido sea accesible, para permitirnos poner una última barrera y asegurarnos de que la aplicación que se va a lanzar en producción sea realmente accesible para el usuario. Y con eso, ya hemos terminado con la parte general, así que si solo estabas aquí por eso, ahora es el momento de tomar un café, tal vez ver la otra charla en SummerTrack, simplemente tomar un descanso, ya sabes, pero por supuesto, también eres bienvenido a quedarte para el Y sí, vamos directo al grano.

En primer lugar, como dije, hay muchas herramientas disponibles para el desarrollo web. Desafortunadamente, para React Native no hay muchas. La única herramienta de la que hablaré es el Inspector de Accesibilidad, ya que estoy dando esta charla en una Mac y la demostración que mostraré más adelante también es una aplicación de iOS.

La única gran herramienta que tenemos los desarrolladores de Mac es el Inspector de Accesibilidad. Funciona como una especie de lector de pantalla falso, pero también nos permite realizar una auditoría, como puedes ver en mi vista del lado derecho. Puede realizar una auditoría que te indica, por ejemplo, que el área de pulsación es demasiado pequeña. Y en el lado izquierdo, también puedes ver que puedes influir, por ejemplo, en el nivel de zoom del tamaño de fuente.

Antes de pasar a la demostración, una nota rápida sobre la API de Accesibilidad de React Native. Lo principal en lo que debes enfocarte son las propiedades de accesibilidad. Hay algunas otras cosas disponibles, pero si quieres cubrir alrededor del 90 al 95% de tus casos de uso de accesibilidad, las propiedades de accesibilidad son las que debes utilizar. Y eso significa que esas propiedades están disponibles para cada componente principal, lo que incluye vista, texto, las diversas listas que tienes, todos los elementos táctiles y también el nuevo presionable. Y hay 14 de esas propiedades. Seis de ellas son solo para iOS o Android. Por lo general, son un poco más específicas de usar. Y luego, las otras ocho, las únicas que realmente necesitas son accesible, etiqueta de accesibilidad, rol de accesibilidad y estado de accesibilidad. En mi experiencia, estas cubren alrededor del 90 al 95% de tus necesidades de accesibilidad.

Y con eso, pasemos a la demostración. Como puedes ver, he preparado una aplicación corta. Es una aplicación de una sola pantalla. Es una aplicación de búsqueda y tu misión actual es restaurar la magia. Para restaurar la magia, debes encontrar siete llaves. Estas llaves las tienen varias personas. Y tienes un botón que te permite marcar la siguiente llave como encontrada. Si hacemos clic rápidamente en esto, como usuario con visión, podrás ver que la primera llave ahora se ha seleccionado como encontrada, lo cual se indica mediante un mayor contraste en las fuentes. Y el icono de la llave que está a la derecha del elemento de la lista ahora es dorado. Y puedes hacer esto para cada elemento de la lista. Y cuando hayas encontrado las siete llaves, el botón para marcar la siguiente llave como encontrada estará desactivado.

Muy bien. Como acabas de escuchar o ver, y como puedes ver a la izquierda en el campo de etiqueta básica aquí, lamentablemente no se enfoca, cada elemento de texto se lee como un elemento individual. Por ejemplo, para una fila de lista que incluye la llave del reino y la reina de las hadas, la reina de las hadas siendo la propietaria de la llave del reino, se leerá llave del reino y luego reina de las hadas como si no tuvieran ninguna relación. Pero por supuesto, están en la misma fila de lista. Así que quieres asegurarte de que un usuario de lector de pantalla sepa que pertenecen juntos. Y para hacer eso, necesitas establecer la propiedad accessible. La propiedad accessible, como acabo de decir, agrupa a todos los hijos en un componente seleccionable, y la etiqueta, es decir, lo que el lector de pantalla va a leer, se establece concatenando todos los hijos de texto. Ahora una nota al respecto es que todos los componentes principales Touchable y Pressable son accesibles de forma predeterminada, lo que significa que el TouchableOpacity, el TouchableHighlight y hay un tercer Touchable que no puedo recordar ahora mismo, pero todos están configurados como accesibles de forma predeterminada. Todo lo demás está configurado como no accesible de forma predeterminada. Así que vamos a establecer esa propiedad. Para eso, echa un vistazo a la línea 8 aquí después del estilo. Así que en este caso, cuando ahora selecciono ese commit, verás aquí que la propiedad accessible se establece en true en el elemento de la lista. Y sí, suponiendo que el simulador no se bloquee, o el inspector de accesibilidad, veamos qué sucede. Se bloquea. Lo siento. Muy bien. No sucede nada, lo cual también es genial. Ahí lo tienes.

Entonces acabas de ver y también escuchaste que ahora esta fila para la llave se lee como llave de ilusión, padre Po, que como acabo de decir, es la concatenación del título y el propietario, pero esto en realidad no le dice al usuario nada sobre el estado de la rosa. Como usuario que puede ver, ahora sabes que esto significa que la llave no ha sido encontrada, pero la etiqueta en realidad no te lo dice. Y ahora cuando establezco la llave como encontrada y ejecuto el inspector nuevamente, esperando que no se bloquee, lo cual lo hace. Vamos.

Acabas de escuchar que incluso cuando está seleccionado, en realidad no hace nada. Entonces lo que quieres hacer es establecer una etiqueta para informar al usuario que, hey, esta llave ha sido encontrada, toda esta tarifa no ha sido encontrada. Y para eso, necesitas establecer la etiqueta de accesibilidad adecuadamente llamada. Como acabo de decir, describe lo que contiene el componente o para qué se utiliza el componente. No debe usarse como reemplazo de un buen diseño de buenos componentes visibles. Solo debe usarse para reorganizar el contenido del componente y permitir que un usuario de lector de pantalla conozca cualquier información que no se pueda transmitir a través del texto. Entonces sí, establezcamos esta propiedad. Ahora lo verás después de la propiedad accessible en la línea 9 a la 11. En realidad, es de la línea 11 a la 13, lo siento.

Entonces aquí, ahora puedes ver que estamos estableciendo el título sostenido por el propietario. Y luego, si la llave ha sido encontrada, se establece como recuperada. Si no, se establece como no recuperada. Veamos si funciona. Y luego el siguiente elemento es leído. Muy bien, ahí lo tienes. Ahora el usuario de lector de pantalla sabe si se ha recuperado esta llave o no. Y eso es prácticamente todo para esos elementos de lista que no son interactivos. Pero como habrás notado, mientras el lector de pantalla recorría la lista, cuando llega al botón para establecer la siguiente llave como encontrada, no hay indicación para el usuario de lector de pantalla de que este botón es presionable, que es en realidad un botón. Suponiendo que eso no se bloquee, lo siento mucho. Por alguna razón, desde la última actualización, el inspector de accesibilidad ha estado específicamente con errores. Pero como puedes ver aquí, ahora estamos en el botón con el lector. Pero la etiqueta se establece como siguiente llave encontrada, que es básicamente lo mismo que cualquier elemento de texto. Entonces, ¿cómo le decimos al usuario, hey, esto es realmente un botón, esto es interactivo? Para eso, necesitas establecer el rol de accesibilidad. Lo que hace el rol es describir, como su nombre lo indica, el rol del botón, el rol del componente, que en muchos casos es el botón. Honestamente, el 90% del tiempo, solo establezco el rol como botón. Pero también hay otros como enlace y encabezado.

Creo que en total hay alrededor de 20. Puedes buscarlos en la documentación. La cosa con el rol es que siempre debes establecerlo manualmente. No hay un valor predeterminado. Esto significa que si tienes un componente táctil o presionable, que en la mayoría de los casos es un botón, debes asegurarte de establecer el rol. De lo contrario, el usuario no se dará cuenta de que es interactivo.

Entonces, vamos a establecer el botón. Para eso, necesitamos ir al componente del botón de actualización. Y ahora, cuando miras la línea 11, hemos establecido el rol de accesibilidad como botón. Y ya en el inspector de accesibilidad a la izquierda, puedes ver que se ha establecido el atributo de botón. Y luego, suponiendo que no se bloquee, ahí lo tienes. Ahora anuncia que el botón es un botón real. Lo cual es genial. Ahora has cubierto alrededor del 90%. Pero todavía hay otro 5% que podemos obtener de esto. Solo anunció botón. Lo que significa que podemos interactuar. Pero como mostré al principio, una vez que has encontrado todas las llaves, el botón se deshabilita. Porque no hay más llaves que encontrar. Desafortunadamente, el lector de pantalla seguirá leyendo solo botones. Entonces, un usuario de lector de pantalla pensará que este botón sigue siendo interactivo.

Lo siento. Ahí lo tienes. Para solucionar eso, necesitamos establecer el estado de accesibilidad. El estado de accesibilidad, como dice, es el estado en el que se encuentra el componente. Puede ser, por ejemplo, cargando o deshabilitado. También puede ser seleccionado o marcado. Y es un objeto, por lo que puedes darle múltiples estados. Entonces, vamos a establecer el estado en este elemento. Ahora puedes ver en la línea 12 aquí, simplemente establecemos el estado como deshabilitado, basado en la propiedad, que es un booleano.

Veamos qué sucede ahora. Ahí lo tienes. Ahora se anuncia que no está habilitado. ¿Qué sucede si el botón está habilitado? Así que déjame restablecer todo esto sigilosamente. Ahí lo tienes. Ahora el usuario sabe que esto es un botón, no se menciona que no esté habilitado, así que debe estar habilitado.

Y sí, eso es prácticamente todo. ya te permiten cubrir alrededor del 90 o 95% de tus necesidades de accesibilidad para todo lo demás. La documentación en React Native es bastante buena en todo lo demás. Hay cosas geniales como poder hacer cosas condicionales basadas en si un lector de pantalla está activado o no, pero no voy a entrar en eso, porque en algún momento, el principio de Pareto entra en juego, donde sabes, esos últimos pocos porcentajes que quieres obtener, requieren mucho trabajo.

Así que sí, eso es todo de mi parte. Muchas gracias, y creo que ahora estamos listos para pasar a las preguntas y respuestas. Gracias.