Pruebas de disponibilidad de interfaces

1) Por qué y qué creemos que está «listo»

• se han cumplido los criterios WCAG 2. 1/2. 2 niveles de AA para plataformas de destino;
• la interfaz es totalmente accesible desde el teclado;
• funcionamiento correcto con los captores de pantalla;
• los contrastes se ajustan a las normas;
• todos los estados/errores/estados están disponibles fuera de la vista y sin el ratón;
• se tienen en cuenta la localización, RTL, reducción de movimiento y características móviles.

2) Estrategia de prueba (pirámide A11y)

1. Autotestas/linternas (cobertura rápida de hasta el 40-60% de las clases de problemas).
2. Comprobación manual de patrones (teclado, enfoque, contenido, lógica).
3. Assistive Tech (AT) sesiones: screenriders, zoom, filtros de color.
4. Pruebas de campo con los usuarios (si es posible).

Objetivo: capturar defectos sistémicos a nivel de componentes/patrones para que no se reproduzcan en fichas.

3) Comprobación básica de la lista de verificación (ejecución rápida)

• Teclado: todo es alcanzable con tabúes/flechas; el orden de enfoque es lógico; trampa de enfoque en los modales hay; Los CES/Enter/Space funcionan.
• El indicador de enfoque se ve en cualquier tema/en cualquier fondo.
• Contraste: texto ≥ 4. 5:1 (normal), ≥ 3:1 (grande), iconos/controles legibles.
• Semántica: etiquetas correctas ('button', 'a', 'label', 'ul/li', 'th/td'), roles y' aria- 'sólo cuando sea necesario.
• Screenrider: encabezados por jerarquía, nombres semánticos de botones/enlaces, alternativas para iconos/imágenes.
• Formas: 'label' explícito, pistas/errores relacionados ('aria-describedby'), los textos de error son específicos.
• Dinámica: se anuncian tostadas/pancartas/errores a través de 'aria-live' ('polite '/' assertive').
• Las animaciones respetan 'prefers-reduced-motion'; sin «sacudir» la interfaz.
• Localización/RTL: las pantallas clave están alineadas, los números/fechas/monedas están formateados por utilidades.
• Movilidad: objetivos de toque ≥ 44 × 44 px, zoom no prohibido, el giro de la pantalla no rompe el contenido.

4) Roles, responsabilidades y artefactos

Sistema de diseño: A11y-requisitos en la descripción de cada componente.
Desarrolladores: verificaciones automáticas, pruebas unit/interaction con A11y-asserts.
QA: scripts manuales + sesiones AT; informe con gravedad/frecuencia.
UX/Content: microcopia de errores/estados, legibilidad en voz alta.
Artefactos: listas de cheques, scripts, capturas de pantalla AT, lista de defectos con referencias WCAG, recomendaciones.

5) Comprobaciones automatizadas

Linters/analizadores: axe, eslint-plugin-jsx-a11y, pa11y, Lighthouse.
En pipeline: bloqueamos el PR en caso de infracciones críticas (role/label/contraste/trampas de aprox).
Snapshots de contraste: pruebas visuales de temas/estados.

6) Pruebas manuales: scripts

6. 1 Teclado

Vaya a la página sólo con el teclado (Amb/Mayús + Amb/Enter/Space/flechas).
Compruebe: visibilidad del foco, orden de prioridad, disponibilidad de todas las acciones, ausencia de «trampas» y elementos «muertos».
En Modalk: enfoque en el interior, cuando se cierra, vuelve al iniciador.

6. 2 Captores de pantalla (conjunto mínimo)

Desktop: NVDA/JAWS (Windows), VoiceOver (macOS).
Mobile: VoiceOver (iOS), TalkBack (Android).
Comprobamos: títulos correctos (jerarquía H), nombres de botones/enlaces, lectura de tablas ('th '/' scope'), declaración de estados, errores de formularios comprensibles.

6. 3 Contenido y microcopia

Leemos textos críticos en voz alta - sin ambigüedades, sin el «error 400».
Error = «que no es así + cómo corregir + limitación/formato».

6. 4 Dinámicas y regiones vivas

El brindis del éxito es 'aria-live =' polite ', el error es' assertive '.
El progreso/descarga se explica por el texto; skeleton es preferible a spinner.

7) Formas y errores (en profundidad)

Cada campo tiene una etiqueta asociada (no placeholder).
Los errores están relacionados con el campo: 'aria-invalid =' true ',' aria-describedby = '[id del error]'.
Las fórmulas de formato (fecha, teléfono) se especifican con antelación; las máscaras no rompen la entrada/inserción.
El banner de error total de submit + auto-scroll y el enfoque en el primer error.
Textos de error: específicos, sin jerga técnica.

8) Tablas, listas, gráficos

Tablas: títulos 'th' s 'scope =' col/row '', firmas, currículum.
Las listas son reales 'ul/ol/li', no divas.
Gráficos - Tablas/descripciones alternativas; leyendas disponibles; los colores ≠ la única señal.

9) Multimedia y animaciones

Vídeo: subtítulos/descifrado; control desde el teclado; sin autoplay (o con silencio).
GIF/micro animaciones: desactivamos cuando 'prefers-reduced-motion'; evitamos los brotes.
Vibraciones/sonidos - opcionales y duplicados visualmente/por texto.

10) Disponibilidad móvil

