Valida las rutas de acceso, no solo la ruta predeterminada

945. Identidad de la lección

Módulo

2.15 — Accesibilidad

Lección

Valida las rutas de acceso, no solo la ruta predeterminada

Tipo académico

Flujo de trabajo

Tipo de esquema

Mixto

Orden

Lección 2 del módulo

Tiempo estimado

35–45 minutos, incluida la práctica

Esta lección convierte la superficie del contrato de la lección anterior en un plan de validación ejecutable. Probarás una interacción acotada mediante sus rutas de acceso requeridas y producirás evidencia que otra persona pueda revisar y repetir.

946. Objetivo de aprendizaje

Después de esta lección, podrás escribir y ejecutar un plan de validación de accesibilidad para una interacción acotada. El plan definirá resultados observables, rutas compatibles, configuraciones de prueba, señales de presentación, condiciones temporales, retroalimentación, recuperación, estabilidad entre rutas, estados de la evidencia y decisiones de seguimiento.

947. Límite de la validación

948. Por qué importa

Una prueba de la ruta predeterminada solo demuestra que una interacción funcionó mediante una ruta y una configuración concretas. No establece que una entrada alternativa requerida funcione, que la información de estado y error siga siendo perceptible, que el comportamiento temporal admitido sea suficiente o que la recuperación funcione después de un intento bloqueado.

Por tanto, un registro de validación debe responder por separado a dos preguntas:

1. ¿Qué exige el contrato de la interacción?
2. ¿Qué se observó en una versión y configuración identificadas?

Una ruta, adaptación temporal o alternativa de retroalimentación que la tarea exige pero que la implementación no admite es una carencia. No puede convertirse en un cumplimiento llamándola decisión de alcance.

949. Conocimientos previos

Ya deberías poder:

• Describir la superficie del contrato de una interacción: acciones requeridas, decisiones, retroalimentación y recuperación.
• Distinguir una condición de juego de la señal que la comunica.
• Identificar una interacción acotada y sus responsabilidades de implementación.

Estas capacidades provienen de 2.15 — Accesibilidad: La accesibilidad cambia la superficie del contrato.

950. Cuatro estados de la evidencia

Asigna exactamente un estado a cada criterio y ruta requerida:

• Cumple: La prueba configurada produjo el resultado observable exigido por el criterio.
• No cumple: La prueba se ejecutó y el resultado observado no satisfizo el criterio.
• Pendiente: Falta evidencia, el requisito no está claro, la configuración todavía no puede probarse o no existe un umbral documentado que permita declarar el cumplimiento.
• No aplicable: El criterio no corresponde a la tarea, al contrato admitido o a la configuración probada, y el registro incluye una justificación basada en la tarea.

No uses no aplicable solo porque una ruta no exista. Si la tarea o un requisito documentado del proyecto o de la plataforma exige una ruta alternativa, una adaptación temporal o una alternativa de retroalimentación que no está disponible, registra una carencia como no cumple o pendiente. Asígnale una persona responsable y una acción de seguimiento.

951. Criterios de aceptación operativos

Expresiones como “legible”, “claro”, “importante” o “tiempo suficiente” no son condiciones de cumplimiento por sí solas. Registra lo siguiente para cada criterio:

1. Fuente del requisito: El requisito documentado del proyecto o de la plataforma, cuando exista.
2. Versión: La compilación, revisión o configuración exacta que se probó.
3. Dispositivo y ruta de entrada: El dispositivo, método de control, reasignación, ruta mediante pulsador, teclado, mando u otra ruta compatible que se utilizó realmente.
4. Ajustes relevantes: Los ajustes de accesibilidad, presentación, audio, controles, tiempo o dificultad que estaban activos.
5. Estado inicial: El estado desde el que comienza la prueba.
6. Acción: La acción o secuencia exacta del jugador.
7. Señal y estado esperados: La presentación, la retroalimentación y el estado resultante observables necesarios para cumplir el criterio.
8. Condición temporal: Un límite documentado, una ventana medida, un estado de pausa, una condición de reintento o una indicación de que la tarea no tiene un umbral temporal aplicable.
9. Resultado observado: Lo que ocurrió, incluidas las señales, las transiciones de estado, el tiempo y la recuperación.
10. Estado de la evidencia: Cumple, no cumple, pendiente o no aplicable.
11. Responsable y seguimiento: Obligatorios para cada resultado que no cumple o queda pendiente.

