Accesibilidad como un Ciudadano de Primera Clase

Rate this content
Bookmark

Muy a menudo, A11Y es solo una idea secundaria y se agregará a un proyecto "cuando tengamos tiempo", es decir, nunca. Pero hay muchas razones por las que deberías desarrollar teniendo en cuenta la accesibilidad desde el principio, incluyendo algunas que convencerán a los superiores. Exploraremos las herramientas que podemos usar para ayudarnos a desarrollar de manera más accesible y hablaremos sobre algunas de las peculiaridades y limitaciones que tiene React Native.

24 min
17 Jun, 2021

Video Summary and Transcription

TypeScript y React son lenguajes populares para el desarrollo de software. La accesibilidad es importante para la inclusión y para prevenir demandas legales. Construir accesibilidad desde el principio es crucial, considerando aspectos de diseño e ingeniería. Las herramientas para la accesibilidad de React Native son limitadas. Establecer la propiedad accesible y el rol en los componentes es esencial para los usuarios de lectores de pantalla. La documentación de React Native es útil, pero algunas necesidades de accesibilidad pueden requerir atención adicional.

Available in English

1. Introducción a la Accesibilidad y React Native

Short description:

TypeScript y React son los lenguajes más populares. TypeScript es excelente para aprender JavaScript. React se trata de hacer conexiones. Bienvenidos a mi charla sobre accesibilidad como ciudadano de primera clase. Soy Sophie Au, una desarrolladora full stack de front-end con enfoque en React Native. Me he adentrado en la accesibilidad debido a mi papel como defensora de la diversidad. Visiten mi sitio web y síganme en Twitter. Esta es la parte 1 de 2, con un enfoque en la accesibilidad en general y React Native.

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.

2. ¿Para quién es la accesibilidad y por qué deberíamos preocuparnos?

Short description:

¿Para quién es la accesibilidad? No solo es para personas ciegas o con discapacidades. También es para aquellos con conexión lenta o nula a internet, dispositivos antiguos y diferentes sensibilidades. Construir accesibilidad es lo correcto y puede prevenir costosos litigios. También atrae a usuarios y empleados que valoran la inclusión. Aproximadamente el 50% de la población mundial tiene alguna discapacidad, incluyendo a aquellos con discapacidades menores.

¿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.

3. Building Accessibility and Design Considerations

Short description:

Es crucial construir accesibilidad desde el principio. Considera las implicaciones de accesibilidad para cada función y producto. Estima las historias y características teniendo en cuenta la accesibilidad. Los diseñadores deben centrarse en colores de alto contraste, niveles de zoom, áreas de toque, estados de carga y error, y flujos de la aplicación simples. El contenido debe tener un nivel de comprensión de escuela secundaria para facilitar su comprensión.

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.

4. Construyendo para Accesibilidad e Ingeniería

Short description:

Asegúrate de que tu lenguaje no sea ofensivo o hiriente. Evita el lenguaje sexista, el lenguaje religioso y las bromas sarcásticas o provocativas. El lenguaje condescendiente puede hacer que los usuarios se sientan estúpidos y dañar la reputación de tu aplicación. La ingeniería es crucial para construir accesibilidad, especialmente para lectores de pantalla. Los ingenieros se aseguran de que la aplicación funcione con poca potencia de cómputo, internet lento y no agote la batería. Las herramientas nos permiten verificar la accesibilidad del diseño y contenido y asegurarnos de que la aplicación sea accesible antes de su lanzamiento.

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.

5. Herramientas, API de Accesibilidad y Demostración

Short description:

Hay muchas herramientas disponibles para el desarrollo web, pero desafortunadamente no hay muchas para React Native. La principal herramienta para los desarrolladores de Mac es el Inspector de Accesibilidad, que funciona como un lector de pantalla falso y nos permite realizar auditorías. El enfoque principal de la API de Accesibilidad de React Native son las propiedades de accesibilidad, que cubren alrededor del 90 al 95% de los casos de uso de accesibilidad. Ahora pasemos a la demostración, donde verás una aplicación de búsqueda de una sola pantalla donde debes encontrar siete llaves para restaurar la magia.

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.

6. Usando la Propiedad Accessible para Lectores de Pantalla

Short description:

Cuando se utiliza un lector de pantalla, cada elemento de texto se lee como un elemento individual, incluso si están relacionados. Para asegurarse de que los usuarios de lectores de pantalla sepan que estos elementos están relacionados, es necesario establecer la propiedad accessible. Al establecer la propiedad accessible en true, todos los hijos se agrupan en un componente seleccionable, y el lector de pantalla leerá los hijos de texto concatenados como la etiqueta. Los componentes principales Touchable y Pressable son accesibles de forma predeterminada, mientras que todo lo demás no lo es. Establecer la propiedad accessible en true en el elemento de la lista lo hará accesible.

Muy bien. Así que primero una advertencia rápida. El inspector de accesibilidad, desafortunadamente, a veces tiene algunos errores. Así que si se bloquea, por favor ten paciencia. Reiniciarlo es muy rápido. Así que sí, vamos a repasarlo rápidamente con el lector de pantalla para entender qué es lo que un usuario no vidente realmente verá o escuchará en este caso, en realidad. Ahí lo tienes. Te lo advertí, es un poco inestable. Lo siento mucho por eso. Pero por lo general se resuelve por sí mismo eventualmente. O no.

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.

7. Estableciendo Etiqueta y Rol de Accesibilidad

Short description:

La etiqueta de accesibilidad describe lo que contiene o se utiliza en el componente. No debe reemplazar un buen diseño, sino transmitir información que no se puede transmitir a través del texto. Al establecer la etiqueta de accesibilidad, los usuarios de lectores de pantalla pueden saber si se ha recuperado una llave o no. Sin embargo, para elementos interactivos como botones, es necesario establecer el rol de accesibilidad para indicar que es presionable e interactivo.

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.

8. Estableciendo Rol y Estado de Accesibilidad

Short description:

Para asegurar que los elementos interactivos sean reconocidos correctamente por los lectores de pantalla, es necesario establecer manualmente el rol de accesibilidad. Establecer el rol de accesibilidad como 'botón' para un componente táctil o presionable indicará al usuario que es interactivo. Sin embargo, si el botón se deshabilita, el lector de pantalla seguirá leyéndolo como interactivo. Para solucionar esto, se puede establecer el estado de accesibilidad como 'deshabilitado' para transmitir con precisión el estado del botón a los usuarios de lectores de pantalla.

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.

9. Reflexiones Finales y Preguntas y Respuestas

Short description:

Ahora se anuncia que no está habilitado. ¿Qué sucede si el botón está habilitado? La documentación de React Native es buena para todo lo demás. El principio de Pareto se aplica a las últimas necesidades de accesibilidad. Eso es todo de mi parte. ¡Gracias!

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions