Accesible por Defecto: Construyendo Apps Que Todos Pueden Usar

Esta charla trata sobre algo que a menudo se considera como una idea tardía en el desarrollo de apps, la accesibilidad. Pero si queremos construir para la escala, para la inclusión y para la longevidad, la accesibilidad no puede ser opcional. Una vez escuché a un orador realmente brillante decir, todos estamos pre-discapacitados. Esa frase realmente se quedó conmigo porque la verdad es que, ya sea por envejecimiento o lesión o simplemente la vida misma, cada uno de nosotros probablemente experimentará algún tipo de limitación en algún momento.

Piénsalo. Tal vez un brazo roto o intenta sostener un bebé mientras revisas tu teléfono, luchando por ver tu pantalla con luz brillante. Esas son todas discapacidades situacionales. La accesibilidad no es solo para otras personas, es para todos nosotros. No todos interactúan con la tecnología de la misma manera. Algunas personas usan lectores de pantalla, algunas navegan completamente con teclados, y algunas tienen su tamaño de fuente muy aumentado solo para leer.

La accesibilidad cubre todo un espectro. Discapacidades permanentes como baja visión o impedimentos motores. Temporales como romperse un brazo o usar tu teléfono con tu mano no dominante. E incluso situacionales como sostener un bebé o leer a la luz del sol o tal vez incluso lidiar con un mal internet. La accesibilidad no es una característica, es la base para un buen diseño. Así que la accesibilidad no es solo para otras personas. Es para ti, tus compañeros de trabajo, tus padres, tu yo futuro. Y cada vez que construimos apps con esa mentalidad, no solo estamos cumpliendo con casillas, estamos creando experiencias que son más utilizables, más reflexivas y más inclusivas para todos.

Así que aquí está nuestro plan. Hoy, vamos a hablar sobre por qué esto es importante, lo que React Native ofrece actualmente, una demostración de una app rota, vamos a arreglar algunas características allí, revisar algunas herramientas que puedes usar, y al final, quiero que tengas algunas conclusiones prácticas que puedas aplicar de inmediato. Primero y ante todo, ¿quién soy yo? Mi nombre es Carly Lam. He trabajado en startups y empresas y he construido apps que han escalado desde MVPs improvisados hasta la adquisición por parte de Fortune 1. Lo que he visto en todas las industrias es que las apps que escalan tienen una cosa en común. Están construidas para más que solo el usuario ideal. Están construidas con calidad y claridad y cumplimiento ya integrados. Y esta es la receta.

Así que comenzamos con esa claridad técnica, límites limpios, modularidad y arquitectura escalable. Luego podemos construir esa resiliencia con observabilidad y manejo de errores. Pero cuando realmente quieres escalar, cuando estás siendo evaluado por empresas, gobiernos, o incluso solo un uso de tráfico realmente alto, alcanzas este nivel superior, y eso es esa seguridad y cumplimiento.

Y la accesibilidad, no es solo una amabilidad de UX. Se encuentra justo aquí bajo cumplimiento. Es requerida bajo el WCAG y es aplicada por el ADA. Y es tu boleto para los negocios serios. Uno de cada cuatro adultos en los Estados Unidos tiene alguna forma de discapacidad que impacta cómo están interactuando con la tecnología. Eso es una cuarta parte de tu base potencial de usuarios.

Y eso es solo lo que se reporta. Pero aquí está el verdadero problema. La mayoría de nosotros experimentaremos algún tipo de impedimento, ya sea envejecimiento, lesión, o simplemente sosteniendo un bebé como mencionamos antes mientras sostienes tu teléfono. La accesibilidad no se trata de ellos. Se trata de nosotros. Saltarse la accesibilidad, no solo perjudica a tus usuarios.

