Pruebas de accesibilidad

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

Explicar el motivo por el cual es fundamental realizar pruebas manuales de accesibilidad además de las pruebas automatizadas.
Resumir los pasos necesarios para realizar pruebas de teclado y gestión de enfoque en MacOS.
Identificar las comprobaciones que se deben realizar al llevar a cabo pruebas de lectores de pantalla con VoiceOver.
Reconocer elementos para incluir en los planes de pruebas de accesibilidad.
Describir estrategias para lograr pruebas manuales de accesibilidad eficaces.

Comprender la importancia de las pruebas manuales

A pesar de que las pruebas automatizadas de accesibilidad pueden detectar muchos problemas, no tienen en cuenta el contexto ni identifican problemas de accesibilidad más sutiles. A veces, hasta pueden omitir problemas significativos. Por eso, es fundamental realizar pruebas manuales de accesibilidad para detectar las barreras que las pruebas automatizadas no identificaron. Las pruebas manuales también permiten validar problemas que se hayan descubierto durante las pruebas automatizadas e identificar falsos positivos.

Un desarrollador que realiza pruebas de accesibilidad manuales.

A diferencia de las pruebas automatizadas de accesibilidad, las pruebas manuales evalúan todo el recorrido del usuario para simular la experiencia de un usuario que tiene una discapacidad o que utiliza tecnología de asistencia. Por ejemplo, la prueba manual de teclado simula cómo un usuario navega por su software usando solo el teclado, mientras que la prueba manual de lector de pantalla simula cómo un usuario con discapacidad visual experimenta su software.

Veamos en más detalle las pruebas manuales de accesibilidad; comencemos con el teclado y la gestión de enfoque.

Realizar pruebas de teclado y gestión de enfoque

Las pruebas de teclado y gestión de enfoque son una excelente forma de garantizar que los usuarios puedan navegar e interactuar con la interfaz del usuario de manera directa y según lo esperado.

Cuando realice pruebas de teclado, formule preguntas como las siguientes:

¿Se puede acceder al contenido con diferentes tipos de entradas? Los usuarios deben poder desplazarse por el contenido mediante distintos dispositivos de entrada, como comandos de voz, pantallas táctiles y controles de cambios. Si algún contenido está disponible solamente si se pasa el mouse sobre él, los usuarios de pantallas táctiles, dictado por voz y teclado no aprovecharán esa opción.
¿El orden del enfoque tiene lógica? Este orden se refiere a la secuencia en la que reciben el enfoque los elementos interactivos, como vínculos, botones y campos de formulario. Un orden de enfoque sin lógica puede hacer que la navegación sea difícil.
¿Los usuarios pueden desplazarse por el contenido con eficiencia y consistencia? Los cambios inesperados en la navegación, como diferentes pulsaciones de teclas o comandos, pueden suponer una dificultad para el usuario final, en especial si usan tecnología de asistencia.
¿Todos los usuarios pueden desplazarse por este contenido? Tenga en cuenta a los usuarios con discapacidades visuales, motoras y de destreza.

Al realizar pruebas en una Mac, necesita habilitar el acceso completo del teclado en las preferencias del sistema de teclado. Siga estos pasos.

Habilitar la navegación del teclado en MacOS

Abra la opción Teclado en Preferencias del Sistema.
Seleccione la ficha Funciones rápidas.
En el acceso completo del teclado, seleccione Todos los controles.

La ficha Funciones rápidas de la pantalla de configuración del teclado en MacOS con el campo de acceso completo del teclado resaltado y la opción Todos los controles seleccionada.

Habilitar el acceso del teclado para Safari

Abra Preferencias de Safari.
Seleccione la ficha Avanzado.
En Accesibilidad, seleccione Presionar Tabulador para resaltar cada elemento de una página web.

Navegue por una página web con estas teclas.

Use:	Para hacer lo siguiente:
Tab y Mayús+Tab	Desplácese por los vínculos, campos de entrada y otros controles interactivos. La tecla Tab se mueve hacia delante a través de la interfaz de usuario y Mayús+Tab se mueven hacia atrás. No se preocupe si no puede ver todos los elementos en la página y solo aparecen los elementos interactivos.
Ctrl+Tab	Desplácese por los marcos.
Intro	Active los vínculos.
Intro y espacio	Active los botones.
Espacio	Active las casillas de verificación del campo de entrada y seleccione los menús desplegables.
Flecha hacia arriba y hacia abajo	Desplácese por los menús, las listas de selección y los menús desplegables de relleno automático.
Flecha izquierda y derecha	Desplácese por las fichas en un conjunto de fichas o carrusel.
Esc	Cierre menús, modales y paneles.

