¿Cuánto tiempo lleva construir una aplicación móvil accesible?

Rate this content
Bookmark

Los conceptos erróneos más comunes sobre la accesibilidad son que lleva mucho tiempo o se puede dejar fácilmente como lo último en agregarse. Pero, por supuesto, esto no es el caso. Veremos lo fácil y rápido que es adoptar la accesibilidad como un Ciudadano de Primera Clase y, por el contrario, lo difícil y lento que es agregar accesibilidad a un proyecto existente.

21 min
24 Oct, 2022

Video Summary and Transcription

Construir una aplicación accesible puede llevar mucho tiempo, pero se puede dividir en dos partes: hacer que una aplicación existente sea accesible y comenzar una aplicación accesible desde cero. React Native Armour puede ayudar con las correcciones de accesibilidad, pero aún se requieren verificaciones manuales. Las mejores prácticas de accesibilidad incluyen enfocar los elementos en el orden correcto, anunciar los cambios de IU a los usuarios del lector de pantalla y garantizar la consistencia en el comportamiento y la apariencia. La construcción de componentes accesibles puede agilizar el proceso de hacer que una aplicación sea accesible.

Available in English

1. Introducción a la Accesibilidad y Solución de Problemas

Short description:

¿Es realmente cierto que construir una aplicación accesible lleva mucho tiempo y es costoso? Vamos a dividir la agenda en dos partes: hacer que una aplicación existente sea accesible y comenzar una aplicación accesible desde cero. La accesibilidad es la práctica de hacer que tu aplicación móvil sea utilizable por la mayor cantidad de personas posible. El problema de accesibilidad a solucionar es un informe real que recibimos, resaltando un problema grave. Utilicé React Native Armour para ayudar con las correcciones, que incluye componentes y hooks para cumplir con los requisitos de accesibilidad. Reemplacé las importaciones de pressable de react-native a react-native-ama, lo que resultó en aproximadamente 200 errores de TypeScript. Tuve que navegar por las pantallas para solucionar problemas y asegurarme de que las etiquetas de accesibilidad fueran claras. Los encabezados se marcaron como encabezados para el lector de pantalla. El formulario presentó otro problema.

Para responder a esa pregunta, vamos a dividir la agenda en dos partes. En la primera parte, tomaremos una aplicación existente y trataremos de hacerla accesible. En la segunda parte, comenzaremos una aplicación accesible desde cero.

Antes de comenzar, mi nombre es Alessandro Lemsenese y soy un ingeniero de software en Formidable. Comencé a trabajar con accessibility hace unos cuatro años. Mi primer trabajo con React en un televisor involucró la creación de una aplicación accesible para un banco. Comencé a aprender más y más sobre accessibility y nunca dejé de hacerlo desde entonces.

Antes de continuar, recordemos qué estamos tratando de hacer. La accesibilidad es la práctica de hacer que tu aplicación móvil sea utilizable por la mayor cantidad de personas posible. Ese es nuestro objetivo. Queremos asegurarnos de que la mayor cantidad de personas posible puedan usar nuestra aplicación. Así que empecemos.

Ahora, el problema de accessibility a solucionar es en realidad un informe real que recibimos de una excelente compañía, donde resaltaron un problema grave y crítico que tuvimos que solucionar en nuestra aplicación. En mi caso, utilicé React Native Armour para ayudarme con estas correcciones. Y la biblioteca es una biblioteca de React Native que construí después de unirme a Formidable. Contiene un conjunto de componentes y hooks diseñados para cumplir con los requisitos mínimos de accessibility. Lo primero que hice fue instalar la biblioteca con Yard, importar el proveedor proporcionado por la biblioteca y envolverlo alrededor de mi aplicación. Para corregir reglas, etiquetas, estados e indicaciones, reemplacé todas las importaciones de pressable de react-native a react-native-ama. Y una vez que hice eso, obtuve alrededor de 200 errores de typescript o reglas y etiquetas faltantes. Y en esta captura de pantalla puedes ver cómo funciona Ama. Básicamente, Ama realiza algunas comprobaciones en tiempo de ejecución, pero además de la tipificación de typescript, realiza una comprobación en tiempo de ejecución de los problemas comunes de accessibility y, si los encuentra, resalta el componente dentro de la interfaz de usuario y muestra un banner, además de imprimir en la consola cuál de las pruebas de accessibility ha fallado.