Cuando exista un umbral documentado, úsalo. Si no existe, no inventes uno. Deja el juicio pendiente hasta que haya un requisito autorizado o un criterio observable.

952. Comprobación RUTAS

953. Ejemplo de criterio

Para una interacción acotada en la que el jugador confirma un objeto seleccionado, un criterio comprobable podría decir:

Desde el estado de selección documentado y con la versión y configuración identificadas, cada ruta de confirmación compatible que sea obligatoria cambia el objeto seleccionado al estado activo. Los estados activo, no disponible y de error producen las señales textuales, visuales, auditivas u otras señales compatibles documentadas. La interacción satisface el requisito temporal documentado y un intento bloqueado muestra y completa la recuperación admitida.

El registro debe identificar:

• La versión y la configuración.
• Las rutas predeterminada y alternativas que exige la tarea.
• Los ajustes activos durante cada ejecución.
• Las señales esperadas de acción, estado, éxito y error.
• La condición temporal documentada, si existe.
• El resultado esperado de la recuperación.
• La condición de cumplimiento observable para cada ruta.

Si la tarea exige una ruta alternativa de confirmación que no está implementada, esa ruta es una carencia. Regístrala como no cumple o pendiente, asigna una persona responsable e indica la siguiente acción. Si una ruta propuesta realmente no corresponde a la tarea, usa no aplicable y justifícalo en función de la tarea.

954. Flujo de trabajo con IA

Usa la IA para cuestionar el plan, no para declarar que una ejecución cumple el criterio.

1. Redacta el requisito de la interacción y los criterios observables sin IA.
2. Pide a la IA que identifique resultados ambiguos, rutas obligatorias sin probar, campos de configuración ausentes, supuestos temporales sin respaldo, canales de retroalimentación ausentes, problemas de recuperación y riesgos de aislamiento del estado.
3. Contrasta cada sugerencia con el comportamiento documentado del proyecto y los requisitos aplicables.
4. Elimina controles, ajustes, canales y umbrales inventados.
5. Ejecuta la prueba y registra observaciones directas.
6. Marca como pendiente toda evidencia ausente o todo juicio sin respaldo, en lugar de declararlo cumplido.

Un prompt útil es:

Revisa este plan de validación para una interacción acotada. Identifica criterios que no indiquen versión, dispositivo o configuración de entrada, ajustes relevantes, estado inicial, señal esperada, condición temporal, condición de cumplimiento observable, resultado de recuperación o estado de la evidencia. No inventes comportamientos ni umbrales del proyecto. Distingue las carencias obligatorias pero no compatibles de los casos no aplicables justificados por la tarea.

955. Práctica guiada

Elige una interacción acotada que puedas inspeccionar sin rediseñarla. Crea una tabla de validación con estas columnas:

Completa el trabajo en este orden:

1. Define la tarea acotada y su resultado exitoso observable.
2. Enumera la ruta predeterminada y todas las rutas alternativas que exijan la tarea o los requisitos documentados aplicables.
3. Clasifica cada ruta como compatible, obligatoria pero no compatible, pendiente o no aplicable. Incluye una justificación basada en la tarea para cada caso no aplicable.
4. Registra la versión, el dispositivo o configuración de entrada, los ajustes relevantes y el estado inicial.
5. Define el estado exacto y las señales esperadas de acción, estado, éxito y error.
6. Registra el requisito temporal aplicable. Si no existe un umbral documentado, no conviertas una impresión informal en cumplimiento: déjala pendiente e identifica quién debe aclarar el criterio.
7. Define un intento bloqueado o incorrecto y el resultado esperado de la recuperación.
8. Ejecuta la ruta predeterminada, una ruta alternativa compatible y obligatoria, y después la ruta predeterminada otra vez.
9. Registra la ejecución final inmediata como una comprobación de estabilidad entre rutas o aislamiento del estado.
10. Asigna cumple, no cumple, pendiente o no aplicable a cada criterio. Añade una persona responsable y una acción de seguimiento para cada resultado que no cumpla o quede pendiente.