Pone a tu empresa en un riesgo serio. Legalmente, financieramente, reputacionalmente, las demandas relacionadas con la accesibilidad están realmente en aumento en este momento. El ADA y WCAG están siendo aplicados activamente. Y aquí está la parte que la mayoría de los equipos pasan por alto. Tu app podría no ser permitida en algunos países si no cumple con los requisitos de accesibilidad. Ahora no estamos hablando solo de perder una cuarta parte de tu audiencia en los EE.UU. Son países enteros o incluso continentes a los que tu producto puede que nunca llegue. Por ejemplo, la Ley de Mercados Digitales de la Unión Europea ahora requiere que las apps cumplan con estándares de accesibilidad mucho más estrictos solo para permanecer listadas en las tiendas de apps de la UE.

Así que eso significa que características como la navegación por voz o el contraste ajustable y los subtítulos, no son solo agradables de tener, son realmente obligatorias. Así que si no cumples, tu app podría ser eliminada de esos mercados por completo. Así que cada vez que omitimos la accesibilidad, no solo estamos ignorando a los usuarios, estamos cerrando silenciosamente esa puerta a toda una oportunidad global. Domino's. Se vieron arrastrados a una demanda de seis años por un usuario con discapacidades visuales que no podía pedir pizza en su app. Target, tuvieron que pagar $6 millones. Nike, perdieron la confianza de los usuarios cuando los lectores de pantalla fallaron. Las apps bancarias bajo presión se rompieron completamente cuando los usuarios escalaron el texto. Estos no son solo casos aislados, son casos bastante comunes.

La palabra accesibilidad literalmente significa fácil de alcanzar o usar. Así que cuando las apps están diseñadas de esa manera, los usuarios se quedan más tiempo porque las cosas simplemente funcionan. Grandes objetivos de toque, etiquetas claras, fuentes legibles, estos no solo ayudan a las personas con discapacidades, mejoran la usabilidad para todos nosotros. También ayuda a aumentar la retención de usuarios. A los usuarios realmente les gusta cuando las apps son fáciles de usar, e incluso obtienes algunos beneficios de SEO. Así que veamos un ejemplo rápido que muestra cuán universal es realmente la accesibilidad. Cuando todos los cubículos en un baño público están abiertos, apuesto a que la mayoría de nosotros vamos directamente al accesible. ¿Por qué? Porque es más grande, es más fácil moverse en él, y simplemente más cómodo. Este último cubículo fue diseñado para personas con discapacidades, pero termina funcionando mejor para todos. Padres con niños, viajando con equipaje, o cualquiera que simplemente no quiera que sus rodillas toquen la puerta. Ese es el corazón del diseño accesible. No solo es inclusivo, es simplemente un mejor diseño.

Y hay una foto divertida de ChatGBT cuando pregunté, ¿cómo se siente usar el cubículo pequeño en comparación con el cubículo para discapacitados? Así que hablemos de por qué React Native es un gran lugar para comenzar esta conversación con el desarrollo de apps. Bueno, es uno de los frameworks móviles de más rápido crecimiento en el mundo, impulsando apps de millones desde Meta hasta Coinbase y Shopify. Debido a que es multiplataforma, una mejora de accesibilidad instantáneamente ayuda a los usuarios tanto en iOS como en Android. Así que la accesibilidad en React Native todavía está evolucionando, pero eso significa que tenemos la oportunidad de moldear cómo crece. Así que si vas a comenzar a abordar la accesibilidad, comienza donde tu alcance sea mayor. Comienza donde las herramientas son convencionales, comienza donde tus soluciones realmente importan rápidamente. React Native nos da ese alcance y esa responsabilidad.

Así que primero lo primero, hablemos de semántica. La semántica es realmente importante en el código de tu app. La semántica le da a tu app un significado más allá de cómo se ve. En React Native, la mayoría de las cosas se construyen con vistas, pero una vista es solo una caja. Puedes hacer que se vea como un encabezado o un botón, pero la tecnología asistiva realmente no sabe qué es a menos que se lo digas, ¿verdad? Así que si no estás usando un componente de botón, en su lugar estás construyendo uno personalizado usando una vista, la tecnología asistiva no sabe que estás representando esa vista como un botón. Así que ahí es donde usamos nuestros props de accesibilidad. Por ejemplo, la regla de accesibilidad realmente podría ser útil aquí porque le dice al lector de pantalla qué es el elemento, no solo cómo se ve. Esto le da a tu app una estructura real, hace que la navegación sea más fácil para todos.