¿Puede alcanzar cada elemento interactivo y desencadenar su acción?

Algunos elementos complejos con múltiples elementos interactivos tienen más interacciones de teclado exclusivas además de lo básico, incluidos los cuadros combinados, los menús, las cuadrículas de datos, los diálogos modales y no modales, y los conjuntos de fichas. Estas interacciones de teclado siguen ciertas expectativas definidas por las Prácticas de redacción de ARIA del consorcio World Wide Web Consortium (W3C).

Salesforce crea sus directrices de teclado según estas expectativas, y estas directrices se utilizan en las bibliotecas de componentes React de Lightning y Lightning Design System. Compilamos algunos recursos útiles en el sitio Lightning Design System 2 para ayudar a crear y probar estos componentes.

Directrices de accesibilidad de interacción de teclado: una lista de comprobación de pruebas de teclado manuales
Directrices de accesibilidad de enfoque global: sugerencias sobre comportamientos esperados para la gestión de enfoque
Accesibilidad: especificaciones de interacción y HTML para patrones/widgets comunes

Probar navegación de teclado

Cuando pruebe la navegación del teclado, verifique lo siguiente:

El orden de las fichas es lógico. Utilice el tablero para navegar por su aplicación. El orden de navegación predeterminado debería ser lógico y verse natural.
El enfoque del teclado es visible. Utilice el tablero para navegar por una página y confirme que un indicador visual muestra el elemento que tiene enfoque de teclado.

Los elementos accionables reciben enfoque. Utilice el tablero para navegar por una página. Pruebe que todos los botones, los vínculos, los campos de formulario, las fichas y cualquier otro elemento interactivo puedan aceptar el enfoque de teclado. Si un usuario puede hacer clic en un elemento para realizar una acción o pasar el cursor para revelar información, debe aceptar el enfoque del teclado.

Se puede navegar por los elementos interactivos. Verifique que pueda desplazarse por todos los elementos interactivos, como menús, modales, elementos de arrastrar y soltar, conjuntos de fichas, paneles y menús desplegables de relleno automático. Verifique que pueda utilizar el teclado para seleccionar y activar elementos.

Se puede desplazar por los cuadros de diálogo modales. Utilice el teclado para abrir y desplazarse por un cuadro de diálogo modal y opere todos los controles en él. Verifique que pueda interactuar solo con la ventana modal actual, y no con la página detrás de ella. Cuando se abre un modal, el enfoque debería estar en el interior. Asegúrese de que cuando se cierra un modal, el enfoque vuelva al lugar correcto en la página.

Tenga en cuenta que existen diferencias entre las pruebas de teclado y las pruebas de lector de pantalla. Comience con las pruebas de teclado antes de probar con un lector de pantalla para identificar los problemas que un lector de pantalla no puede detectar.

Se recomienda que realice pruebas de lector de pantalla en MacOS y Windows. MacOS tiene un lector de pantalla integrado que se denomina VoiceOver, que reproduce en voz alta el elemento seleccionado y lee su etiqueta o texto alternativo. Cuando realice una prueba con un lector de pantalla, descubrirá si su texto alternativo es preciso y, de ser necesario, haga los ajustes necesarios.

A continuación, detallamos algunas comprobaciones sencillas que puede hacer con VoiceOver en MacOS.

Use Cmd+F5 para activar o desactivar VoiceOver.
Use Cmd+u para abrir Web Rotor.
Utilice Web Rotor para comprobar lo siguiente:
- Los vínculos y botones tienen etiquetas concisas y relevantes.
- Los encabezados están en el orden correcto.
- La página tiene buenos puntos de referencia.
Desplácese por la interfaz del usuario para verificar lo siguiente:
- Los campos que se pueden modificar indican su etiqueta, tipo de entrada y la palabra “editar”.
- Los conjuntos de fichas indican qué ficha está seleccionada y se puede navegar con las teclas de flechas.
- Las casillas de verificación indican en voz alta sus estados cuando se alterna con la barra espaciadora.

No se preocupe si no puede alcanzar cada parte de contenido al navegar con el tabulador a través de la interfaz de usuario mediante un lector de pantalla. Los usuarios del lector de pantalla tienen accesos directos específicos del teclado para desplazarse por la página, elemento por elemento, incluidos los elementos no interactivos, para que la tecla Tab no tenga que abarcar todo (ni debería hacerlo). Con VoiceOver, puede utilizar Ctrl+Opción+Flecha izquierda o Ctrl+Opción+Flecha derecha para leer el contenido de la página de forma lineal de atrás para adelante o de adelante para atrás.

