Tutoriales
Claude Opus 5.5: reparar el foco de diálogos de producto
Usa Claude Opus 5.5 para revisar un diálogo como una secuencia de estados del teclado: abrir, navegar, cerrar y volver.
Usa Claude Opus 5.5 para revisar un diálogo como una secuencia de estados del teclado: abrir, navegar, cerrar y volver. Un diálogo bien centrado puede dejar al comprador detrás de la capa o devolver el foco al principio de la página. Entrega el componente y un registro de foco para poder comprobar la reparación propuesta.
Definir el resultado de cada acción
| Acción | Resultado esperado | Prueba que registrar |
|---|---|---|
| Abrir especificaciones | El foco entra en contenido útil | Elemento activo tras abrir |
| Tab y Shift+Tab | El foco permanece en el modal | Primer y último control accesibles |
| Escape o Cerrar visible | El diálogo se cierra | Visibilidad y elemento activo posterior |
| Cerrar sin el activador original | El foco llega a un destino lógico | Destino alternativo y motivo |
El patrón de diálogo modal de W3C describe la navegación contenida y el retorno del foco, normalmente al elemento que lo abrió. Si desaparece, elige un destino lógico del proceso. Es un contrato de comportamiento, no una razón para añadir `aria-modal` a una capa que no funciona como modal.
Un recorrido para una ficha de producto
Imagina una página de una taza con un botón «Especificaciones», un diálogo largo y un botón «Añadir al carrito» fuera. Al abrir, enfocar un encabezado estático con `tabindex="-1"` puede ser mejor que saltar hasta el primer enlace lejano. El encabezado es un destino programático, no una parada adicional del Tab normal. En una confirmación breve puede convenir un control relacionado con la acción.
Anota el recorrido: Especificaciones → encabezado del diálogo → Cerrar → enlace de cuidados → Cerrar al completar el ciclo de Tab → Especificaciones tras Escape. El orden exacto depende del documento. Si un cambio de producto elimina el activador, registra una alternativa como el encabezado del nuevo producto o el siguiente control pertinente. No elijas un botón arbitrario solo para aprobar una aserción. Es un escenario ficticio, no una ejecución registrada de Opus.
Mantén un control visible para cerrar. Pulsar el fondo no sustituye una salida explícita ni el teclado. En una implementación nueva, revisa el elemento dialog nativo y `showModal()`. Con una biblioteca existente, conserva sus API de ciclo de vida y foco antes de añadir una trampa de foco propia que compita con ellas.
Un prompt de reparación completo
Revisa el ciclo de teclado de este diálogo de producto. Proporcionaré componente, versión de la biblioteca si existe, código del activador, CSS y recorrido del foco al abrir, avanzar con Tab, retroceder, pulsar Escape y Cerrar. Marca como desconocidas las pruebas de ejecución ausentes.
Crea una tabla de acción, foco esperado y foco observado. Separa fallos de foco inicial, contención, cierre y retorno. Explica si el destino inicial corresponde a contenido estático largo o a una acción breve. Conserva el nombre accesible, el cierre visible y la API del componente. No supongas que aria-modal vuelve inerte el fondo por sí sola.
Propón el cambio mínimo con la biblioteca actual o dialog nativo. Resuelve la eliminación del activador con una alternativa lógica explícita. Devuelve un parche y comprobaciones de teclado para cierre normal y desaparición del activador. No afirmes pruebas con tecnologías de asistencia sin un registro real ni sustituyas toda la interfaz sin justificar su necesidad.La guía oficial de Opus sirve de referencia para aportar contexto y requisitos explícitos. Se propone un método de revisión; no se afirma que el modelo haya superado estas comprobaciones.
Comprobar la vuelta, no solo la apertura
Ejecuta el recorrido con teclado en la aplicación real. Incluye aperturas repetidas, Tab inverso, el contenido más largo y una actualización que quite el activador. Comprueba la visibilidad del foco en cada paso. Que el diálogo exista en el DOM no demuestra que el fondo sea inaccesible ni que el foco vuelva correctamente. Registra versiones del navegador y de las tecnologías de asistencia en las pruebas que realmente realices.
Preguntas habituales
**¿Debe enfocarse siempre el primer botón?** No. Un contenido largo puede requerir un inicio estático; una confirmación destructiva puede favorecer la opción menos destructiva.
**¿Basta con cerrar al pulsar el fondo?** No. Mantén un control explícito y un recorrido de cierre con teclado adecuado y probado.
**¿Un recorrido automatizado certifica accesibilidad?** Detecta regresiones concretas, pero no reemplaza revisar nombres, orden de lectura y comportamiento real de tecnologías de asistencia.
Separar interacción y campaña
Cuando la página funcione, usa la imagen y el mensaje aprobados para crear variantes en Panelly Studio. Para fallos de envío, consulta el flujo independiente de recuperación de errores de formularios. Panelly es aquí un espacio creativo, no una integración afirmada con Opus.