Así que veamos un ejemplo rápido. Así que este es un ejemplo simple aquí. Así que puedes ver a la izquierda, tenemos un elemento de texto con estilo que parece un encabezado, pero no se comporta como uno. Y luego a la derecha, tenemos este rol de accesibilidad que hemos asignado como un encabezado. Así que ahora realmente actúa como un encabezado para los usuarios de lectores de pantalla. Ese pequeño cambio ahí hace una gran diferencia. Mejora la navegación y le da a tu app una estructura real. Así que definir roles es una de las formas más simples y más pasadas por alto de hacer que tus apps de React Native sean mucho más accesibles. Y aquí hay algunos roles comunes. No necesitas una lista enorme para comenzar. Solo estos roles aquí cubrirán alrededor del 90% de lo que necesitas. Siempre que asignamos estos roles, le estamos diciendo a la tecnología asistiva, oye, esto es un botón. Esto es un encabezado, solo un cambio realmente pequeño en tu código que puedes hacer, pero una mejora masiva en la experiencia. Así que vamos a echar un vistazo aquí a una aplicación como ejemplo. Aplicación muy simple.

Es una app de tareas pendientes. Así que las características son muy simples. Puedes agregar diferentes tareas. Puedes marcarlas como completadas o no. Si las has completado, elimínalas, edítalas. Aplicación muy simple.

Pero para nuestros usuarios con discapacidades, puede haber algunos errores ocultos que hacen que esta app sea demasiado compleja y realmente frustrante de usar. Así que vamos a echar un vistazo a esta aplicación aquí. Y va a navegar por la app usando un lector de pantalla.

Así que primero y ante todo, si nunca has usado un lector de pantalla al probar tu aplicación, si estás usando iOS, vas a usar una herramienta llamada VoiceOver, y solo tienes que ir a tus configuraciones, accesibilidad, y VoiceOver. Si estás usando Android, vas a usar una herramienta llamada TalkBack, donde solo tienes que ir a accesibilidad y luego activar TalkBack.

Así que voy a hacer clic en esta aplicación aquí, y vas a escuchar el VoiceOver, y vas a escuchar al lector de pantalla hacer clic en la aplicación. Mis tareas. Texto. Actualmente estás en un elemento de texto. Lista de títulos simples. Texto. Actualmente estás en un elemento de texto. Así que de inmediato, nos hace saber que es un elemento de texto, pero no necesariamente sabemos que estos son encabezados hasta ahora. Tarea de hoy. Texto. Actualmente estás en un elemento de texto. Ingresar nueva tarea. Inserción al comienzo del texto. Editar texto. Así que este es un punto importante aquí. Nos hace saber que estamos en un campo de texto y podemos escribir para comenzar a escribir texto, pero no necesariamente sabemos qué tipo de texto poner aquí. Ahora, esta es una aplicación realmente simple, por lo que podríamos asumir que la información que escribimos aquí va a ser una tarea para nuestra lista de tareas, pero imagina que esto fuera un formulario realmente grande con mucha entrada de usuario. Sería casi imposible si no les dijéramos para qué era la entrada y qué poner allí.

Actualmente estás en un campo de texto. Para ingresar texto en este campo, escribe. Otro punto importante aquí. Ahora mismo estamos resaltados sobre este botón de más para agregar nuestra tarea. Ahora, solo tenemos un ícono allí. No hay texto, por lo que el lector de pantalla no tiene nada que leer al usuario final, por lo que está completamente en silencio. El usuario no tiene idea de este botón aquí porque no lo hemos etiquetado con algún tipo de etiqueta de accesibilidad. Aquí hay otro. Ahora mismo estamos resaltados sobre la casilla de verificación para una de nuestras tareas. Esto es comprar comestibles aquí. No nos está informando cuál es el estado de esa casilla de verificación, lo cual es bastante importante porque esa es básicamente la característica principal de esta aplicación, poder marcar los elementos de nuestra lista de tareas y ver qué hemos completado. Comprar comestibles.

