Conceptos básicos de React Native A11y

May 10 2022
Una introducción rápida a la accesibilidad y cómo se puede hacer que sus aplicaciones nativas de reacción sean accesibles
ANTECEDENTES: En smallcase, queremos cambiar la forma en que India invierte. Esto comenzó con la creación de un producto de inversión fácil de entender, luego con la creación de una plataforma de ejecución técnica fácil de usar y ahora con la creación de un ecosistema de otros servicios y productos complementarios.

ANTECEDENTES:

En smallcase, queremos cambiar la forma en que India invierte. Esto comenzó con la creación de un producto de inversión fácil de entender, luego con la creación de una plataforma de ejecución técnica fácil de usar y ahora con la creación de un ecosistema de otros servicios y productos complementarios. Todavía queda un largo camino por recorrer en este viaje, pero creemos que ahora estamos en un punto en el que, desde un punto de vista tecnológico, podemos comenzar a resolver problemas para usuarios marginados y casos de uso. Esto implica cosas como un mejor soporte para Internet lento, capacidades fuera de línea cuando tengan sentido, asegurarse de que los flujos de usuarios sean accesibles para personas discapacitadas y más. Algunas de estas cosas están planeadas para ser retomadas en el futuro, algunas de ellas ya existen de alguna manera, pero necesitan ser reenfocadas.

La accesibilidad es una de esas capacidades.

Este blog habla sobre algunos de los puntos más destacados de nuestra investigación sobre accesibilidad móvil, especialmente para iOS, Android y React Native.

POR QUÉ PREOCUPARSE POR A11Y:

Si está activo en Twitter, debe haberse topado con los resultados de wordle de alguien o puede que los haya compartido usted mismo. ¡Estos tweets son bastante molestos para muchas personas, pero no por la razón que piensas!

Cuando una persona revisa su cuenta de Twitter usando un lector de pantalla, así es como se le lee una palabra.

Como puede ver, los lectores de pantalla leen una lista larga e indescifrable de "cuadrado verde", "cuadrado amarillo" y "cuadrado grande blanco" que no tiene mucho sentido sin contexto.

¿Cómo arreglamos la situación? ¡Identificando el problema y siendo más empático con las personas que enfrentan barreras tan grandes a diario cuando tratan con el mundo!

También podemos inspirarnos en desarrolladores como Josh Wardle , quien creó una herramienta llamada wa11y.co que puede usar para generar resultados de Wordle descriptivos (y accesibles) que puede compartir en su feed.

(Si estás en Reddit, también te puede interesar saber que él también es el creador de Place ).

QUE ES LA DISCAPACIDAD:

Este fue un caso de discapacidad visual en el que una herramienta facilitó la forma en que alguien consumía información, pero hay otros tipos de discapacidad que pueden dificultar la experiencia del mundo de una persona. Incluyen discapacidad auditiva, personas con problemas de movilidad y discapacidades cognitivas: personas con discapacidad intelectual o personas de la tercera edad simple y llanamente. Todos ellos se manifiestan con diferente gravedad y requieren necesidades especializadas.

El Modelo Social de Discapacidad dice que las personas están discapacitadas por las barreras de la sociedad, no por sus impedimentos y la eliminación de estas barreras crea igualdad y les ofrece independencia.

DIRECTRICES DE ACCESIBILIDAD:

Algunos países como los EE. UU. y Canadá exigen legalmente que los sitios web y las aplicaciones sean accesibles, por lo que se estableció un conjunto de pautas llamadas Pautas de accesibilidad al contenido web (WCAG) “con el objetivo de proporcionar un estándar único compartido para la accesibilidad del contenido web que satisfaga las necesidades de individuos, organizaciones y gobiernos a nivel internacional”

Las pautas de las WCAG se organizan según cuatro principios: aspectos importantes que debe tener el contenido de la web/aplicación para que se considere accesible.

Para cada directriz, existen criterios de éxito comprobables en tres niveles A, AA y AAA, donde cada uno es progresivamente más estricto.

Nivel A: no reconozca algo solo por el color: no diferencie entre un número positivo o negativo solo por un color, agregue signos positivos/negativos también

Nivel AA: el color del texto debe cumplir los requisitos de contraste de al menos 4,5:1

Nivel AAA: el color del texto debe cumplir con el requisito de contraste de 7:1 (color muy oscuro sobre un fondo muy claro que, por lo general, es difícil de cumplir)

PRINCIPIOS DE ACCESIBILIDAD:

Cualquier contenido web/móvil puede considerarse accesible si cumple con los siguientes principios generales de accesibilidad

  1. Perceptible : la interfaz de usuario y el contenido representado son perceptibles.
  2. Operable : la interfaz de usuario es operable para todo tipo de usuarios, por ejemplo, los usuarios que interactúan con un navegador web/aplicación pueden hacerlo usando uno o más métodos de entrada, incluidos el teclado, el mouse, la voz, el tacto y los gestos.
  3. Comprensible : por ejemplo, el diseño y la navegación deben ser consistentes y predecibles y proporcionar indicaciones claras de que los elementos son procesables.
  4. Robusto : el contenido debe desarrollarse utilizando estándares mundiales bien adaptados que funcionarán en diferentes plataformas, ahora y en el futuro.

