Consigna y contexto
Cuéntame sobre una ocasión en la que encontraste un problema de accesibilidad que afectó a los usuarios o generó un riesgo para el lanzamiento. ¿Cómo confirmaste el impacto, impulsaste la solución, te comunicaste con el equipo y evitaste que se repitiera?
Una respuesta sólida relata una falla real o un incidente cercano en lugar de recitar cláusulas de WCAG. WCAG 2.2 proporciona criterios de éxito evaluables, mientras que el GOV.UK Service Manual recomienda pruebas automatizadas, manuales y con tecnologías de asistencia. Utiliza esas fuentes para explicar tu evidencia, pero no conviertas un solo escaneo automatizado en una afirmación completa de conformidad.
Qué está evaluando el entrevistador
El entrevistador busca juicio centrado en el usuario, recopilación rápida de hechos, sentido de propiedad, coordinación multifuncional y mejoras medibles. También desea escuchar cómo manejaste la presión del lanzamiento, las prioridades contrapuestas y la evidencia incompleta, y si convertiste un rescate individual en un mecanismo de equipo.
Preguntas para aclarar primero
- ¿Qué usuarios, tareas críticas, dispositivos o tecnologías de asistencia se vieron afectados?
- ¿Lo encontraste a través de comentarios de usuarios, pruebas manuales, automatización o una señal de producción?
- ¿Ya estaba en producción y existía una ruta alternativa o una mitigación urgente?
- ¿Qué equipos eran responsables del diseño, el código, el contenido, las pruebas y las decisiones de lanzamiento?
- ¿Qué datos de tiempos, tasa de éxito, pasos bloqueados o regresiones puedes compartir?
- ¿De qué te hiciste cargo personalmente y qué hicieron las demás personas?
Una respuesta de 30 segundos
“Elegiría un caso específico que demuestre impacto y cambio. Primero utilicé la tarea del usuario afectado y la evidencia para definir el problema, proporcioné una ruta utilizable a corto plazo e hice visible el riesgo. Luego trabajé con diseño, ingeniería, control de calidad y producto en las prioridades, y volví a probar con tecnologías de asistencia y usuarios reales. Después del lanzamiento, agregué validaciones, responsables y señales de regresión al proceso habitual. Cuantificaría el cambio en el éxito de las tareas, quejas o regresiones, y expondría cualquier riesgo remanente en lugar de ocultarlo”.
Respuesta detallada paso a paso
Paso 1: Describe el impacto en lugar de aplicar una etiqueta
Explica qué tarea falló para qué combinación de dispositivo y tecnología de asistencia. Reemplaza “el botón no era intuitivo” por “un usuario de lector de pantalla no pudo identificar el control de envío, por lo que no se pudo completar el pago”. Proporciona pasos de reproducción, tamaño de la muestra o el lenguaje del usuario. No deduzcas la gravedad ni la responsabilidad legal sin evidencia.
Paso 2: Confirma con rapidez y limita el daño
Reproduce el problema y registra la versión de la página, el navegador, la tecnología de asistencia y las rutas de éxito y fallo. Si el riesgo está aumentando, propone deshabilitar el flujo afectado, ofrecer una alternativa humana, pausar el lanzamiento o agregar un aviso claro. Explica cómo se enteraron los usuarios afectados sobre el cambio en lugar de dejarlo en un ticket interno.
Paso 3: Coordina con un lenguaje compartido
Divide el problema en diseño, semántica, comportamiento del teclado, gestión del foco, contenido, pruebas y pasos de lanzamiento. Invita a colegas o usuarios que dependan de tecnologías de asistencia. Analiza la prioridad utilizando tareas y evidencia; no conviertas la accesibilidad en la responsabilidad privada de un único experto ni termines la conversación con “lo arreglaremos más adelante”.
Paso 4: Haz que la solución sea verificable
Indica la solución más pequeña, el responsable, la fecha, la dependencia y la línea de parada. Combina comprobaciones automatizadas, revisión manual de teclado, pruebas de lectores de pantalla y pruebas con usuarios reales; la automatización encuentra solo una parte del problema. Si varios flujos se ven afectados, repara primero las tareas de alta frecuencia o irremplazables y programa el resto.
Paso 5: Comunica los balances bajo presión
Informa al responsable del lanzamiento sobre el impacto en el usuario, el riesgo, la mitigación y el costo del retraso. Si una solución completa no puede llegar antes del lanzamiento, proporciona una alternativa acotada, una explicación pública y una fecha en lugar de ocultar el problema. Registra quién aprobó qué para que “inconcluso” no se confunda con “riesgo aceptado”.
Paso 6: Valida con usuarios
Pide a los usuarios afectados que completen la tarea original con combinaciones reales como teclado, lector de pantalla, ampliación o entrada de voz. Registra el éxito de la tarea, el tiempo de finalización, los errores, las solicitudes de ayuda y los comentarios. Si los usuarios siguen fallando después de la solución, reconócelo e itera; un escaneo en verde no prueba una experiencia utilizable.
Paso 7: Incorpora la lección al proceso
Agrega reglas concretas a la revisión de diseño, la biblioteca de componentes, los criterios de aceptación, las verificaciones de CI, las listas de verificación de lanzamiento y las pruebas de regresión. Asigna un responsable y una vía de excepción para cada regla, y mantén una tendencia de defectos y un punto de entrada para los comentarios de los usuarios. El siguiente compañero de equipo debería poder ejecutar la mejora sin depender de tu memoria.
Paso 8: Cierra con resultados y reflexión
Utiliza datos de antes y después y menciona las métricas que sigan siendo débiles. Reflexiona sobre lo que pasó por alto tu juicio, comunicación o mecanismo de prevención; si evaluaste mal el impacto, explica cómo lo corregiste. Termina con la siguiente acción: mayor cobertura, actualizaciones de componentes, capacitación u otra ronda de investigación de usuarios.
Balances y límites
Velocidad frente a reparación completa
La mitigación urgente protege a los usuarios, pero no reemplaza la reparación de la causa raíz. Ofrece tanto un paso de contención inmediato como un plan duradero, con un responsable y fecha de caducidad para que la ruta temporal no se vuelva permanente.
Automatización frente a validación humana
La automatización permite verificaciones de regresión rápidas, mientras que las pruebas manuales con teclado y tecnologías de asistencia revelan el contexto, el foco, el orden y la usabilidad real. Registra su cobertura y evidencia por separado.
Estándares frente a experiencia vivida
Los criterios de éxito de WCAG proporcionan un lenguaje compartido, pero aprobar un criterio no garantiza que la tarea de cada usuario sea fluida. Conecta el criterio con una tarea, dispositivo y comentarios de usuarios en lugar de presentar únicamente un puntaje de conformidad.
Simulacros de fallas y plan de evolución
Los usuarios aún no pueden completar la tarea
Observa nuevamente la cadena completa de tareas, pregunta a los usuarios dónde están bloqueados e inspecciona el contenido, el foco y la recuperación de errores en lugar de limitarte a volver a ejecutar un escaneo. Aumenta la muestra y actualiza los criterios de aceptación.
El equipo culpa a un componente heredado
Reconoce la restricción del componente, luego propone un contenedor temporal o una alternativa a corto plazo y una solución de componentes a largo plazo. Registra el alcance, el responsable y la fecha para que la responsabilidad no pase de un equipo a otro.
Regresa la presión de lanzamiento
Utiliza la línea de parada acordada, el registro de riesgos y la ruta alternativa. Si se aprueba un lanzamiento que asume riesgos, nombra a la persona que aprueba, el aviso al usuario, el monitoreo y los criterios de reversión, y luego revisa si el umbral de control debería ser más alto.
Errores comunes y preguntas de seguimiento
Error 1: Decir solo “Corregí un atributo aria”
Pregunta de seguimiento: ¿Qué tarea del usuario estaba bloqueada y cómo lo verificaste antes y después? Nombra la tarea, la tecnología de asistencia y el resultado.
Error 2: Tratar un puntaje automatizado como evidencia de usuario
Pregunta de seguimiento: ¿Qué pruebas manuales y con usuarios reales ejecutaste? ¿Qué problemas no pudo encontrar la herramienta automatizada?
Error 3: Dejar la accesibilidad en manos de QA o de un único experto
Pregunta de seguimiento: ¿Qué cambió para diseño, ingeniería, contenido y producto? Explica la responsabilidad compartida y las barreras de protección del proceso.
Error 4: Contar una historia de conflicto de equipo sin tu acción
Pregunta de seguimiento: ¿Qué propusiste, impulsaste o cambiaste? ¿Qué habría sucedido sin tu intervención?
Preguntas de seguimiento y respuestas
¿Cómo decides si bloquear un lanzamiento con evidencia incompleta?
Presenta el impacto conocido, las incógnitas y la mitigación temporal, luego recomienda un camino utilizando la criticidad, la escala afectada, las alternativas y el tiempo de reparación. Un responsable autorizado lo aprueba con monitoreo, aviso al usuario y condiciones de reversión; la incertidumbre no se presenta como certeza.
¿Cómo demuestras que el cambio de proceso funcionó?
Compara la regresión posterior de defectos, el éxito en tareas críticas, la cobertura de tecnologías de asistencia, los comentarios de los usuarios y el tiempo de reparación. Continúa con revisiones manuales por muestreo para que un menor recuento de reportes no se confunda con una mejora.
¿Cómo deberías responder si tu primer juicio fue incorrecto?
Menciona el juicio incorrecto, el impacto y la nueva evidencia. Explica cómo te comunicaste con el equipo y los usuarios afectados y cómo integraste la corrección en una lista de verificación o proceso. El sentido de propiedad y el aprendizaje son más sólidos que culpar a una herramienta.