Texto. Actualmente estás en un elemento de texto. Ahí estamos. Sabemos que tenemos una de las tareas, pero no sabemos cuál es su estado. Sabemos que comprar comestibles está en las tareas, pero tal vez no recordamos si ya lo hicimos o no. Bueno, ese es todo el punto de esta lista de tareas, asegurarse de que completemos los elementos en nuestra lista de pendientes. Nuevamente, puedes ver que estamos resaltados en el botón de edición aquí, que es un ícono. No puede leernos qué es ese botón. Lo mismo con el botón de eliminar allí.

Comencemos a ver dónde podemos empezar a arreglar esta aplicación aquí. Este es un muy buen lugar para comenzar aquí. Cada elemento interactivo obtiene una etiqueta y un rol. Esto por sí solo puede transformar una experiencia de lector de pantalla. Sin mencionar que solo toma unos 10 segundos comenzar a agregarlo a tu aplicación. Veamos esto más de cerca en el código y hablemos de ello.

En esta diapositiva, puedes ver una comparación lado a lado de nuestra aplicación de tareas antes y después de agregar esas propiedades de accesibilidad. A la izquierda, puedes ver que la entrada de texto y el botón de opacidad táctil se ven bien. Funcionan visualmente, pero no dan retroalimentación significativa a alguien que está usando un lector de pantalla. A la derecha aquí, verás que hemos agregado solo tres propiedades que cambian completamente la experiencia. Primero está la etiqueta de accesibilidad. Esto le da al elemento un nombre realmente claro y legible, como ingresar nueva tarea o agregar nueva tarea. De esa manera, los usuarios saben exactamente con qué están interactuando. Luego tenemos nuestra pista de accesibilidad. Aquí es donde agregamos la guía, como tocar dos veces para agregar la tarea a tu lista o explicar qué sucede cuando el usuario toma acción aquí. La última es este rol de accesibilidad. Así es como le decimos a la tecnología asistiva qué es este elemento. ¿Es un campo de texto? ¿Es un botón? ¿Es un encabezado? Esto permite que la navegación tenga sentido. Estas tres simples líneas de código, y de repente, tu aplicación tiene una voz. Eso es lo que la hace verdaderamente usable para todos. A continuación, hablemos sobre contenido dinámico.

El contenido dinámico, cada vez que cambiamos el estado de marcar y desmarcar elementos en nuestra lista, así es como podemos hacerlo aquí. A la izquierda, solo estamos iterando sobre algunas tareas y representándolas visualmente. Se ve bien, pero el lector de pantalla no sabe qué es un checkbox, qué es una tarea completada, o qué botón hace qué. No hay significado semántico allí.

A la derecha, hemos mejorado cada elemento con propiedades de accesibilidad. Ahora el lector de pantalla no tiene que adivinar. Están guiados. Esa es la diferencia entre código accesible y esa frustración invisible. Echemos un vistazo más de cerca aquí. Podemos ver que todo el elemento de la tarea tiene esta etiqueta de accesibilidad. Así es como anunciamos el nombre de la tarea y si está completada.

Luego tenemos el rol de accesibilidad. Este es un checkbox para el toggle. Esto deja claro a los lectores de pantalla qué tipo de control es. Luego hemos agregado este nuevo aquí, este estado de accesibilidad. Así es como obtenemos esa representación dinámica. Da el estado actual, ya sea marcado o desmarcado, tal como lo haría un checkbox nativo. Para los botones de edición y eliminación, también hemos agregado ese rol de accesibilidad de un botón. Estas etiquetas claras te permiten interactuar mejor con la aplicación.

Ahora la aplicación puede leer, esto es un checkbox. Esta es la tarea de comprar comestibles. Está marcado, básicamente. La aplicación puede funcionar correctamente ahora.

Echemos un vistazo a nuestra aplicación después de que hayamos hecho algunos cambios aquí. Puedes ver lo que nuestro voiceover está diciendo aquí. Ingresamos una nueva tarea, toca aquí para agregar una nueva tarea a tu lista. Actualmente estás en un elemento de texto.

