Por Elbrinner hace 3 años, 3 meses, 17 días, 4 horas, 13 minutos

Introducción

En algún momento de nuestra vida, vamos a necesitar soluciones accesibles para mantener nuestro estilo de vida. Yo desde hace 8 meses, soy padre y desde este momento mi libertad de movimiento cambio… ahora, siempre que estoy con la pequeña necesito planifica a donde voy y como haré para llegar, ya que pequeños problemas como la falta de ascensor, falta de transporte apropiado, me impactan directamente a donde puedo ir o no.

Una de las cosas buena de la tecnología, es que nos permite crear solucionas accesible para todos, independientemente de sus capacidades técnicas, cognitivas o físicas. Sí tenemos la tecnología a nuestro favor, además de las leyes que obligan a las empresas a cumplir determinados niveles de accesibilidad, me pregunto:

¿Por que la accesibilidad sigue siendo un tema de poca importancia en el software cuando nos impacta a todos en algún momento de nuestra vida?

Hoy en día, todos los principales sistemas operativos tienen herramientas de accesibilidad maduras, que permite la mayoría de los usuarios tener acceso a la información sin mayores problemas.

Partiendo de la base anterior que los sistemas operativos ya hacen su trabajo, debemos enfocar en los siguientes puntos para que nuestro producto sea accesible:

Que el equipo de UX y usabilidad tenga en cuenta los requisitos de accesibilidad desde el momento 0 al crear la interfaz del producto.
Que los programadores usen en la medida del posible, los componentes ya definido por sistema, en caso de crear componentes customizados, que aplique los atributos de accesibilidad disponible en cada sistema.
Que los programadores sepan usar de forma adecuada los atributos de accesibilidad, de nada sirve usar los atributos de accesibilidad indicando que un botón es un botón, eso ya lo hace el sistema operativo y no aporta ningún valor al usuario, además las descripciones deben ser cortas y precisas.
En caso de componentes poco accesibles como los gráficos, debemos aportar siempre una alterativa accesible para el usuario, en este caso, una tabla que represente los valores puede ser suficiente.
Realizar pruebas de accesibilidad, teniendo en cuenta las diversas casuísticas.

Considerando todo lo anterior, en esencia, una aplicación móvil puede ser considerada accesible cuando cualquier usuario, independientemente de su diversidad funcional, puede utilizarla en su dispositivo móvil satisfactoriamente con su sistema de acceso habitual.

Un 84% de las personas con discapacidad afirma que las Nuevas Tecnologías han mejorado su calidad de vida global.

Sobre Accesibilidad

Las personas con discapacidad pueden presentar una amplia gama de habilidades y necesidades muy heterogéneas, dependiendo de la naturaleza de la discapacidad y del grado de afectación. Para que una aplicación sea accesible, ésta debe cubrir todas las necesidades que un usuario pueda requerir, desde aquellos con dificultades sensoriales a los que presentan problemas cognitivos o motores. Por tanto, las aplicaciones deben satisfacer los requisitos propios de perfiles de lo más diversos, incluyendo el de aquellas personas que pueden experimentar ciertos procesos adversos, como convulsiones, al hacer uso de las mismas.

Imagen que muestra los 3 tipos de discapacidad: sentorial, motora y cognitiva

Sensorial
- Discapacidad visual
- Discapacidad auditiva
- Daltonismo
- Entre otros
Motora
- Lesión por esfuerzo repetitivo
- Debilidad física
- Trastornos neurológicos
- Movimientos involuntarios
- Falta de coordinación
- Parálisis
- Limitación de las sensaciones
- Problemas de articulaciones
- Falta de miembros
- Entre otros
Cognitivo
- Perdida de memoria
- Trastorno por déficit de atención
- Dislexia
- Entre otros

Discapacidad sensorial

Los usuarios con discapacidad sensorial presentan dificultades o imposibilidad para percibir la información de salida ofrecida por el dispositivo utilizado, a través de uno o varios canales o sentidos. No obstante, esta falta de información también puede influir en la entrada, dependiendo del caso.

Las personas invidentes no pueden acceder al canal visual, mientras que aquellas que presentan dificultades en la visión, ya sea baja visión, daltonismo o cualquier otro trastorno relacionado con la vista, pueden hacerlo siempre y cuando se cumplan ciertas condiciones.

Ofrecer la información de forma alternativa, mediante el canal sonoro o háptico, puede ser una buena solución para estos casos, aunque también se pueden adoptar medidas para que el canal visual sea apropiado si el usuario cuenta con alguna capacidad visual. El tamaño del texto y los elementos, así como el contraste, son fundamentales para garantizar la accesibilidad para estos perfiles concretos de discapacidad visual.

Otro grupo afectado por la discapacidad sensorial es el de las personas con discapacidad auditiva. En este caso, los usuarios no pueden captar información a través del oído, o lo hacen con dificultad. Esto complica el hecho de que puedan mantener una conversación hablada, escuchen mensajes, utilicen componentes multimedia (como audios o vídeos) o reciban notificaciones sonoras. Por consiguiente, las aplicaciones deben plantear alternativas visuales o hápticas para transmitir la información, en lugar de utilizar el canal auditivo. Además, en muchos casos los problemas auditivos están relacionados con problemas del habla, por lo que la entrada de voz no es un medio de interacción adecuado.

También existen formas de discapacidad que afectan al sentido del tacto, evitando que el usuario pueda sentir los estímulos mecánicos, como la vibración del dispositivo. Aunque este canal no es tan importante a la hora de transmitir información, hay que tener en cuenta que cualquier notificación que se haga llegar por esta vía debe contar con alternativas.

Discapacidad motora

Otro de los grandes grupos de usuarios que encuentran barreras a la hora de interactuar con los dispositivos móviles es el de aquellos que presentan alguna clase de discapacidad que les impide o dificulta el movimiento, la aplicación de fuerza o el uso de varios gestos simultáneos.

En esta categoriá existe una enorme variedad de casuísticas, desde los casos más severos, que implican la incapacidad de mover los brazos o las manos (o directamente la ausencia de éstos), hasta aquellos en los que el movimiento está limitado o entorpecido, de forma que no se pueden realizar gestos complicados (o varios simultáneamente) o aplicar fuerza.

Como puede apreciarse, los perfiles de discapacidad motora presentan dificultad sobretodo en relación al canal de entrada, ya que los dispositivos mo?viles se centran en la interacción táctil con la pantalla o en la pulsación de teclas. Para poner a disposicio?n de estos usuarios las aplicaciones móviles, deben ofrecerse alternativas de entrada más simples, en caso de que sean complejas, e incluso abogar por la interacción mediante comandos de voz.

Discapacidad cognitiva

Por último tenemos el grupo de usuarios que presentan discapacidad cognitiva. Quizás éste sea el perfil más heterogéneo, pues, a pesar de que se disponen de clasificaciones aceptadas para las diversas patologías que la provocan, el grado de severidad varía mucho de unos

individuos a otros. No obstante, en general, estos usuarios presentarán dificultades a la hora de comprender o aprender el funcionamiento de la aplicación.

La principal herramienta que podemos utilizar para lidiar con estas barreras es la simplicidad en el manejo. Cuanto más sencilla, intuitiva, consistente y uniforme sea una aplicación móvil a lo largo de todas sus vistas, más fácil les será de utilizar a las personas afectadas por esta clase de discapacidad. Por tanto, hay que evitar términos enrevesados, instrucciones complejas o navegaciones excesivamente largas y retorcidas.

Normativa vigente

Desde el día 21 de diciembre de 2018, el estándar a cumplir por las Administraciones Públicas españolas en sus sitios web es el EN 301 549 V2.1.2 (2018-08). En el caso de las aplicaciones móviles aplicará a partir del 23 de junio de 2021. Haga clic aquí para conocer más detalles.