Interactivos ≥ 44 × 44 px, intervalos suficientes.
Zoom no prohibido (meta viewport sin 'user-scalable = no').
Forma/teclado: tipos correctos ('tel', 'email', 'número') sin ocultar las capacidades del sistema.
Comprobación en un tema oscuro y con fuentes del sistema «más».

11) Localización, números y RTL

Cadenas a través de claves i18n con contexto; los idiomas largos (DE/TR) no rompen el diseño.
Los formatos de fecha/moneda son utilidades, no cadenas.
Modo RTL: espejo de iconos de navegación, comprobar el orden del foco y del carro, entrada bidireccional.

12) Especificidad del flow crítico (iGaming)

Pagos/conclusiones

Instrucciones claras, límites/plazos/comisiones - texto.
Los errores del proveedor se declaran explícitamente, sin códigos; hay una alternativa a la acción.
Confirmación de la operación: enfoque en el CTA lógico, posibilidad de cancelación.

CUS/verificación

Consejos paso a paso para fotos/documentos; progreso y ETA.
Errores «desenfocados/deslumbrados/recortados» - con ejemplos de corrección.
Tono neutral, sin humor.

13) Evaluación de la gravedad de los defectos

Blocker: no se puede completar una tarea clave (con teclado/screenrider).
Crítica: la funcionalidad crítica funciona, pero con serias barreras.
Mayor: interfiere, hay una solución.
Menor: cosmética/no coincidencia con gaids sin afectar la tarea.

Cada defecto es una referencia al criterio WCAG y a la secuencia de comandos reproducible.

14) Criterios de aceptación (Definición de Don, A11y)

Pasar el script del teclado sin el ratón al 100%.
axe/Lighthouse: no hay infracciones críticas/altas.
Contraste de AA en todos los temas/estados.
Screenrider-running de las vías clave (navbar, formas, modalkas, tostadas).
Documentación A11y para nuevos componentes/fichas (modelo de rol, aria, enfoque, ejemplos).
La regresión de las pruebas A11y es verde en CI.

15) Procesos y automatización

Antes del desarrollo: Criterios A11y en tareas, diseños con estados de enfoque/error.
En desarrollo: linters/ahe durante el ensamblaje local; emparejamientos visuales de contraste/enfoque.
En CI: pa11y/axe-scan por páginas críticas; la caída del build en Blocker/Critical.
Después de la liberación: auditorías trimestrales, monitoreo de quejas de los usuarios sobre la etiqueta A11y.

16) Anti-patrones

Playsholder en lugar de label.
'amb' en lugar de 'button '/' a'.
Anillos de enfoque desconectados «por la belleza».
El color como único medio de estado.
Modalkas sin trap focus/ESP.
Prohibición de escalar en el móvil.
«Error 400/500» sin explicación humana.

17) Plantillas de scripts de prueba

Escenario 1 - Navegación por teclado (página con formulario)

1. Amb hasta el primer campo, introduzca los datos.
2. Mayús + Amb atrás - asegúrese de que está en el orden correcto.
3. Invocar validación (submit): el enfoque se transfiere al primer error.
4. Cierre el modal con la tecla AMB, el enfoque volvió al iniciador.

Escenario 2 - Screenrider (página de pago)

1. Vaya al encabezado de la página (h1), escuche las secciones.
2. Abra la selección de método: se oye la declaración de roles/estados.
3. Comete deliberadamente un error de suma - mensaje leído y relacionado con el campo.
4. Un brindis exitoso sobre el pago declarado 'polite'.

Escenario 3 - Dinámica

1. Ejecute la operación pendiente> 3 s - hay texto sobre el proceso/ETA.
2. En caso de error de red - banner 'assertive', disponible desde el teclado, hay una manera de «repetir/ayudar».

18) Micro-plantillas útiles

Roles/aria para tostadas

html
<div role = "status" aria-live = "polite"> Payment accepted. Balance updated. </div>
<div role = "alert" aria-live = "assertive"> The payment was denied. Try another method. </div>

Relación de error con el campo

html
<label for = "amount "> Amount </label>
<input id="amount" aria-invalid="true" aria-describedby="amount-error">
<div id = "amount-error "> Minimum 100 UAH. Please enter a larger amount. </div>

Modalk (atributos semánticos)

html
<div role="dialog" aria-modal="true" aria-labelledby="m-title">
<h2 id =" m-title "> Confirm Payment </h2>
<! -- content -->
<button> Confirm </button>
<button> Cancel </button>
</div>

19) Plan de implementación rápida de las prácticas A11y

1. Auditoría de componentes/patrones actuales (semántica de contraste/enfoque/rol).
2. Edición del sistema de diseño: agregue una partición A11y a cada componente.
3. Herramientas: configurar los conectores/axe/pa11y/Lighthouse localmente y en CI.
4. Entrenamiento: Gaids cortos para diseñadores/desarrolladores/redactores.
5. Piloto: reparar 3-5 de los defectos más frecuentes (modales, formas, tostadas).
6. Reglamento: DoD con criterios A11y; auditoría trimestral.

Parche final

Comprueba el teclado, el enfoque, los contrastes, el screenrider, la dinámica.
Declare los estados a través de aria-live; errores - relacionados con los campos.
Respete el movimiento de reducción, no prohíba el zoom.
Piensa en semántica (etiquetas/roles) en lugar de «cómo se ve».
Automatiza las inspecciones, pero siempre complementa con las manuales.
Captura los defectos con referencia a WCAG, gravedad y escenario de reproducción.