Para este tipo especial de pruebas, nuestro formulario de errores habitual no proporciona suficientes campos para toda la información necesaria. Además, hay requisitos adicionales para los informes de accesibilidad, que se suman a los requisitos estándar para los informes de errores detallados en los artículos de la academia sobre Requisitos para el Informe de Errores y Adjuntos de Informe de Errores.
Las obligaciones adicionales a las que debe adherirse cada informe de accesibilidad se describen en los siguientes capítulos. Al final del artículo, encontrarás dos ejemplos que ilustran informes de accesibilidad con las reglas aplicadas.
Título
Tu título de error debe seguir el siguiente formato, dependiendo del nivel de accesibilidad (A o AA) y del punto de control del WCAG:
Problemas de nivel A | Problemas de nivel AA |
|
|
|
|
El marcador de posición debe reemplazarse por una descripción de tu error que usarías para informes de errores regulares. Por ejemplo:
[A] [1.1.1] Los enlaces de redes sociales se anuncian incorrectamente
Aquí tienes ejemplos de títulos de errores para los problemas de accesibilidad más comunes. Siéntete libre de usarlos y ajustarlos según tus necesidades:
[A] [4.1.2] Enlace de cierre anunciado sin una función[A] [2.4.3] Botón de alternar de filtro anunciado con un estado incorrecto[A] [2.4.2] El título de la página no es único y descriptivo[AA] [2.4.7] El contorno de enfoque no es visible para el enlace de prueba debajo del botón de inicio de sesión
Pasos para Reproducir
En general
Primer paso: además de la llamada de la URL de prueba, incluye el nombre de la herramienta que utilizaste en tu primer paso. Reemplaza el marcador de posición <herramienta> por ejemplo NVDA, JAWS, WAVE, etc., en la plantilla siguiente:
Usando <herramienta>, abre <URL de prueba>, por ejemplo, Usando NVDA, abre https://www.test.io
Múltiples elementos: Si un punto de control falla para múltiples elementos del mismo tipo (por ejemplo, botones o enlaces), agrupa estas repeticiones en un solo informe.
Múltiples ocurrencias: Para documentar múltiples ocurrencias idénticas de un problema en la misma página o en diferentes páginas, enuméralas en tu resultado real bajo una sección llamada ❝Otras ocurrencias❞.
Acciones descritas: Dado que las personas con discapacidad visual o ciegas no utilizan un mouse de computadora, no describas acciones de mouse. En su lugar, describe acciones de teclado y touchpad, como:
Usa la tecla TAB para navegar a Cuenta de UsuarioPresiona la tecla ENTER para activar el enlace de cierre de sesiónDesliza hacia la izquierda para enfocar el menú hamburguesa
Herramientas automatizadas: Puedes utilizar herramientas como WAVE para identificar problemas, pero tu informe, incluyendo tus pasos, debe describirse desde el punto de vista del usuario. No puedes describir en tus pasos cómo usas una herramienta automatizada y lo que informa, sino que debes describirlo todo como si no hubieras usado ninguna herramienta, basándote únicamente en los puntos de control del WCAG.
Problemas de contraste de color
Tus pasos deben ser los siguientes (reemplaza los marcadores de posición):
Abre <URL de prueba>......Mide la proporción de contraste de color de <nombre del elemento>
Problemas con el mismo conjunto de colores solo se pueden informar una vez. Por ejemplo, un problema con texto azul en un fondo blanco y texto blanco en un fondo azul son el mismo conjunto de colores y no se pueden enviar dos veces.
Resultado Real
En el campo de resultado real, además del resultado real típico que debes ingresar en pruebas exploratorias regulares, proporciona información sobre qué punto de control ha fallado, por ejemplo:
Puntos de control de WCAG 2.1 que fallaron: 1.3.2 Nivel A
Adjuntos
El tipo de archivo adjunto que debes incluir depende del tipo de problema de accesibilidad:
Contraste de color: captura de pantalla
Todos los demás problemas: grabación de pantalla
Capturas de pantalla: Al igual que en las pruebas regulares, el problema debe estar marcado en las capturas de pantalla.
Grabaciones de pantalla: Al grabar tu pantalla, por favor, ralentiza tus acciones antes de llegar al elemento que tiene el problema. Si realizas acciones a una velocidad normal durante la grabación, el espectador de lo contrario no verá el problema. Si realizas acciones demasiado rápido durante la grabación, el TL podría solicitarte una grabación mejorada.
Problemas de navegación con el teclado
Tu grabación de pantalla debe incluir las teclas que presionaste en tu teclado durante la grabación; de lo contrario, los espectadores no podrán comprender el problema. Habilita el teclado en pantalla de tu computadora, que está disponible tanto para Windows como para macOS. Un teclado virtual se superpondrá en parte de tu pantalla y simplemente haces clic en un botón para simular la pulsación de tecla correspondiente.
Plantilla de Formulario
Actualmente, no tenemos un formulario específico para informes de accesibilidad, por lo que, mientras tanto, utilizamos el formulario para informes de usabilidad. Para asegurar que todos los informes sigan el mismo formato, es esencial que estén correctamente formateados. A continuación, proporcionamos una plantilla formateada que te pedimos que utilices.
Simplemente copia y pega la plantilla en el campo de texto único del formulario de usabilidad, reemplaza los marcadores de posición (por ejemplo, <herramienta>, <URL>, etc.) e ingresa tu información.
Notas:
Si no usaste una herramienta para encontrar el problema, por ejemplo, en problemas de navegación con el teclado, el primer paso debe ser como de costumbre: Abre <URL>.
Si necesitas más o menos pasos, simplemente ajusta la numeración en consecuencia.
Pasos
1. Usando <herramienta>, abre <URL>
2.
3.
4.
5.
<resultado real>
Puntos de control de WCAG 2.1 que fallaron: X.X.X Nivel <A/AA>
<resultado esperado>
Ejemplos
Ejemplo de lector de pantalla
Título:
[AA] [2.4.3]: El enfoque no queda atrapado en el menú modal de la hamburguesa
Pasos:
Usando VoiceOver, abre https://test.io/
Desliza hacia la derecha para enfocar el menú de hamburguesa
Doble toque para activarlo
Desliza a través del menú modal de hamburguesa expandido y observa
Resultado Real:
El enfoque continúa moviéndose a través del contenido de fondo detrás del modal, que no forma parte del menú de hamburguesa superpuesto.
Puntos de control de WCAG 2.1 que fallaron: 2.4.3 Nivel AA
Resultado Esperado:
El enfoque debería quedar atrapado en el menú de hamburguesa. Los elementos ocultos de la página subyacente no deberían enfocarse ni anunciarse.
Ejemplo de navegación con el teclado
Título:
[AA] [2.4.7] El enlace ❝Obtener Demo❞ no tiene un contorno de enfoque visible
Pasos:
Usando NVDA, abre https://test.io/
Presiona TAB para enfocar el botón ❝Obtener una demo❞ bajo la sección ❝¿Te tomas la Calidad Personalmente?❞ y observa
Resultado Real:
El enlace ❝Obtener una demo❞ en la sección ❝¿Te tomas la Calidad Personalmente?❞ no tiene un contorno de enfoque.
Otras ocurrencias: Iconos de redes sociales
Puntos de control de WCAG 2.1 que fallaron: 2.4.7 Nivel AA
Resultado Esperado:
Los elementos con acciones deben tener contornos de enfoque visibles cuando se enfocan.
Ejemplo de contraste de color
Título:
[AA] [1.4.3] El texto blanco sobre fondo azul del enlace ❝Obtener una demo❞ no cumple con los requisitos de contraste de color
Pasos:
Abre https://test.io/
Desplázate hasta el enlace ❝Obtener una demo❞
Mide la proporción de contraste de color del enlace ❝Obtener una demo❞
Resultado Real:
El enlace ❝Obtener una demo❞ no cumple con los requisitos de contraste de color. El texto azul en primer plano (#21BEF4) sobre el fondo blanco (#FFFFF) tiene una proporción de contraste de solo 2.15:1.
Puntos de control de WCAG 2.1 que fallaron: 1.4.3 Nivel AA
Resultado Esperado:
El texto pequeño debe tener una proporción de contraste de al menos 4.5:1. El texto grande (negrita de 14 pt o 18 pt o más grande) debe tener una proporción de contraste de al menos 3:1.