Si bien los principios generales de accesibilidad son los mismos en las plataformas web y móviles, hay una diferencia en la forma en que se implementa a11y, especialmente en diferentes sistemas operativos como iOS y Android y también en aplicaciones multiplataforma creadas con React Native.

Algunos consejos rápidos para implementar a11y en aplicaciones móviles:

  1. Diseñe flujos de tareas claros y bien definidos con pasos de navegación mínimos, especialmente para las principales tareas de los usuarios, y asegúrese de que esas tareas sean navegables a través del control de enfoque
  2. Etiquete los componentes de la interfaz de usuario que no tienen texto visible
  3. Asegúrese de que los usuarios puedan navegar por los diseños de su pantalla usando controles direccionales basados ​​en hardware o software (y no solo la pantalla táctil del móvil)

De forma nativa, en Android puedes describir contenido usando android:contentDescription

Uso de descripción de contenido

Una forma en Android de vincular un campo de texto de entrada a su etiqueta sería usar android:labelFor

Usando labelFor

Los elementos se pueden hacer enfocables configurando el atributo android:screenReaderFocusable del objeto contenedor en verdadero, y el atributo android :focusable de cada objeto interno en falso.

Al hacerlo, los servicios de accesibilidad pueden presentar las descripciones de contenido de los elementos internos, uno tras otro, en un solo anuncio.

Volveremos a este punto en la sección React Native.

Implementación de a11Y en iOS

iOS tiene un conjunto integral de métodos proporcionados a NSObject, que es la clase raíz de la mayoría de las jerarquías de clases de Objective-C, de las cuales las subclases heredan una interfaz básica para el sistema de tiempo de ejecución.

  • UIAccessibility: un conjunto de métodos que proporciona información de accesibilidad sobre vistas y controles en la interfaz de usuario de una aplicación.
  • UIAccessibilityContainer: lo utilizan las subclases de View para hacer que los subcomponentes sean accesibles como elementos separados.
  • UIAccessibilityAction: un conjunto de métodos que los elementos de accesibilidad pueden usar para respaldar acciones específicas.
  • UIAccessibilityFocus: se usa para determinar si una aplicación de asistencia, como VoiceOver, se enfoca en un elemento accesible.
  • UIAccessibilityDragging: un par de propiedades que le permiten ajustar cómo arrastrar y soltar se exponen a las tecnologías de asistencia.

Si bien tanto iOS como Android proporcionan API de forma nativa para integrar aplicaciones con tecnologías de asistencia,

React Native también tiene un conjunto complementario de API que permiten que su aplicación se adapte a todos los usuarios.

Hoja de trucos de accesibilidad de React Native
  • accesible : cuando es verdadero, indica que la vista es un elemento de accesibilidad. Cuando una vista es un elemento de accesibilidad, agrupa a sus elementos secundarios en un solo componente seleccionable; como resultado, el lector de pantalla puede leer todo el contenido uno tras otro. De forma predeterminada, todos los elementos táctiles son accesibles.
  • AccesibilityRole: comunica el propósito de un componente; puede ser un botón, un enlace, etc. Sin la información de qué es este elemento , es posible que el usuario no entienda lo que puede suceder cuando se interactúa con el elemento.
  • etiqueta accesible : se utiliza para proporcionar un sentido de propósito para el elemento actual con el que el usuario está interactuando
  • AccesibilityState: describe el estado actual de un componente: deshabilitado, seleccionado, expandido. Por ejemplo, establecer un control como "deshabilitado" es cuestión de asignar el accesorio accessState con un nombre de clave de objeto de disabled y establecer su valor en true .
  • accessHint : para los elementos interactivos, la sugerencia de accesibilidad proporciona una forma de describir el resultado esperado de la interacción del usuario con el elemento. Por ejemplo, informar a los usuarios cuando hacen clic en un botón abrirá un navegador móvil en lugar de una nueva vista en la aplicación.

<TouchableOpacity
 accessibilityRole="button"
 accessibilityState={disabled: true}
    ...
>
  Submit code
</TouchableOpacity>

Indicamos que el botón actualmente no se puede accionar mediante el estado: deshabilitado.

El texto del botón indica claramente que al presionarlo se enviaría el código, pero digamos que tenía un título genérico como Enviar; entonces tendríamos que agregar una etiqueta de accesibilidad = {"Enviar código"} para informar al usuario lo que realmente lograría al hacer clic en el botón. .