La norma europea EN 301 549 v2, se basa en gran medida a las pautas y criterios de la conformidad WCAG 2.1.

Estas medidas se aplican a:

Los sitios web y aplicaciones para dispositivos móviles que reciban financiación pública para su diseño o mantenimiento.
Los sitios web y aplicaciones para dispositivos móviles, vinculados a la prestación de servicios públicos, de entidades y empresas que se encarguen, ya sea por vía concesional o a través de otra vía contractual, de gestionar servicios públicos, en especial, los que tengan carácter educativo, sanitario, cultural, deportivo y de servicios sociales.
Los sitios web y aplicaciones para dispositivos móviles de los centros privados educativos, de formación y universitarios sostenidos, total o parcialmente, con fondos públicos.

La información completa esta publicada en el BOE, hace clic aquí para ver.

API Xamarin Forms

Xamarin.Forms cuenta con una API de accesibilidad que cubre muchos de los problemas de accesibilidad que pueden existir en una aplicación. Vamos a ver en detalle que podemos hacer, la API cuenta con 4 propiedades que debemos agregar en los controles mediante XAML o C#.

AutomationProperties.HelpText
AutomationProperties.IsInAccessibleTree
~~AutomationProperties.LabeledBy~~
AutomationProperties.Name

HelpText: Utilizamos para orientar al usuario lo que vamos hacer.

IsInAccessibleTree: Permite indicar si un elemento será usado por el lector de pantalla o no.

LabeledBy: Permite que otro elemento visual defina información de accesibilidad. No hace nada en IOS.

Name: Permite indicar al usuario el nombre del elemento para el lector de pantalla.

Ahora que ya conocemos lo que hace la API de Xamarin.Forms, a continuación, voy a contar mi experiencia y los puntos principales a tener en cuenta para que tu aplicación sea accesible.

El primero punto, es que tenga leído el texto anterior para entender las diversas casuísticas que tenemos que tener en cuenta, una vez superado esta parte, vamos por la practica.

Textos

El diseño, el tamaño de los elementos y los colores es la base que necesitamos para empezar. Vamos a ver algunos problemas relacionado con esto.

Problemas de constate:

Imagen con texto con poco contraste

Al usar la herramienta Test accesibilidad de Android, recebemos la siguiente notificación.

La relación de contraste del texto del elemento es 4,26. Esta relación se basa en un color de primer plano estimado de #5A7B99 y un color de fondo estimado de #FAFAFA. ¿Por qué no utilizas una relación de contraste superior a 4,50 para textos de pequeño tamaño o a 3,00 para textos de gran tamaño.

Si tienes buena visión, es fácil asumir que todas las personas perciben el color o la legibilidad del texto de la misma manera que tú — pero, por supuesto, eso no es real.

Como puedes imaginar, algunas combinaciones de colores que a algunas personas les resultan fáciles de leer les resultan difíciles o imposibles a otras. Esto se suele reducir a color contraste, la relación entre la luminosidad de los colores de primer plano y de segundo plano. Cuando los colores son similares, la relación de contraste es baja. Cuando son diferentes, la relación de contraste es alta.

Imagen con comparaciones de contraste en los textos

Se recomiendan una relación de contraste (mínima) AA de 4.5:1 para todo el texto. Se hace una excepción para texto muy grande (120 a 150% más grande que el texto de cuerpo predeterminado), para el que la relación puede disminuir a 3:1.

Evitar el tamaño fijo en las fuentes:

Uno de los problemas más frecuentes, es no respetar lo que el sistema operativo ya hace por nosotros a nivel de accesibilidad. Cuando agregando el tamaño de la fuente fijo, estamos pisando las preferencias de los usuarios.

Label con tamaÃƒÂ±o fijo en XAML

Al cambiar la configuración en accesibilidad, no va a sufrir ningún cambio, porque hemos puesto los valores como fijo y fijo, se quedan.