956. Registro de evidencia

Al menos un registro ejecutado debe contener:

• Versión o compilación.
• Dispositivo y ruta de entrada.
• Ajustes relevantes de accesibilidad e interacción.
• Estado inicial.
• Acción realizada.
• Estado y señales esperados.
• Condición temporal aplicable o ausencia documentada de dicha condición.
• Presentación y canales de retroalimentación observados.
• Estado resultante.
• Resultado de recuperación cuando corresponda.
• Resultado de estabilidad entre rutas.
• Estado de la evidencia.
• Responsable y seguimiento para cualquier resultado que no cumpla o quede pendiente.

Las capturas, el vídeo, los registros técnicos o las notas pueden respaldar el registro, pero un archivo adjunto sin contexto de configuración y observación no es suficiente.

957. Criterios de suficiencia

Tu trabajo es suficiente cuando:

• La interacción y el resultado exitoso observable están acotados.
• Cada ruta obligatoria tiene un estado explícito.
• Una ruta, condición temporal o alternativa de retroalimentación obligatoria pero no compatible se registra como carencia, no como decisión de alcance cumplida.
• Cada cumplimiento cita una condición observable y la configuración en la que se observó.
• Cada caso no aplicable incluye una justificación basada en la tarea.
• Los umbrales sin respaldo y la evidencia ausente quedan pendientes.
• La presentación cubre el estado, los indicadores de estado, el éxito y los errores requeridos.
• El tiempo se vincula con un requisito documentado cuando existe.
• Los canales de retroalimentación se evalúan por la información que transmiten, no solo por su cantidad.
• El fallo y la recuperación se ejecutan o se marcan expresamente como pendientes.
• La repetición inmediata de la ruta predeterminada se etiqueta como estabilidad entre rutas o aislamiento del estado.
• Los resultados que no cumplen o quedan pendientes tienen responsables y acciones de seguimiento.

958. Evaluación práctica

Completa la evaluación práctica adjunta. Entrega la tabla de validación y un registro de evidencia ejecutado. La evaluación considera el resultado observable, las rutas compatibles y obligatorias, la configuración de prueba, la presentación, el tiempo, la retroalimentación, la recuperación, la estabilidad entre rutas, el estado de la evidencia y la decisión resultante.

959. Puntos clave

• Cada criterio recibe un estado: cumple, no cumple, pendiente o no aplicable.
• No aplicable exige una justificación basada en la tarea; no sirve para ocultar una implementación ausente.
• Las rutas y alternativas obligatorias pero no compatibles son carencias con responsables y acciones de seguimiento.
• Para declarar que algo cumple hacen falta una condición observable, una configuración identificada y evidencia directa.
• La repetición inmediata entre rutas comprueba el aislamiento del estado; una prueba de regresión repite el registro después de un cambio.
• Una validación acotada del equipo de desarrollo aporta evidencia de implementación, pero no demuestra por sí sola la accesibilidad global, la usabilidad ni la conformidad.

960. Siguiente lección

Lleva la tabla de validación y el registro de evidencia directamente a Stage 3 — De los sistemas de juego a los responsables de runtime. Usa el artefacto para asignar una persona responsable en runtime y una responsabilidad de ciclo de vida a cada ruta de acceso, señal de presentación, comportamiento temporal, canal de retroalimentación, mecanismo de recuperación, riesgo de estado compartido y registro de evidencia.

961. Comprobación de conocimientos

962. Comprobación