Actualizaciones de la API de accesibilidad

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Motivación

A medida que la tecnología avanza y las aplicaciones móviles se vuelven cada vez más importantes en la vida cotidiana, la necesidad de crear aplicaciones accesibles también ha crecido en importancia.

La API de accesibilidad limitada de React Native siempre ha sido un gran punto de dolor para los desarrolladores, por lo que hemos realizado algunas actualizaciones en la API de accesibilidad para facilitar la creación de aplicaciones móviles inclusivas.

Problemas con la API existente

Problema uno: dos propiedades completamente diferentes pero similares - accessibilityComponentType (Android) y accessibilityTraits (iOS)

accessibilityComponentType y accessibilityTraits son dos propiedades que se utilizan para indicar a TalkBack en Android y VoiceOver en iOS con qué tipo de elemento de interfaz de usuario está interactuando el usuario. Los dos mayores problemas con estas propiedades son:

1. Son dos propiedades diferentes con métodos de uso distintos, pero tienen el mismo propósito. En la API anterior, estas son dos propiedades separadas (una para cada plataforma), lo que no solo era inconveniente, sino también confuso para muchos desarrolladores. accessibilityTraits en iOS permite 17 valores diferentes, mientras que accessibilityComponentType en Android solo permite 4 valores. Además, los valores en su mayoría no tenían superposición. Incluso los tipos de entrada para estas dos propiedades son diferentes. accessibilityTraits permite pasar un array de rasgos o un solo rasgo, mientras que accessibilityComponentType solo permite un único valor.

2. Existe una funcionalidad muy limitada en Android. Con la propiedad anterior, los únicos elementos de interfaz de usuario que Talkback podía reconocer eran "button", "radiobutton_checked" y "radiobutton_unchecked".

Problema dos: Pistas de accesibilidad inexistentes

Las pistas de accesibilidad ayudan a los usuarios que utilizan TalkBack o VoiceOver a comprender qué sucederá cuando realicen una acción en un elemento de accesibilidad que no es evidente solo por la etiqueta de accesibilidad. Estas pistas se pueden activar y desactivar en el panel de configuración. Anteriormente, la API de React Native no admitía pistas de accesibilidad en absoluto.

Problema tres: Ignorar colores invertidos

Algunos usuarios con pérdida de visión utilizan colores invertidos en sus teléfonos móviles para tener un mayor contraste en la pantalla. Apple proporcionó una API para iOS que permite a los desarrolladores ignorar ciertas vistas. De esta manera, las imágenes y los videos no se distorsionan cuando un usuario tiene activada la configuración de colores invertidos. Esta API actualmente no es compatible con React Native.

Diseño de la nueva API

Solución uno: Combinar accessibilityComponentType (Android) y accessibilityTraits (iOS)

Para resolver la confusión entre accessibilityComponentType y accessibilityTraits, decidimos fusionarlas en una sola propiedad. Esto tenía sentido porque técnicamente tenían la misma funcionalidad prevista y, al fusionarlas, los desarrolladores ya no tenían que preocuparse por las complejidades específicas de la plataforma al crear funciones de accesibilidad.

Antecedentes

En iOS, UIAccessibilityTraits es una propiedad que se puede establecer en cualquier NSObject. Cada uno de los 17 rasgos que se pasan a través de la propiedad de JavaScript a nativo se asigna a un elemento UIAccessibilityTraits en Objective-C. Cada rasgo está representado por un long int, y cada rasgo que se establece se combina mediante un OR.

Sin embargo, en Android, AccessibilityComponentType es un concepto inventado por React Native, y no se asigna directamente a ninguna propiedad en Android. La accesibilidad se maneja mediante un delegado de accesibilidad. Cada vista tiene un delegado de accesibilidad predeterminado. Si deseas personalizar cualquier acción de accesibilidad, tienes que crear un nuevo delegado de accesibilidad, sobrescribir los métodos específicos que deseas personalizar y luego establecer que el delegado de accesibilidad de la vista que estás manejando esté asociado con el nuevo delegado. Cuando un desarrollador establecía AccessibilityComponentType, el código nativo creaba un nuevo delegado basado en el componente que se pasaba, y establecía que la vista tuviera ese delegado de accesibilidad.

