Caso de estudio: PsicoBienestar

Descripción general

El día 28 de marzo EsAccesible realizó una auditoría de accesibilidad en 3 páginas del sitio PsicoBienestar y creamos un informe de accesibilidad.

Encontramos 28 problemas en violación a 11 criterios de conformidad de las pautas de accesibilidad para el contenido web 2.1 nivel de conformidad AA. Esto sin contar los problemas que consideramos mejores prácticas.

En el informe los hallazgos están organizados por categorías y cada problema contiene la siguiente información:

• Título y código: nombre del problema acompañado de un código para que sea más fácil referenciar los problemas.
• Imagen: captura de pantalla mostrando donde ocurre el problema.
• Resumen informativo:
  • Impacto: severidad del problema categorizado en bajo, medio y alto.
  • Páginas afectadas: páginas afectadas por el problema,
  • Plataforma: donde se puede reproducir el problema.
• Descripción: descripción detallada del problema.
• Recomendación: descripción detallada de cómo resolver el problema. Incluyendo muestra de código de ser necesario.
• Estándares relevantes: criterios de conformidad de las pautas de accesibilidad que sean relevantes al problema.

Metodología

La metodología usada para el informe de accesibilidad incluye una prueba automática, pruebas manuales y una inspección del código. Las siguientes herramientas y aplicaciones fueron usadas en las pruebas:

• Navegadores de escritorio: Chrome, Safari
• Navegadores de dispositivos móvil: Safari
• Tecnología de asistencia: NVDA, VoiceOver, Windows con alto contraste
• Herramientas: Colour contrast analyser, Axe DevTools, HeadingsMap, bookmarklets

A continuación haremos un resumen de los problemas encontrados.

Prueba automática

Las pruebas automáticas son un excelente primer paso. Te permiten escanear una página rápidamente, pero es importante tener en cuenta que la cantidad de errores de accesibilidad que pueden encontrar son limitados.

Existen muchas de estas herramientas, nosotros usamos una que se llama Axe DevTools. Esta herramienta se puede instalar como una extensión de navegador y te permite escanear una página abriendo la herramienta para desarrolladores en Google Chrome.

Después de escanear cada página verificamos el error manualmente, y determinamos si no se trata de un falso positivo.

Pruebas manuales

Estructura y semántica

Hacemos una revisión del código y revisamos entre otras cosas el uso correcto de puntos de referencia, código semántico, asociaciones programáticas, estados, encabezados, tablas, botones.

Usamos la extensión de navegador llamada HeadingsMap para revisar el orden de los encabezados.

Imágenes y contenido no textual

Es importante que exista un método que transmita el mismo propósito y la misma información en formato de texto. Revisamos entre otras cosas imágenes, imágenes accionables, imágenes de texto, íconos. Determinamos cuales son informativas o decorativas y verificamos si están representadas en texto.

Etiquetas y nombre accesible

Las etiquetas en controles de formulario deben ser visibles, descriptivas y estar en proximidad cercana. Enlaces, botones y componentes de interfaz deben tener un nombre accesible que describa su propósito.

Teclado y foco

Es importante que la funcionalidad de un sitio no dependa únicamente del uso de un mouse, sino que también sea operable usando un teclado. Personas con baja visión, ciegas o con discapacidad motora necesitan otro dispositivo de entrada como un teclado o emuladores que actúan como teclados. Es por esto que es esencial que toda la funcionalidad del sitio también pueda ser usada con un teclado.

Para que una persona pueda interactuar con el sitio usando el teclado es además necesario que los elementos interactivos tengan un foco claramente visible, de lo contrario no es posible identificar qué elemento se encuentra enfocado.

Verificamos manualmente que los elementos interactivos puedan ser usados con un teclado, que tengan un foco claramente visible y que el orden de este sea correcto.

Contraste

Asegurarnos que exista suficiente contraste de color entre texto y fondo ayuda a las personas con discapacidad visual a leer el contenido. Las pautas de accesibilidad para el contenido web (WCAG) establecen una relación de contraste mínima para estos casos de 4.5:1 y 3:1 para texto grande.

Sin embargo, no todo el contenido es texto, por eso en su versión 2.1 WCAG añadió un criterio de conformidad que aborda el contraste de color en elementos de interfaz. Esto para asegurar que personas con baja visión también perciban contenido que es considerado importante para entender cierta información, pero que no necesariamente está en formato de texto. El criterio establece que elementos de interfaz y objetos gráficos esenciales para entender el contenido deben tener una relación de contraste de 3:1 con colores adyacentes.

Otro requisito que tenemos que tener en cuenta en relación al uso de colores es el no usarlos como el único medio para transmitir información. El motivo es que hay personas con deficiencias en la percepción del color y tienen problemas en distinguir colores.

Revisamos texto, elementos de interfaz, foco, objetos gráficos utilizando la herramienta Colour Contrast Analyser y verificamos si cumplen con los requisitos.

Windows con alto contraste

El sistema operativo Windows incluye una opción para mejorar la legibilidad a través de un modo de alto contraste. Al activarlo, es posible elegir entre distintas temáticas de alto contraste usando una cantidad de colores limitados.

Si un sitio no está optimizado para funcionar con el modo de alto contraste de Windows, es normal encontrarse con distintos problemas como elementos, íconos, imágenes y focos invisibles o estados activos que no se logran distinguir.

Revisamos el sitio en modo de alto contraste en Windows y verificamos si está funcionando correctamente. Esto no es un requisito en las pautas de accesibilidad para el contenido web, pero lo consideramos una buena práctica ya que ayuda a personas con baja visión o con deficiencia en la percepción del color y les da una opción más legible a nivel de sistema operativo. Como no forma parte de los estándares de WCAG, en el informe de accesibilidad lo agregamos en una sección aparte de mejores prácticas.

Zoom y ajustes de texto

Personas con baja visión pueden hacer uso del zoom del navegador para ver mejor el contenido. También pueden ajustar el espaciado del texto para mejorar su experiencia de lectura. Es importante que estas opciones estén disponibles sin que exista pérdida de contenido o desplazamiento en múltiples direcciones.

Hay que también tener cuidado con el uso del posicionamiento fijo en elementos ya que esto puede hacer más difícil leer e interactuar con el contenido al hacer zoom.

Utilizamos un bookmarklet para comprobar que se pueda ajustar el espaciado de texto sin que exista pérdida de contenido.

Verificamos que no exista pérdida de contenido al hacer zoom y que elementos con posicionamiento fijo no cubran gran parte de la pantalla debido a que esto dificulta la navegación o puede esconder el foco visible de un elemento interactivo. Somos rigurosos con probar en los niveles de zoom según las pautas de accesibilidad, pero entendemos que WCAG tiene limitaciones y por lo mismo de todas formas documentamos y explicamos en una sección aparte como resolver malas prácticas que no necesariamente son consideradas un fallo a las pautas.

Lector de pantalla

Usamos distintos lectores de pantalla tanto en computadores de escritorio como en dispositivos móviles y verificamos que se pueda navegar e interactuar correctamente con los elementos de interfaz. Vemos entre otras cosas si existen redundancias en nombres accesibles, si controles son suficientemente descriptivos, la existencia y uso correcto de regiones vivas en caso de ser necesario.