En Windows, se recomienda utilizar NVDA.

Realice las pruebas de accesibilidad con varios lectores de pantalla. Si solo prueba con VoiceOver, es posible que omita problemas específicos que otros lectores pueden detectar, como JAWS o NVDA.

Si está realizando pruebas con un lector de pantalla y no suele utilizarlo de forma regular, es común que encuentre errores de usuario. Consulte los videos sobre A11ycasts en la sección Recursos para obtener más información sobre los matices que se pueden presentar al usar lectores de pantalla.

Escribir planes de prueba de accesibilidad

Para incorporar la accesibilidad en su plan de pruebas, inclúyala en las especificaciones de su componente, los criterios de aceptación y las historias de los usuarios.

Ejemplo: Iniciador de aplicación

Para abrir el Iniciador de aplicación, seleccione . En el Iniciador de aplicación, los usuarios pueden buscar y abrir aplicaciones, leer sus descripciones y volver a organizar aplicaciones.

El Iniciador de aplicación con la sección “Todas las aplicaciones” ampliada.

¿Qué casos de prueba puede crear para volver a organizar aplicaciones?

Este es un plan de prueba de muestra para diferentes casos de uso asociados con el Iniciador de aplicación.

Para darle contexto, la funcionalidad se refiere a lo que un producto o servicio puede hacer, es decir, sus funciones o acciones. La potencialidad es un elemento de diseño que sugiere cómo se debe usar un objeto según su apariencia y comportamiento.

Tipo	Mouse	Teclado	Lector de pantalla
Funcionalidad.	Hacer clic en el mosaico abre la aplicación	Presionar Intro en el mosaico abre la aplicación	Se aplican todas las expectativas de teclado
Potencialidad	El mosaico movió el cursor cuando se pasa sobre él	El botón de mover el mosaico tiene distintos indicadores de enfoque visuales	Se notifica al usuario de posibles interacciones
Funcionalidad.	Hacer clic y sostener el mosaico inicia el arrastre	La tecla de espacio inicia el modo de arrastre	Lectura de estado de arrastre, posición e instrucciones cuando un usuario ingresa al modo de arrastre
Potencialidad	El modo de arrastre tiene un estado visual distinto (mosaico en ángulo con borde azul)	El modo de arrastre tiene un estado visual distinto (mosaico en ángulo con borde azul)
Funcionalidad.	Mover el mouse cuando el arrastre mueve el mosaico	Las teclas de flecha mueven la aplicación a la posición previa o posterior en la lista
Potencialidad	El usuario ve una vista previa de la posición de aplicación	El usuario ve una vista previa de la posición de aplicación	Se lee la posición de aplicación cuando cambia
Funcionalidad.	Soltar el mouse finaliza el arrastre	La tecla Intro inicia el modo de arrastre	Se lee el estado de posición final y arrastre cuando el usuario sale del modo de arrastre

¿Qué otros casos de prueba puede agregar? ¿Cómo probaría esto? Aunque es posible que pueda escribir pruebas automatizadas para los atributos del lector de pantalla y el comportamiento del teclado, aún debe realizar algunas pruebas manuales para garantizar que la experiencia no tenga interrupciones.

Usar estrategias de pruebas manuales

¿Vamos a poner todo en práctica? A continuación, detallamos algunas estrategias para realizar pruebas manuales de accesibilidad que sean eficaces.

Escribir un plan de prueba

Puede incluir lo siguiente:

Llamar a $A.test.assertAccessible para los estados visuales esenciales (para las pruebas de componentes).
Comprobar manualmente el flujo del teclado.
Considerar factores exclusivos para su caso de uso.

Realizar pruebas temprano y seguido

Mientras crea interfaces de usuario:

Realizar pruebas manualmente.
Habilitar la automatización de pruebas.
Buscar oportunidades para garantizar la accesibilidad con pruebas personalizadas.

Registrar y solucionar errores

En Salesforce, priorizamos los errores de accesibilidad, sin importar la cantidad de usuarios a los que afectan. Para los usuarios que se ven afectados, estos errores pueden ser una barrera crucial para realizar su trabajo. Cualquiera sea el modo en que su organización prioriza los errores, fomente que la cantidad de problemas de accesibilidad sin resolver sea mínima.

Al realizar pruebas automatizadas y manuales de accesibilidad, y al eliminar las barreras que puedan surgir, se logra ofrecer una experiencia digital realmente inclusiva en la que todas las personas pueden participar y disfrutar.

Estimación de tiempo

Temas