En mi caso, tenía alrededor de 200 errores y el gran problema que tuve fue que no podía asumir que todo era un botón. Y debido a que el código que escribí para usar no siempre era sencillo, la opción que tuve fue navegar por la pantalla para solucionar el problema. Lo mismo sucedió con la etiqueta de accessibility. Tuve que asegurarme de que la etiqueta de accessibility fuera clara para el usuario del lector de pantalla y también tuve que verificar si era suficiente porque teníamos algunos casos como el que se muestra en la captura de pantalla donde el botón contenía x información, en este caso 5 mensajes, mensajes no leídos. Así que tuve que comunicar esta información al usuario del lector de pantalla utilizando una indicación accesible. Además, debido a que no había trabajado en todas las partes de la aplicación, no estaba seguro de cuántas pantallas teníamos en realidad, así que la única opción que tuve fue recorrer toda la aplicación por mí mismo y descubrir toda la información que faltaba. Para los encabezados, fue más fácil. Solo asegúrate de que cada pantalla tenga un encabezado y que todo lo que parezca un encabezado se lea y se marque como un encabezado para el lector de pantalla. El formulario, presentó otro problema.

2. Solución de Problemas de Accesibilidad del Formulario y la Hoja Inferior

Short description:

El usuario no podía enfocar la etiqueta del formulario y el campo de entrada como campos separados. La tecla de retorno en el teclado no funcionaba correctamente. El envío del formulario no se enfocaba en el primer campo con un error. Utilizamos React Native ARMA para solucionar estos problemas. También abordamos el problema de accesibilidad con la hoja inferior utilizando un componente incorporado de ARMA. Todo el proceso, incluidas las correcciones de errores, llevó más de 5 semanas. Para construir una aplicación accesible, podemos crear componentes compartidos que manejen las propiedades de accesibilidad. Sin embargo, aún se requieren verificaciones manuales para garantizar la compatibilidad con los lectores de pantalla.

El problema más grande era que el usuario no podía enfocar la etiqueta del formulario y el campo de entrada como dos campos diferentes. La opción requerida no se leía y el mensaje no se leía como parte del campo. Otro problema era que, por defecto, React Native muestra un teclado con la tecla de retorno, pero esa tecla de retorno no hace nada. El comportamiento correcto era permitir al usuario navegar por los campos usando el botón siguiente si es necesario y permitir enviar el formulario con la tecla de retorno.

El último problema era que si se enviaba el formulario y había un error, el primer campo que contenía un error debía recibir el enfoque, esto no estaba sucediendo en nuestro caso. Para solucionar esto, utilicé React Native ARMA, especialmente el campo de formulario es un contenedor que maneja el envío del formulario. Entonces, si en este caso el envío falla, el formulario que contiene una referencia a todos los campos internos intentará enfocar el primer campo que marcamos como que contiene un error. Y también, sí, el formulario en sí se utiliza internamente por el campo de texto y el gancho de campo de texto para averiguar qué botón del teclado mostrar.

Para el campo de texto, tuvimos que compartir los componentes, así que tuve que envolverlos. Tuvimos que usar el gancho de entrada de texto donde se utiliza la referencia para permitir enfocar el campo internamente y ver si el campo no tenía validación, si no tenía errores o los diversos atributos y pasar esas propiedades de vuelta al campo de texto. También tenemos un campo de formulario como una casilla de verificación o un combo, en este caso tuve que envolverlo en el formulario genérico proporcionado por ARMA y este campo es capaz de recibir un enfoque de la pantalla del lector.

Para la hoja inferior, la que estábamos usando no recibía ningún enfoque, el usuario aún podía seleccionar cualquier cosa debajo de la superposición de la propia hoja inferior. Así que tuvimos que reemplazar eso y en este caso utilicé uno incorporado en ARMA que abordó el problema de accesibilidad. Además, este tiene el beneficio de desactivar la animación de deslizamiento si el usuario desactiva la animación en el dispositivo. En el momento de la acción, en este caso, si se agrega un intento a la tarjeta, mostramos un mensaje durante unos segundos y el informe que se suponía que debía comportarse más o menos como una hoja inferior, se suponía que debía recibir el enfoque, permitir al usuario suficiente tiempo para interactuar con él y el usuario no debía poder seleccionar nada, ni enfocar nada debajo. En este caso, utilizamos la hoja inferior proporcionada por React Native ARMA, por lo que agregamos todas las características de enfoque y la característica de enfoque, y la usamos en conjunto con la acción de tiempo de espera. Este gancho básicamente permite activar la función que le damos según el estado del lector de pantalla y el dispositivo, por ejemplo, en iOS, si el lector de pantalla está activado, el tiempo de espera nunca se activa, mientras que en Android utilizamos la configuración de tiempo de espera de la acción del dispositivo.