Botón de agregar nueva tarea, así que ahora lo hace clic. Nos informa que este es el botón de agregar nueva tarea. Habrá una pista aquí para informarnos que debemos hacer doble toque para agregar la tarea a tu lista. Actualmente estás en un botón.

Ahora tenemos mucha más información mientras usamos la aplicación. Ahora estamos en el checkbox aquí. Nos informa que no está marcado. Editar tarea, comprar comestibles. Editar tarea, comprar comestibles. Ahora nuestros botones de icono nos están dando más información. En general, la aplicación es mucho más fácil de usar ahora, solo con unas pocas líneas de código.

Aquí hay otra cosa de la que hablar, y eso es el escalado de texto. Esto es algo que muchos desarrolladores olvidan. Los desarrolladores pueden y aumentan el tamaño de fuente de su sistema. Si tu aplicación no lo soporta, las cosas se rompen.

De hecho, en mi último rol, tuvimos un usuario que se comunicó porque literalmente no podía entrar en la aplicación. La primera pantalla era una página de permisos pidiéndoles que permitieran su ubicación, pero el tamaño de fuente era tan grande, y el botón de aceptar estaba empujado fuera de la pantalla, y no lo envolvimos en una vista de desplazamiento, por lo que no tenían forma de moverse hacia abajo en la página, hacer clic en el botón de aceptar, y entrar en la aplicación. Eso no es solo un error menor de estilo.

Eso es un usuario realmente bloqueado de usar el producto. Aproximadamente el 20 al 25% de los usuarios de iOS aumentan su tamaño de texto usando tipo dinámico. En Android, es aproximadamente del 15 al 20% de los usuarios que aumentan su escalado de fuente en su configuración de accesibilidad. En promedio, estamos viendo aproximadamente una de cada cinco personas usando tu aplicación.

Ellos pueden estar viendo un diseño completamente diferente al que piensas y en el que has estado probando. Veamos esto en acción, y te mostraré cómo se rompe y luego cómo solucionarlo. Aquí está esa misma aplicación de tareas. Voy a ir a mi configuración en mis ajustes de accesibilidad. Iré a pantalla y tamaño de texto, habilitaré mis tamaños de accesibilidad más grandes, y luego simplemente lo aumentaré al máximo. Vamos a refrescar nuestra aplicación y ver cómo se ve ahora. Puedes ver aquí que tenemos algo de texto saliéndose de la pantalla. Nuestros elementos de tareas, no puedes leer la línea completa allí. Parece que nuestros iconos no están escalando efectivamente. Tenemos algunos botones aquí abajo donde no tenemos suficiente espacio para el texto más, por lo que el botón no ha escalado con el tamaño del texto. Echemos un vistazo al código y veamos con qué cambios podemos comenzar.

A la izquierda aquí, la aplicación usa algunos estilos codificados para encabezados y sub-encabezados. Eso es lo que resulta en esos textos cortados o ilegibles para los usuarios que dependen de las fuentes más grandes, como acabamos de ver. A la derecha, hemos agregado algunos estilos para escalar dinámicamente, así que acerquémonos a esto. Hemos actualizado los estilos para escalar dinámicamente usando ese pixel ratio dot get font scale y el math dot max. Esto es para asegurarnos de que incluso cuando los tamaños de fuente aumenten, el texto aún permanezca legible y se ajuste dentro del diseño en el que está. Esta es una buena manera de asegurar que haya una mejor experiencia de usuario para los usuarios que tienen baja visión, usuarios mayores, o realmente cualquiera que personalice su tamaño de fuente para comodidad. También hemos mantenido esos props de accesibilidad de los que hablamos, así que la etiqueta de accesibilidad, las pistas, y el rol. Etiqueta, texto, y accesibilidad semántica, van de la mano, y ambos realmente importan. Después de que agregamos solo algunos cambios simples aquí, veamos la aplicación ahora.

