🍸 👇🏾 🥤 Cómo realizamos pruebas de accesibilidad en Alfa Digital ☝🏾 🔮 🚿

Los productos digitales no solo deben ser hermosos, convenientes y rentables, sino también accesibles para personas con discapacidades. Esto es más importante de lo que parece a primera vista. A veces, esto debe transmitirse a la empresa, a los propietarios de productos y a los colegas directos. Pero luego resulta llevar su producto a un nuevo nivel. Estamos con un desarrollador senior de iOSfamilkoCuéntanos sobre nuestra experiencia.

Alfa-Bank forma parte de un grupo de trabajo especial creado por el Banco Central con el objetivo de mejorar la calidad de los productos financieros para grupos con discapacidad visual. Ya se ha desarrollado una metodología especial de trabajo y evaluaciones, a la que se adhieren todos los bancos.

Y así es como lo probamos.

Usuarios y escenarios

En primer lugar, invitamos a personas con discapacidad visual (de diferentes grupos) a realizar una prueba.

El primer grupo de discapacidades visuales son las personas completamente ciegas que se ven obligadas a usar dispositivos y software especiales (lectores de pantalla, VoiceOver).

El segundo y el tercer grupo tienen discapacidades visuales, que, según la enfermedad, usan dichos dispositivos o se manejan con éxito sin ellos.

Sí, es importante tener en cuenta que cuando realice cualquier prueba, cuyo resultado será la finalización o incluso el procesamiento de la aplicación completa o sus funciones individuales, no le hará daño transmitir su necesidad a la empresa. Porque también cuesta, tiempo, esfuerzo. Aquí resulta una historia tal que, por un lado, tales acciones para las personas con discapacidad visual son responsabilidad social de la empresa, por otro lado, como muestran las estadísticas, hasta el 30 por ciento de la población del país puede experimentar dificultades temporales con la visión en diferentes situaciones, y esto ya Figura impresionante.

Por lo tanto, nos reunimos y nos sentamos a probar con ellos los cuatro escenarios más populares para usar Alpha Mobile. Aquí están:

autorización de solicitud
control de saldo
ver sus cuentas (historial, estado)
recarga de cuenta móvil

Por supuesto, dependiendo de una persona en particular, los escenarios pueden ser diferentes: alguien a menudo paga los servicios de vivienda y comunales utilizando un código QR, alguien transfiere dinero a sus familiares, pero los más comunes son estos cuatro.

Métodos de prueba y herramientas

Existe un GOST R 52872-2012 especial , "Requisitos de accesibilidad para personas con discapacidad visual", que describe todos los estándares con suficiente detalle. Eso es lo que usamos, asignando a cada error encontrado una etiqueta correspondiente. En total, todos los problemas encontrados se dividieron en tres categorías.

Problema de diseño Por ejemplo, en la entrada del banco móvil, esta es la ventana habitual para que todos ingresen el código PIN, no tiene foco en el campo de entrada y la persona no dice en voz alta cuántos intentos tiene para ingresar el PIN.

Así fue con nosotros. Suena como un problema regular, pero esto es algo crítico. Si una persona no puede escuchar si ingresó el pin correctamente o no, cuántos intentos le quedan, entonces puede exceder este número de intentos. Esto significa que la entrada a Alfa Mobile se bloqueará temporalmente con todos los inconvenientes resultantes.

Problema de calidad del código. Esto es cuando no todos los elementos que pronuncia correctamente. Por ejemplo, en algunos lugares las flechas de navegación se pueden expresar como "Fin de la tabla" y piezas similares del sistema.

El problema del contraste. Por ejemplo, aquí, incluso con visión normal, es difícil leer el texto. Debe deshacerse de esto y tener esto en cuenta de inmediato.

"
Hubo cuatro pasos principales en nuestro trabajo:

Reunió a un grupo de evaluadores (7 personas) y regresó la solicitud
Separado de las ramas de desarrollo, analizó problemas y elementos.
Los escribieron en un plato, priorizaron
Crítico comenzó a editar

Las pruebas realmente ayudan al enfoque de Apple para crear productos. En primer lugar, es realmente conveniente probar todo directamente en el dispositivo, los cupertinianos han adaptado todo genial.

En segundo lugar, hay Xcode con su inspector de accesibilidad, esta utilidad muestra una vista específica de botones y elementos cuando pasa el mouse sobre la pantalla, puede leer todo rápidamente y comprender si se expresará correctamente. En realidad, en nuestro caso, este era el problema principal: firmar botones para VoiceOver.