Entonces, ese fue el problema grave y serio que solucionamos, ¿cuánto tiempo llevó? También agregamos correcciones de errores, porque durante el proceso tuvimos que reemplazar algunas bibliotecas con otras que eran accesibles. Así que introdujimos algunos errores, algunos de los cuales no éramos conscientes, porque, por ejemplo, la hoja inferior utiliza modelos, pero React Native en este momento no admite la apertura de múltiples modelos a menos que estén anidados, por lo que también tuvimos que cambiar un poco la lógica en torno a eso para que funcione en la aplicación. Y todo el proceso llevó más de 5 semanas para solucionar. Así que construyamos una aplicación accesible como ciudadano de primera clase. ¿Cómo lo hacemos? ¿Cómo podemos asegurarnos de que nuestra aplicación sea accesible desde el primer día? La solución es fácil, podemos construir componentes compartidos que sean accesibles por defecto. Entonces, dondequiera que tengamos botones con diferentes estados, con diferentes indicaciones, simplemente creamos uno o varios componentes compartidos que manejen todas las propiedades requeridas que necesitamos. Lo mismo podemos hacer para un encabezado, lo mismo podemos hacer para formularios, simplemente nos aseguramos de que los campos ya sean accesibles. Hoja inferior, superposición si es necesario y carrusel, en nuestro caso agregamos un carrusel, tuvimos que hacerlo accesible. Entonces, cualquier componente que realmente necesitemos en nuestra aplicación, podemos crearlo una vez y hacerlo accesible. Lo que vamos a usar ya es accesible por defecto. Necesitamos un poco, solo un poco de tiempo extra para asegurarnos de que todo funcione. Porque ser accesible de forma predeterminada no significa que su aplicación vaya a ser completamente accesible, hay algunas verificaciones que deben hacerse manualmente que no podemos automatizar. Por ejemplo, aún debemos asegurarnos de que cualquier función que construyamos se pueda hacer con el lector de pantalla.

3. Mejores Prácticas y Consideraciones de Accesibilidad

Short description:

El enfoque es importante y los elementos deben enfocarse en el orden correcto. Los cambios en la interfaz de usuario deben anunciarse a los usuarios de lectores de pantalla. La consistencia en el comportamiento y la apariencia es crucial. Se debe verificar el contenido agrupado para asegurarse de que sea accesible. Varios elementos de texto pueden envolverse en una vista accesible para que se lean como uno solo. Eliminar la accesibilidad no tiene beneficios y es costoso. El tiempo necesario para abordar los problemas de accesibilidad depende del tamaño de la aplicación. Verificar y solucionar problemas requiere navegar por toda la aplicación. Las verificaciones deben realizarse tanto en iOS como en Android para evitar introducir errores.

El usuario de lectores de pantalla puede realizar esa función. Además, el enfoque es muy importante. Debemos asegurarnos de que los elementos se enfoquen en el orden correcto. Si se necesita un orden específico por alguna razón, también debemos asegurarnos de que los usuarios de lectores de pantalla puedan realizar ese orden.

Los cambios en la interfaz de usuario se anuncian. Si como consecuencia de alguna acción del usuario actualizamos la interfaz de usuario o mostramos elementos de notificación, debemos asegurarnos de que esa información se proporcione al usuario de lectores de pantalla. Podemos hacer que se anuncie utilizando una de las API de accesibilidad proporcionadas por React Native. Por ejemplo, si aparecen elementos, como errores después de que falle una API, debemos asegurarnos de que ese elemento obtenga el enfoque y sea anunciado por el usuario de lectores de pantalla.

Una cosa muy importante es asegurarnos de que el comportamiento y la apariencia sean consistentes en toda la aplicación. La aplicación debe ser predecible. Si tenemos un botón de Bluetooth, por ejemplo, deben verse iguales. Otra cosa importante a tener en cuenta es el contenido agrupado, si es necesario. A veces esto puede formar parte del componente compartido que creamos, pero debemos verificarlo cada vez. Debemos asegurarnos de que esté bien. En nuestro caso, tenemos un contexto donde tenemos un título, un encabezado, el texto y el autor, y un botón. La cita del día, que es un encabezado, puede tener un enfoque por separado, eso está bien, pero la cita, en nuestro caso una cita de Walt Disney, el texto y el autor deben enfocarse como una sola cosa. Para hacer eso, generalmente podemos envolver los múltiples textos en una vista accesible. Esto obligará al lector de pantalla a leer el texto como uno solo. Este es otro ejemplo de nuestra aplicación, donde tenemos un SUBTOTAL y $20, queremos asegurarnos de que el usuario seleccione la fila SUBTOTAL $20 y lo lea como uno solo. No queremos que el usuario seleccione primero SUBTOTAL y luego $20. Entonces, cada vez que tengamos información relacionada que deba leerse en conjunto, asegurémonos de que así sea.