ConfiguraciÃƒÂ³n de accesibilidad en IOS, al aplicar un tamaÃƒÂ±o grande, no se aplica si el tamaÃƒÂ±o de la fuente estÃƒÂ¡ fijo.

En lugar de usar tamaños fijos, se recomida usar los estilos base ya definidos en Xamarin.Forms.

También se puede aplicar el tamaño de la fuente según los valores disponible en el sistema.

Ejemplo:

Fuente con valores de la interfaz de Xamarin.Forms. No usa valores fijos.

Parece fácil verdad, hay un pero, cada sistema operativo implementa el tamaño y los estilos de una forma diferente.

Los mismos estilos se ver de la siguiente forma:

Estilos del sistema, se ver de forma muy distintas

Como se puede apreciar en la imagen superior, son muy distintos para IOS, Android y UWP.

Con el tamaño definido en los sistemas, pasa algo parecido, actualmente hay 9 valores disponibles como se puede ver en la imagen de abajo:

Miembro	iOS	Android	UWP
`Default`	16	14	14
`Micro`	11	10	15.667
`Small`	13	14	18.667
`Medium`	16	17	22.667
`Large`	20	22	32
`Body`	17	16	14
`Header`	17	96	46
`Title`	28	24	24
`Subtitle`	22	16	20
`Caption`	12	12	12

No transmitas información solo con color

Existen alrededor de 320 millones de usuarios con deficiencia de visión en color. Alrededor de 1 de 12 hombres y 1 de 200 mujeres tienen alguna forma de "daltonismo", lo que significa que alrededor de 1 de cada 20, o el 5%, de tus usuarios no verán tu sitio en la forma que deseas. Cuando confiamos en el color para transmitir la información. Ejemplo:

Muchas veces indicando con color verde, algo que está bien y en rojo cuando está mal. Es importante que está información sea transmitida de otra forma, además de los colores.

Imágenes y botones:

Los botones deben tener un tamaño suficiente para que cualquier usuario pueda activarlo sin problema. El tamaño mínimo de objetivo táctil recomendado es de alrededor de 48 píxeles independientes del dispositivo. Por ejemplo, a pesar de que un ícono tenga un ancho y un alto de 24 px, puedes usar relleno adicional para llevar el tamaño del objetivo de presión a hasta 48 px. El área de 48x48 píxeles corresponde a alrededor de 9 mm, que es alrededor del tamaño del área de la yema del dedo.

Los objetivos táctiles también deberían tener un espacio de alrededor de 8 píxeles de separación, en orientación horizontal y vertical, de manera que el dedo del usuario, al presionar un objetivo de presión, no toque intencionalmente otro objetivo de presión.

La imagen debe tener como minimo 48px de ancho y de altura.

Botones con imágenes usando TapGestureRecognizer

De forma predefinida, el lector de pantalla ignorar este elemento. Para que esto no ocurra, debemos agregar los atributos AutomationProperties en la imagen para decir que se debe tener en cuenta y lo que es. Ejemplo en la imagen.

Agregando las propiedades de Xamarin Forms en una imagen, para que funciona como botÃ³n.

Me falta algo más para una experiencia completa con Xamarin.Forms

Imaginemos que tenemos una zona o varias zonas de nuestra App cuyo contenido se añade, elimina, actualiza o modifica sin intervención del usuario. Es lo que llamamos una live region, una zona viva de la aplicación. Infelizmente, Xamarin.Forms no lo implementa, pero tenemos la suerte de tener acceso a las API nativa de cada plataforma.

Vamos a verificar como funciona en los distintos sistemas, empezando por el HTML5.

HTML5, hace uso de WAI-ARIA, que no deja de ser propiedades que van dentro de las etiquetas HTML, que informa el lector de pantallas sobre las actualizaciones en las live region.
Android, funciona similar al HTML5, se debe agregar las propiedades especificas de accesibilidad en el código XML del control.
UWP, similar a Android y HTML5, hace uso de propiedades en el XAML del control.
IOS, se debe usar el método postNotification, está solución es muy distinta a los demás sistemas.

