Keyboard walk reports complete when focus is trapped
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- playwright, typescript
- Área
- accessibility
Línea de trabajo
Start with cycle detection in src/providers/keyboard-walk/, where a repeated stop currently ends the walk as complete. Then open the real-browser tests /light-trap and /shadow-trap, which assert no findings for this trapped case. Done means a walk that loops back to an earlier stop without reaching the document body ends with a truncation gap, and those tests are updated to expect it. Whether to also add a separate WCAG 2.1.2 check is a design question to settle with maintainers first.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What happens
When keyboard focus is trapped in a group of controls, the keyboard walk ends as complete. It reports no finding and no gap. The controls after the trap are never reached, but the run reads as if the walk covered the page.
Example: a page with a focus trap around two buttons, followed by an "Outside" button. Tab moves between the two trapped buttons only. The walk sees a repeated stop, ends the cycle, and reports complete. "Outside" is never visited.
There is no keyboard trap rule in src.
Expected
A walk that returns to an earlier stop without passing through the document body has not covered the page. At minimum it should end with a truncation gap. A dedicated keyboard trap check (WCAG 2.1.2 No Keyboard Trap) would report it as a barrier.
Where
src/providers/keyboard-walk/(cycle detection)- The real-browser tests
/light-trapand/shadow-trapcurrently assert no findings for this case.
- Lenguaje dominante
- TypeScript
- Estrellas
- 0
- Forks
- 0
- Merge medio
- 8 h 39 min
- PR fusionados (30 d)
- 52
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de usabl-dev/usabl
-
area: engine enhancement performance
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
area: engine bug
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 1 día
-
area: engine bug
Dificultad 3/5 1-2 días Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
area: engine enhancement performance
Dificultad 4/5 1-2 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
Todos los issues de usabl-dev/usabl
Issues similares
-
Cleanup SetupPosiblemente ocupada @AlexanderKaran la tomó hoy. Abiertodocumentation enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
e18e/framework-tracker#769 ·
Los mantenedores suelen responder en 1 día
-
fix(docker): correct stale --db-path comments in fetch/git Dockerfiles and clarify git READMEAbiertobug v2
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
modelcontextprotocol/servers#5483 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 84/100
XiaomiMiMo/MiMo-Code#2783 ·
Los mantenedores suelen responder en 1 día
-
area: web bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
kinqsradio/orbyn-engineering#227 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
joeldesante/TurfBuilder#258 ·
Los mantenedores suelen responder en 1 día