Aquí hay una pequeña tabla de las desventajas de eliminar la accesibilidad o construir una aplicación accesible desde cero. Si eliminas la accesibilidad, no obtienes ningún beneficio. A pesar de los esfuerzos que tuve que hacer, eliminar la accesibilidad en realidad es muy costoso y requiere un gran esfuerzo. El tiempo necesario para abordar problemas de accesibilidad depende del tamaño de tu aplicación, cuanto más grande, peor. Para encontrar problemas y solucionarlos, debes navegar por toda la aplicación. No puedes simplemente mirar el código y adivinar cómo funcionará. Además, no olvides que todas las verificaciones deben realizarse en ambas plataformas, iOS y Android. Esto significa trabajo duplicado y existe el riesgo de introducir errores.

4. Construcción de Componentes Accesibles

Short description:

Si comienzas con accesibilidad, solo necesitas hacer que los componentes sean accesibles una vez. El componente se encargará de la mayoría de las necesidades de accesibilidad y solo necesitas unirlo. Al probar, solo necesitas probar lo que estás construyendo realmente.

Esto puede suceder si necesitas reemplazar una biblioteca por otra, o si necesitas modificar la lógica para hacerla accesible. Sin embargo, si comienzas con accesibilidad, requiere cierto esfuerzo hacer que un componente sea accesible, pero solo lo haces una vez. Solo lo haces accesible cuando lo creas. Claro, el componente ya manejará la mayoría de las necesidades de accessibility. Eventualmente, solo necesitas unirlo. Cuando haces una prueba, porque aún necesitas probar, solo pruebas lo que estás construyendo realmente. No necesitas probar toda la aplicación desde cero todo el tiempo. Solo pruebas lo que construyes. La accesibilidad es costosa y consume tiempo solo si la pospones. Esa es la realidad. Si la ignoramos, si sabemos que nuestra aplicación debe ser accesible y la ignoramos, solo nos haremos daño a nosotros mismos, probablemente de manera grave, al final. Dejé algunas referencias si deseas obtener más información sobre el React Native Ama y varias pautas a las que puedes consultar para saber cómo construir una aplicación móvil accesible. Eso es todo de mi parte. ¡Muchas 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

TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Top Content
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.
React Advanced Conference 2021React Advanced Conference 2021
27 min
Limitless App Development with Expo and React Native
App development is hard, React and Expo make it easy!It's never been simpler to build and deploy powerful mobile apps with incredible features to both Android and iOS users all over the world.We’ll discuss building and deploying mobile apps seamlessly from the cloud using EAS, creating powerful dev clients (like browsers but for mobile app development) for testing your app, pushing OTA updates instantly to users, and much more — no native experience required!
React Summit 2022React Summit 2022
7 min
How to Share Code between React Web App and React Native Mobile App in Monorepo
Usually creating web and mobile apps require different tech stacks, and it is pretty hard to share code. This talk will show how I added a React web app and a React Native mobile app in the same monorepo using Nx, and how I optimized codeshare between react web app and react native mobile app.
JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.

Workshops on related topic

React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
JSNation 2023JSNation 2023
111 min
Bringing Your Web App to Native With Capacitor
WorkshopFree
So, you have a killer web app you've built and want to take it from your web browser to the App Store. Sure, there are a lot of options here, but most will require you to maintain separate apps for each platform. You want your codebase to be as close as possible across Web, Android, and iOS. Thankfully, with Capacitor, you can take your existing web app and quickly create native iOS and Android apps for distribution on your favorite App Store!
Contents: This workshop is aimed at beginner developers that have an existing web application, or are interested in mobile development. We will go over:- What is Capacitor- How does it compare to other cross-platform solutions- Using Capacitor to build a native application using your existing web code- Tidying up our application for distribution on mobile app stores with naming conventions, icons, splash screens and more
GraphQL Galaxy 2022GraphQL Galaxy 2022
156 min
Hands-On With SwiftUI, GraphQL, & Neo4j AuraDB
WorkshopFree
Bring the power of graphs to iOS mobile app development in this hands-on workshop. We will explore how to use the Neo4j GraphQL Library to build GraphQL APIs backed by Neo4j AuraDB and how to integrate GraphQL into an iOS app using SwiftUI and the Apollo iOS GraphQL library as we build a news reader mobile app.
Table of contents:- Intro to Neo4j AuraDB- Building GraphQL APIs with the Neo4j GraphQL Library- Intro to SwiftUI- SwiftUI + GraphQL
PrerequisitesTo follow along during the workshop attendees will need a Mac laptop with a recent version of Xcode installed. Some familiarity with Swift and iOS app development will be helpful, although not required.
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)