Planteamiento y contexto
La empresa desea que los flujos de trabajo principales funcionen para usuarios de teclado, usuarios de lectores de pantalla, personas con baja visión y personas con discapacidades cognitivas. Los comentarios cubren el contraste, el orden del foco, los errores de formulario y el estado dinámico, pero no existe una base de referencia compartida. Diseña un plan de dos trimestres desde los usuarios y estándares hasta el alcance de la auditoría y la gobernanza del lanzamiento.
Lo que evalúa el entrevistador
El entrevistador busca decisiones de producto que conviertan el "cumplimiento" en resultados para los usuarios. Una respuesta sólida separa los criterios de éxito de WCAG, la aplicabilidad legal y la experiencia del producto, y no trata un escaneo automatizado como una finalización. WCAG-EM pide a los evaluadores que definan el alcance, las páginas representativas y los entornos de prueba; Digital.gov aconseja a los product managers incluir la accesibilidad en los requisitos, la investigación, el diseño y la aceptación.
Preguntas aclaratorias para hacer primero
Usuarios y tareas críticas
Confirma los usuarios afectados, las regiones y las tecnologías asistivas; luego, enumera el inicio de sesión, la creación, la exportación, el pago y otras tareas críticas. Prioriza el bloqueo de tareas y los usuarios afectados, no solo el conteo de defectos.
Estándar y propiedad
Confirma WCAG 2.2 AA o una versión especificada por contrato, la Sección 508 aplicable o la ley local, y los responsables de producto, diseño, ingeniería, QA, legal y comunicación con el cliente.
Estado actual y restricciones de entrega
Verifica el sistema de diseño, la biblioteca de componentes, las pruebas automatizadas, el presupuesto de pruebas manuales y los plazos de los clientes. La hoja de ruta debe gestionar tanto las puertas de aprobación para nuevas funciones como la deuda técnica en páginas heredadas.
Marco de respuesta de 30 segundos
"Empiezo con los usuarios objetivo, las tareas críticas y el estándar aplicable; luego, establezco una base de referencia utilizando páginas representativas y tecnología asistiva. Priorizo los problemas que bloquean el inicio de sesión, los formularios, la navegación, los errores o la retroalimentación de estado, y agrego la aceptación de accesibilidad a la Definición de Terminado para el nuevo trabajo. El éxito incluye la finalización de tareas, el cierre de defectos de teclado y lector de pantalla, la tasa de aprobación en auditorías manuales y las tendencias de quejas. El escaneo automatizado es para triaje, no una prueba definitiva. Tras dos trimestres, el producto mantiene un mecanismo de gobernanza en lugar de un informe de una sola ocasión".
Respuesta detallada paso a paso
Paso 1: Definir el alcance y el resultado
Divide "todo el producto" en usuarios, plantillas de página, tareas críticas y el estándar objetivo. Comprométete primero a completar los flujos de trabajo críticos, luego expande a las páginas de bajo tráfico; registra el riesgo fuera de alcance.
Paso 2: Establecer una base de evidencia
Selecciona páginas y estados representativos, combinando escaneos automatizados, recorridos por teclado, lectores de pantalla, zoom, verificaciones de contraste y entrevistas de usuarios. Registra el criterio, el entorno, la reproducción, el impacto y la gravedad en lugar de capturas de pantalla sin consecuencias.
Paso 3: Clasificar el riesgo de bloqueo
Prioriza la incapacidad de iniciar sesión o enviar datos, el foco perdido, los errores no anunciados, los estados dinámicos silenciosos y los límites de tiempo no ajustables. Trata las fechas legales o contractuales como restricciones, no como el único sustituto del impacto en el usuario.
Paso 4: Planificar cambios de diseño e ingeniería
Corrige componentes compartidos y design tokens antes que las excepciones en páginas individuales. Agrega comportamiento de teclado, foco visible, nombres accesibles, asociación de errores y anuncios de estado; exige que el código nuevo pase linting, verificaciones automatizadas y muestreo manual.
Paso 5: Integrar la aceptación en la entrega
Agrega tareas de usuario y criterios de éxito a los requisitos, inspecciona interacciones en revisiones de diseño y ejecuta pruebas automatizadas y manuales en pull requests y staging. El trabajo de alto riesgo necesita aprobación de accesibilidad; una excepción tiene un responsable y una fecha de vencimiento.
Paso 6: Definir métricas y comunicación
Rastrea defectos bloqueantes, tiempo de resolución, regresiones, cobertura de auditorías manuales, quejas y tickets de soporte por tarea, tecnología asistiva y lanzamiento. Publica el alcance, las limitaciones conocidas y un canal de retroalimentación en lugar de afirmar que es "completamente accesible" más allá de la evidencia disponible.
Paso 7: Gobernar continuamente
Realiza auditorías por muestreo trimestralmente, actualiza las bases de referencia de componentes y la capacitación, y revisa nuevos navegadores y tecnologías asistivas. Incluye la deuda de accesibilidad en la planificación de producto y revisión de riesgos para que el presupuesto, los responsables y las escalaciones permanezcan después de la hoja de ruta.
Ejemplo de respuesta de alta calidad
Establecería un objetivo de dos trimestres para completar el inicio de sesión, los formularios principales, la navegación, los errores y el estado dinámico con las tecnologías asistivas objetivo, para luego expandir la cobertura de páginas. En la primera semana confirmaría WCAG 2.2 AA, los límites legales y contractuales, y crearía una línea base a partir de plantillas y tareas representativas utilizando escaneos automatizados, teclado, lector de pantalla, zoom y comentarios de usuarios.
La priorización utilizaría el bloqueo de tareas, los usuarios afectados y el apalancamiento de la reparación en lugar del conteo del escáner. Corregiría primero los componentes compartidos y añadiría puertas de aceptación al trabajo nuevo; las excepciones de alto riesgo necesitarían un responsable y vencimiento. Las métricas semanales cubrirían defectos bloqueantes, tiempo de reparación, regresiones, cobertura manual y finalización de tareas; la comunicación mensual a clientes establecería el alcance soportado y los límites. El entregable es una gobernanza duradera, no un informe único de "escaneo aprobado".
Errores comunes
- Error: Tratar un escaneo automatizado al 100% como conformidad. → Por qué falla: Los escáneres pasan por alto el orden del teclado, la experiencia semántica y los bloqueos en las tareas. → Solución: Combinar la automatización con pruebas manuales, de tecnología asistiva y de usuarios.
- Error: Clasificar por conteo de defectos en lugar de por impacto en la tarea. → Por qué falla: Muchos problemas menores pueden ocultar un bloqueo crítico para iniciar sesión. → Solución: Evaluar tareas críticas, usuarios afectados y apalancamiento de la reparación.
- Error: Corregir únicamente las páginas nuevas. → Por qué falla: Las fallas compartidas se repiten a lo largo de todos los flujos de trabajo. → Solución: Reparar el sistema de diseño y los componentes antes de las excepciones en páginas individuales.
- Error: Prometer externamente que el producto es "totalmente accesible". → Por qué falla: Los estándares, la tecnología asistiva y el alcance no probado cambian continuamente. → Solución: Publicar el alcance de soporte, la evidencia, los límites y los canales de retroalimentación.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: Si la capacidad cubre solo una clase de problemas, ¿cuál elegirías?
Elegiría un problema compartido que bloquee la mayoría de las tareas críticas, como el envío mediante teclado o los errores perceptibles. Explicaría el balance con evidencia de usuarios, fechas contractuales y alcance de la reparación, y registraría el riesgo restante para el siguiente trimestre.
Pregunta de seguimiento 2: ¿Qué pasa si ingeniería argumenta que las auditorías manuales son demasiado lentas?
Utiliza la automatización para el triaje repetible y enfoca el tiempo manual en plantillas de alto riesgo y tareas reales. Ejecuta las correcciones de componentes y el muestreo en paralelo, y luego demuestra el valor a través de la tasa de descubrimiento, la tasa de regresión y la finalización de tareas en lugar de discutir sobre manual versus automatizado.
Pregunta de seguimiento 3: ¿La conformidad con WCAG equivale a seguridad legal?
No. WCAG es un estándar técnico; el alcance legal, las obligaciones contractuales y la interpretación tienen límites independientes. El área legal debe confirmar las obligaciones mientras que el estándar y la evidencia de los usuarios guían la prioridad del producto.
Pregunta de seguimiento 4: ¿Cómo previenes regresiones después de completar la hoja de ruta?
Haz que las líneas base de componentes, las revisiones en pull requests, el muestreo manual, las auditorías trimestrales, los responsables y el vencimiento de excepciones formen parte de la entrega habitual. El nuevo trabajo no puede pasar al lanzamiento estable sin la puerta de accesibilidad, a menos que exista una fecha de remediación aprobada.