Ahora podemos ver que nuestro texto está escalando efectivamente. Podemos ver que nuestro texto ya no se sale de la pantalla. Se mantiene dentro de la vista en la que está. Ahora podemos ver la totalidad de nuestros elementos de tarea. Nuestros iconos se han hecho un poco más grandes. Solo un cambio rápido que puedes hacer para comenzar a escalar tu texto efectivamente allí. Aquí hay algunos recursos y herramientas que pueden ayudarte a comenzar a hacer tus aplicaciones más accesibles. Comienza a probar para accesibilidad. El primero es ese React Native Accessibility Engine. Aquí hay un ejemplo rápido de cómo se ve trabajar con él.

Básicamente, esta es una herramienta que ayuda a aplicar buenas prácticas automáticamente. Se integra en tu base de código, y luego te da advertencias sobre la falta de props de accesibilidad. Es básicamente como un linter para la inclusividad.

El siguiente que quería mencionar era la prueba manual. La automatización es genial, pero la prueba manual sigue siendo la reina aquí. Usa tu aplicación de la manera en que un usuario real podría hacerlo. Habilita voiceover como acabamos de probar. Aumenta el tamaño de tu fuente como acabamos de hacer, y pruébalo con una mano mientras caminas. Esta es una muy buena manera de detectar brechas, es intentar usar tu aplicación. Intenta romperla con diferentes características de accesibilidad y trata de ponerte en los zapatos de alguien que podría estar usando estas tecnologías de asistencia de accesibilidad.

Por último, los inspectores de accesibilidad nativos. Ambas plataformas proporcionan inspectores realmente poderosos, tanto iOS como Android. Te permiten analizar la semántica de tu aplicación. Puedes auditar tu aplicación. Úsalos durante el desarrollo. De esa manera puedes detectar algunas brechas en cómo los lectores de pantalla podrían interpretar tu UI o tal vez los contrastes de color. Otro que quería agregar aquí es aprovechar la IA. La IA es enorme en este momento. Es muy poderosa. La IA puede ser un socio realmente, realmente poderoso en tus pruebas de accesibilidad.

Comienza tal vez con algunos de tus asistentes de codificación de IA como GitHub Copilot o ChachiBT Cursor, Claude. Estas herramientas pueden ayudarte a sugerir diferentes indicaciones de accesibilidad mientras codificas, como agregar esa etiqueta de accesibilidad o tal vez señalar algunos estilos codificados que afectan tu escalado. También puedes usar IA para analizar tu UI o tus componentes. Por ejemplo, podrías pedir a ChachiBT que revise un fragmento y recomiende mejoras de accesibilidad. Puede sugerir esas etiquetas semánticas, nombres de ayuda, botones sin etiquetar, o tal vez simplemente refactorizar alguna estructura deficiente. También puedes usarlo para generar esas etiquetas de accesibilidad.

También puedes traducir archivos de Figma o de diseño en código accesible. Esto realmente ayuda a los diseñadores e ingenieros a alinearse en ese proceso temprano con la incorporación de la accesibilidad en tu proceso actual. La clave es realmente usar la IA como un complemento, no un reemplazo. Aún necesitas esa empatía y esas pruebas, pero la IA puede ayudar a acelerar el camino hacia la inclusión. Aquí hay algunas cosas con las que puedes comenzar de inmediato. Dedica unos cinco minutos a usar tu aplicación con voiceover o TalkBack. Te sorprenderá lo que aprendes.

Elige tal vez solo una pantalla a la vez, aumenta el texto de tu teléfono al máximo y ve qué se rompe. Luego arréglalo. Etiqueta algunos botones. Comienza pequeño, solo tres. Se suma muy rápido. Luego, si puedes, habla con un usuario real que dependa de las funciones de accesibilidad. Pregúntales qué les frustra. Y por último, incorpora esto en tu proceso actual. Haz de la accesibilidad parte de tu definición de hecho, tu lista de verificación de QA, o incluso tu flujo de revisión de código. Si todos los que están viendo esto hicieran solo una de estas cosas, tendríamos muchas más aplicaciones inclusivas solo para el final de la semana.