Aquí tenemos un pequeño problema, como IOS lo hace de forma tan distinta, no podemos extender los controles, porque no seria suficiente para IOS. Por otro lado, no existe ningún método similar a “postNotification” en Android y UWP, si existe, yo no conozco.

Antes de continuar, quiero explicar porque creo fundamental implementar las live region.

Cuando enviamos los datos al servidor, esta operación puede tardar, en este caso considero necesario indicar al usuario que estamos haciendo, para que tenga en cuenta que está operación puede tardar unos segundos. De forma visual se ver claro que la aplicación está realizando algo con el componente de progreso entre otros, pero al usar el lector de pantalla, no llega ninguna información extra al usuario.
Cuando actualizamos los valores de una lista, considero fundamental indicar al usuario que los datos ya fueran cargados. Es el mismo caso que el anterior, la mayoria de las aplicaciones permiten actualizar la lista haciendo uso del evento "Pull To Refresh", en Xamarin Forms cuando la operación empieza o finaliza, no indica de ninguna forma al lector de pantalla.

Tengo un "prototipo de solución" para estos casos. No es una solución definitiva, pero es mejor que nada de cara al usuario hasta encontrar un solución mejor.

Lo que vamos hacer, es definir un servicio para verificar si el lector de pantalla esta activado, si esta activado vamos enviar un texto en las acciones que queremos notificar al lector de pantalla.

Lo primero es crear la interfaz que vamos a usar en Core.

public interface IAccessibility
{
  void PostVoiceOver(string textToSpeak);
  bool IsVoiceOverRunning();
}

En siguiente paso es implementar en plataforma:

IOS:

[assembly: Dependency(typeof(Accessibility))]
namespace AccesibilidadDemo.iOS.Services
{
    public class Accessibility : IAccessibility
    {
        [DllImport(Constants.UIKitLibrary, EntryPoint = "UIAccessibilityPostNotification")]
        public extern static void PostNotification(uint notification, IntPtr id);

        public void PostVoiceOver(string textToSpeak)
        {
            PostNotification(1008, new NSString(textToSpeak).Handle);
        }

        public bool IsVoiceOverRunning()
        {
            return UIAccessibility.IsVoiceOverRunning;
        }
    }
}

Android:

[assembly: Xamarin.Forms.Dependency(typeof(Accessibility))]
namespace AccesibilidadDemo.Droid.Services
{
    public class Accessibility : IAccessibility
    {
        Context context = Forms.Context;

        public bool IsVoiceOverRunning()
        {

            AccessibilityManager am = (AccessibilityManager)Android.App.Application.Context.GetSystemService(Context.AccessibilityService);
            if (am != null & am.IsEnabled)
            {
               var serviceInfoList = am.GetEnabledAccessibilityServiceList(FeedbackFlags.Spoken);
                if (serviceInfoList!=null)
                    return true;
            }
            return false;
        }

        public void PostVoiceOver(string textToSpeak)
        {
            Toast.MakeText(context, textToSpeak, ToastLength.Short).Show();
        }
     
    }
}

Como se puede apreciar, en el caso de android estoy enviando un Toast. La idea, es enviar solo si el lector de pantalla está activo, de esta forma logramos el comportamiento esperado sin molestar a los usuarios, que sí ver la pantalla.

Herramientas de apoyo

Por último, recomiento el uso de 2 aplicaciones que puede ayudar en la construción.

Funkify

Te ayuda a ponerte en el lugar de un usuario con problemas de accesibilidad.

Se puede instalar el programa para hacer las simulaciones en el enlace de abajo.

http://www.funkify.org/

Test de Accesibilidad

Test de Accesibilidad escanea la pantalla en la que te encuentras y te sugiere mejoras en la accesibilidad de tu aplicación. Para ello, se tienen en cuenta los siguientes factores: