Implementamos soporte de accesibilidad sin cambiar el componente visual de la aplicación móvil.

Este artículo no será una línea de código, ni un solo término complejo. Trataré de decir de tal manera que incluso una persona lejos del desarrollo lo entienda.

Se tratará de la implementación de accesibilidad (accesibilidad) en una aplicación móvil.

Breve antecedentes


Recientemente, en nombre del proyecto Accessible Life, comencé a ayudar a Yandex a implementar la accesibilidad de sus aplicaciones de navegación.

Me enfrenté al hecho de que muchas cosas que son obvias desde mi punto de vista no me vienen a la mente: elementos invisibles en la pantalla, salida directa de mensajes de voz usando la API del programa de acceso a la pantalla, etc.

Por lo tanto, decidí declarar todo esto en un artículo separado.

En general, vamos.

Artículos invisibles


El problema


En el proceso de trabajar en mapas, encontramos un problema:
Cuando haces clic en un área de la pantalla con un mapa, la aplicación debe cambiar de modo (no recuerdo los detalles con seguridad).

Para un usuario ciego con un programa de acceso a la pantalla, esta acción aparentemente simple se vuelve imposible.

El hecho es que los programas de acceso a la pantalla "ven" solo objetos específicos en la pantalla: botones, bloques de texto, campos de entrada, controles y listas. Y en la aplicación Yandex.Maps, hacer clic en el mapa no se procesó como una selección de un objeto, sino como un toque en un área específica de la pantalla.

Solución


La solución es bastante simple: hacer un botón en la pantalla sin marco, con un fondo transparente y sin texto visible (fuente cero, que no es tan estéticamente agradable desde el punto de vista del programador, o atributos especiales que muestran texto solo para programas de acceso a pantalla sin mostrarlo en la pantalla).

Este enfoque sorprendió y sorprendió a los programadores, pero en la práctica todo funcionó, la idea funcionó y se está introduciendo activamente donde sea que necesite procesar clics directos en el área de la pantalla.

Salida directa de mensajes de voz utilizando el programa de acceso a la pantalla.


El problema


Otro problema fue que a veces se requiere mostrar información adicional solo para el usuario ciego. Los mensajes emergentes en este caso estropearán el diseño e interferirán con los demás, e implementar un modo de aplicación separado en el que se mostrarán dichos mensajes es engorroso e ilógico.

Solución


La solución no es tan obvia como en el caso de los botones invisibles, pero también se encuentra en la superficie.
Debe usar la API del programa de acceso a la pantalla para mostrar los mensajes. Parece menos voluminoso en el código del programa, no obliga al desarrollador a hacer esfuerzos adicionales para crear modos separados, configuraciones adicionales, etc.

Por cierto, si usa la API del lector de pantalla, ni siquiera necesita verificar si está habilitada. Si el programa se está ejecutando, mostrará un mensaje utilizando el sintetizador de voz seleccionado por el usuario. Y si el programa está apagado, simplemente no sucederá nada, y el usuario promedio no notará nada.

Compartir


El problema


Esta es una recomendación en lugar de un truco de vida, pero estoy obligado a mencionar esto.

¿Recuerda que solo hay objetos en la pantalla para el programa de acceso a la pantalla?

Entonces, el tipo de objeto también importa. El texto no se puede hacer clic, en su opinión, pero el botón no se puede copiar. Es decir, si la tabla de configuración se implementa como un bloque de texto grande que "atrapa" clics en diferentes partes de sí misma, dicha tabla no está disponible para el programa de acceso a la pantalla. Se leerá, pero no permitirá la interacción.

Solución


La solución es bastante simple: use los elementos como se pretende.

Si debe ser una lista, debe usar el elemento que describe la lista en el código;
si es un botón, entonces debe ser el botón; Si se trata de un control deslizante, un regulador de algo, debe ser un elemento del control deslizante y no texto con animación al arrastrar.

Conclusión


En conclusión, quiero decir que el desarrollo para Windows, aunque no es esencial, es diferente del desarrollo para plataformas móviles, por lo que las características de accesibilidad para Windows difieren de las características para Android / Ios.

Source: https://habr.com/ru/post/es432756/


All Articles