Cambios realizados

Para nuestra nueva propiedad, queríamos crear un superconjunto de ambas propiedades. Decidimos modelar la nueva propiedad principalmente siguiendo el comportamiento de la propiedad existente accessibilityTraits, ya que accessibilityTraits tiene significativamente más valores. La funcionalidad en Android para estos rasgos se implementaría mediante modificaciones en el Delegado de Accesibilidad.

Existen 17 valores de UIAccessibilityTraits que pueden asignarse a accessibilityTraits en iOS. Sin embargo, no incluimos todos como valores posibles en nuestra nueva propiedad. Esto se debe a que el efecto de configurar algunos de estos rasgos es poco conocido, y muchos de estos valores prácticamente no se utilizan.

Los valores de UIAccessibilityTraits generalmente cumplían uno de dos propósitos: describían el rol del elemento de UI o describían su estado. La mayoría de los usos observados combinaban un valor representando un rol con "state selected", "state disabled" o ambos. Por ello, decidimos crear dos nuevas propiedades: accessibilityRole y accessibilityState.

accessibilityRole

La nueva propiedad accessibilityRole indica a TalkBack o VoiceOver el rol de un elemento de UI. Puede tomar uno de estos valores:

• none

• button

• link

• search

• image

• keyboardkey

• text

• adjustable

• header

• summary

• imagebutton

Esta propiedad solo permite un valor porque los elementos de UI generalmente no asumen más de un rol lógico. La excepción son imagen y botón, por lo que añadimos el rol imagebutton que combina ambos.

accessibilityStates

La nueva propiedad accessibilityStates indica a TalkBack o VoiceOver el estado de un elemento de UI. Acepta un array con uno o ambos valores:

• selected

• disabled

Solución dos: Adición de sugerencias de accesibilidad

Añadimos una nueva propiedad accessibilityHint. Configurarla permite a TalkBack o VoiceOver leer sugerencias a los usuarios.

accessibilityHint

Esta propiedad recibe la sugerencia de accesibilidad como cadena de texto.

En iOS, configura la propiedad nativa AccessibilityHint en la vista. VoiceOver leerá la sugerencia si están activadas en el iPhone.

En Android, el valor se añade al final de la etiqueta de accesibilidad. Esto imita el comportamiento de iOS, pero con la limitación de que en Android no pueden desactivarse mediante ajustes como en iOS.

Tomamos esta decisión porque las sugerencias suelen corresponder con acciones específicas (ej. clic) y queríamos mantener coherencia entre plataformas.

Solución al problema tres

accessibilityIgnoresInvertColors

Exponemos la API de Apple AccessibilityIgnoresInvertColors en JavaScript. Ahora puedes evitar inversión de colores en vistas (ej. imágenes) configurando esta propiedad como true.

Nuevo uso

Estas propiedades estarán disponibles en React Native 0.57.

Cómo actualizar

Si actualmente estás usando accessibilityComponentType y accessibilityTraits, estos son los pasos que puedes seguir para migrar a las nuevas propiedades.

1. Usando jscodeshift

Los casos de uso más simples pueden reemplazarse ejecutando un script de jscodeshift.

Este script reemplaza las siguientes instancias:

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

Con

accessibilityRole= “trait”

Este script también elimina instancias de AccessibilityComponentType (asumiendo que donde sea que configuraste AccessibilityComponentType, también configuraste AccessibilityTraits).

2. Usando un codemod manual

Para los casos que usaban AccessibilityTraits sin un valor correspondiente en AccessibilityRole, y los casos donde se pasaban múltiples rasgos en AccessibilityTraits, se requiere un codemod manual.

En general,

accessibilityTraits= {[“button”, “selected”]}

se reemplazaría manualmente con

accessibilityRole=“button”
accessibilityStates={[“selected”]}

Estas propiedades ya están siendo utilizadas en la base de código de Facebook. El codemod para Facebook fue sorprendentemente simple. El script de jscodeshift corrigió aproximadamente la mitad de nuestras instancias, y la otra mitad se corrigió manualmente. En general, todo el proceso tomó menos de unas pocas horas.

¡Esperamos que encuentres útil la API actualizada! Y por favor, ¡sigan haciendo aplicaciones accesibles! #inclusion