PROBLEMAS COMUNES A11Y:

  • Mostrar texto como una imagen: describir una sección de su sitio web/aplicación usando solo una imagen puede verse bien, pero es muy inaccesible para los usuarios de lectores de pantalla: ¡no tendrán idea de lo que está sucediendo! Por ejemplo, una sección en la aplicación de smallcase tenía el siguiente texto como una imagen que dejaba a los usuarios en la oscuridad
  • Texto como imagen
  • Íconos como botones: De manera similar, usar íconos como botones sin agregar ningún rol/descripción haría que las acciones fueran inaccesibles. En este caso, VoiceOver solo puede leer el texto y no describir el botón.
  • Icono como botón
  • Elementos interactivos anidados : Tomemos un ejemplo de una tarjeta genérica presente en la aplicación de Smallcase que muestra información sobre un Smallcase en particular, al hacer clic en la cual se lleva al usuario al perfil de Smallcase. También incluye un icono como botón para la lista de seguimiento (seguimiento de las devoluciones) de un caso pequeño.
  • Tarjeta pequeña
Cómo lee VoiceOver la tarjeta en minúsculas

Dado que la tarjeta es un botón y los botones en React Native son accesibles de forma predeterminada, VoiceOver reunirá todas las etiquetas y el texto y lo leerá todo a la vez, presentando información engañosa de que al tocar la tarjeta se incluirá en la lista de observación el caso pequeño mientras que en realidad conducirá el usuario al perfil de smallcase. El ícono de la lista de seguimiento aquí no se puede enfocar por separado debido a que es accesible = {true}

Una forma de hacer esto es hacer que la tarjeta sea accesible = {falso} , lo que hará que todos los elementos se puedan enfocar por separado, pero una mejor manera de hacerlo será hacer que solo el encabezado de esta tarjeta sea táctil (debería llevar a la pequeña perfil) y el icono de la lista de seguimiento será enfocable.

Este es un problema clásico de los elementos interactivos anidados en todos los años, puede leer más sobre esto aquí .

  • Orden de enfoque de accesibilidad en React Native: supongamos que tiene la siguiente tarjeta en su aplicación que debe leerse en columna, en un orden particular para que tenga sentido.
  • Foto de Adam Gerthel en una edición de GitHub
Foto de un artículo de Itty Bitty Apps

Esto sucede porque mientras que en la web los lectores de pantalla determinan el flujo en el que se leen las cosas mirando el árbol DOM y yendo de arriba a abajo, no existe tal estructura en las aplicaciones móviles.

iOS lee elementos de izquierda a derecha, de arriba a abajo, lo que no es apropiado para todos los casos.

PRUEBA DE ACCESIBILIDAD DE LAS APLICACIONES MÓVILES:

Las siguientes herramientas se pueden usar para probar la accesibilidad de las aplicaciones como desarrolladores y también como usuarios reales:

herramientas a11Y en iOS

  1. Un inspector de accesibilidad que pueden usar los desarrolladores para inspeccionar los accesorios de accesibilidad de los elementos usando el botón de la cruz
  2. Inspector de accesibilidad

Herramientas A11y en Android

  1. En los desarrolladores de Android, puede usar el Escáner de accesibilidad que puede registrar flujos de trabajo/tomar capturas de pantalla de pantallas y luego auditarlas en busca de problemas de accesibilidad y proponer soluciones basadas en lo siguiente:

ii. Toque el tamaño del objetivo

iii. Elementos en los que se puede hacer clic

IV. Contraste de texto e imagen.

Captura de pantalla del Escáner de accesibilidad ejecutándose en la aplicación de smallcase

Por ejemplo, después de ejecutar el escáner en la aplicación Smallcase, recibimos las siguientes sugerencias:

Captura de pantalla de Accessibility Scanner auditando la aplicación de smallcase

Y tocando el icono de la lista de observación

nos brinda consejos sobre cómo hacer que el ícono sea accesible para los lectores de pantalla.

2. TalkBack — Lector de pantalla para Android

Si bien las herramientas proporcionadas de forma nativa por iOS y Android para probar la accesibilidad móvil son sólidas, no se puede confiar en ellas por completo. Es posible que puedan detectar cuando no proporcionamos etiquetas a los íconos, pero son incapaces de verificar si las etiquetas proporcionadas realmente tienen sentido, algo que solo puede ser probado manualmente por un ser humano.

Espero que este blog lo aliente a mirar el mundo y especialmente las aplicaciones que está creando desde una perspectiva diferente. Tal vez este sea un buen momento para comprobar cómo le parece el mundo a un usuario de un lector de pantalla y pensar en formas en las que se puede hacer más accesible.

REFERENCIAS :

  • Ejemplos de accesibilidad móvil de la referencia UAAG 2.0
  • Accesibilidad móvil: Cómo se aplican las WCAG 2.0 y otras directrices W3C/WAI a los dispositivos móviles
  • Técnicas WCAG 2.0 que se aplican a dispositivos móviles
  • a11y en android
  • a11y en iOS
  • Creación de aplicaciones nativas de React accesibles en Shopify
  • Discusión de orden de enfoque de accesibilidad de RN
  • Conceptos básicos de VoiceOver iOS
  • Prácticas indias de accesibilidad móvil
  • Hacer Wordle accesible
  • ¿Qué pueden hacer los autores de Tweets?

© Copyright 2021 - 2022 | unogogo.com | All Rights Reserved