Encontramos defectos al evaluar la funcionalidad y la conveniencia de una aplicación móvil que utilizan las personas con problemas de visión. La evaluación se lleva a cabo probando el paso de todos los escenarios básicos del usuario.

Cuantos más escenarios de usuario básicos estén disponibles para el cliente y menos barreras y dificultades identificadas durante la aprobación del guión, mayor será la calificación.

El nivel de disponibilidad del script está determinado por el problema más crítico.

critical recibe un escenario en el que se detecta un problema de disponibilidad crítico que no permite que la tarea se complete en absoluto.
minor recibe un escenario en el que se detectan problemas de accesibilidad de criticidad media cuando los usuarios experimentan dificultades significativas para completar la tarea.
low recibe un escenario en el que se detectan problemas de disponibilidad de baja criticidad cuando los usuarios experimentan alguna dificultad para completar una tarea.

¿Cómo evitar defectos de accesibilidad?

Primero, use el protocolo del elemento de accesibilidad de la interfaz de usuario.

Luego, debe mejorar la Voz en off (una función especial de Makoshi que ayuda a un usuario con discapacidad visual a trabajar con comandos de voz y un teclado):

Firmar botones.
Agregar valores
Deja una pista
Controles grupales.
Corregir las inscripciones incorrectas.
Indique el tipo de control: botón, inscripción, enlace, etc.
Extienda botones o elementos si son demasiado estrechos (mínimo 44: 44)

Esto es lo que recomendamos: 1. Botones - .accessibilityLabel

Cada botón debe tener un nombre corto y resonante. VoiceOver cubrirá, si lo olvida, intentará leer el texto o el nombre del icono en el botón.

Lo que necesitas firmar:

Botones con un icono, pero sin texto;
Imágenes Si es posible, es mejor firmar lo que se muestra en la imagen.
Un botón y una imagen sin etiqueta expresan el nombre del icono, como en Activos

2. Valores - .accessibilityValue

Además del nombre, puede escribir un valor. Por ejemplo, al ingresar la cantidad de dinero con textField, debe firmar el nombre de la cuenta o el final digital, y también indicar la cantidad de rublos.

3. Consejos - .accessibilityHint

Si queremos aclarar más la acción, podemos escribir una pista en .accessibilityHint. Pero no debe depender en gran medida de las indicaciones: las explicaciones constantes le molestan, por lo que algunos usuarios las desactivan a través de la configuración del teléfono.

El botón se expresa como "A otro banco", para explicación, puede dejar una pista, qué tipo de transferencia, qué tan rápido, etc.

4. Controles de grupo - .accesibilidad

Por defecto, cada elemento se habla por separado. Esto es inconveniente: las zonas de presión se reducen, es posible que no note algo, por lo que debe generalizar.

Ahora la celda tiene varios campos: tarjeta, dinero y nombre, 3 controles por celda. Es necesario generalizar que había 1 celda y un nombre, por lo que resulta más cercano al significado.

¿Como arreglarlo?

Haga que toda la celda sea accesible. Por defecto, todas las vistas son solo contenedores para otros elementos; VoiceOver los ignora. Para marcar la vista como un elemento final, debe establecer la celda isAccessibilityElement = true.
Dale un nombre a la celda. Ya no puede centrarse en la etiqueta, por lo que debe especificar manualmente el texto. accessibilityLabel = specialOffer.title

Puedes simplificar:

Haga que toda la celda sea accesible. Establecer la celda isAccessibilityElement = true
En accessibilityLabel, escriba lo más importante: el nombre de la tarjeta y la cuenta. Separado por una coma, VoiceOver tiene en cuenta la puntuación.
En accessibilityValue especificamos información adicional, en nuestro caso esto es qué cuenta, cuánto dinero.
Indique que se puede presionar la celda, es decir Esto es esencialmente un botón. accessibilityTraits = .button

Total

Los rangos de USABILITYLAB nos dieron el primer lugar en términos de disponibilidad de la aplicación. Esto no significa que seamos tan geniales y hayamos cerrado todos los problemas en general, convirtiéndonos en una aplicación ideal, no. Pero estamos trabajando en ello, teniendo en cuenta todas las sutilezas y características de trabajar con personas que tienen problemas de visión.

También es muy bueno que esta historia nos haya ayudado a atraer a esas personas: a menudo nos envían comentarios, y varios de los encuestados ahora ayudan a probar Alfa Mobile de forma continua.

Trabajamos más

Cómo realizamos pruebas de accesibilidad en Alfa Digital

Usuarios y escenarios

Métodos de prueba y herramientas

¿Cómo evitar defectos de accesibilidad?

Total

More articles: