Edit File Modal Keyboard Trap
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- angular, bootstrap, typescript
- Área
- accessibility, frontend
Línea de trabajo
Start by locating the Angular upload-item and upload-person edit-file modal components described in the issue, and check related issue #5502 for context. Reproduce the focus behavior in Safari with UVA-only or Embargo selected, then inspect the modal’s existing focus and dismissal handling. Done means keyboard focus enters and stays within the open modal, returns to its trigger on close, the dialog has an accessible name, and Escape still closes it.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
@lgeggleston
Issue reported by University of Virginia (UVA) Library’s Assessment, Communications, and User Experience (ACE) team as part of internal DSpace 9 accessibility audit.
Issue 1 of 2: Edit File Modal Keyboard Trap
Describe the bug
Specifically in Safari, when the modal opens, keyboard focus is not properly managed. Users can tab out of the modal into background content and cannot tab back in, creating a functional keyboard trap. It appears to happen when UVA only or Embargo are selected. This violates the required modal dialog behavior defined in WCAG: Users must be able to move focus into and out of components using only the keyboard. The modal currently allows focus to escape but not return. When the modal appears, focus must move into it and remain within it until dismissed, preserving logical interaction order. The modal container lacks an accessible name via aria-labelledby, which can cause AT/browser combinations to incorrectly handle dialog focus. This issue blocks users from interacting with or closing the modal using keyboard-only navigation, making the modal inoperable for many users. Also affects: 2.1.2 No Keyboard Trap (Level A), 2.4.3 Focus Order (Level A), 4.1.2 Name, Role, Value (Level A)
Page
Upload Item (Form)
WCAG Guideline
WCAG 2.1.1, 2.1.2, 2.4.3, and 4.1.2
To Reproduce
Relevant code
Start of code: \<ngb-modal-window role="dialog" tabindex="-1" aria-modal="true" class="d-block modal fade show"\>\<div role="document" class="modal-dialog modal-xl"\>\<div class="modal-content"\>
Expected behavior
Move focus into the modal when it opens: Focus has to move to the first meaningful control immediately when the modal appears. This is usually the close button, but can also be the first field. Trap focus inside the modal while it is open: Tab and Shift+Tab have to move only within the modal elements. The background content shouldn't receive focus. Ensure the modal has an accessible name Add an id to the title and reference it via aria-labelledby on the modal container Return focus to the button that opened the modal when it closes Retain the current functionality of closing modal by pressing Esc
Suggested fix / example code
Adding accessible name: \<ngb-modal-window role="dialog" aria-modal="true" aria-labelledby="edit-file-title" tabindex="-1"\> \<div class="modal-dialog modal-xl"\> \<div class="modal-content"\> \<div class="modal-header"\> \<h4 id="edit-file-title" class="modal-title"\>Edit file\</h4\> \<button type="button" class="btn-close" aria-label="Close"\>\</button\> \</div\> \<!-- modal body --\> \</div\>\</div\>\</ngb-modal-window\> Please note: the Javascript below are examples, but I didn't dive into the JS. The general functionality of what should be happening should hopefully be clear enough that you can make edits as needed. Move focus into modal when opened: // Called when opening the modal ngAfterViewInit() { const closeBtn = this.elementRef.nativeElement.querySelector('.btn-close'); (closeBtn || this.elementRef.nativeElement).focus();} Trap focus into modal: @HostListener('keydown', ['$event']) handleTabTrap(event: KeyboardEvent) { const focusableSelectors = [ 'button:not([disabled])', '[href]', 'input:not([disabled])', 'select:not([disabled])', 'textarea:not([disabled])', '[tabindex]:not([tabindex="-1"])' ]; const modal = this.elementRef.nativeElement; const focusable = Array.from(modal.querySelectorAll(focusableSelectors)); const first = focusable[0]; const last = focusable[focusable.length - 1]; if (event.key === 'Tab') { // Shift + Tab if (event.shiftKey && document.activeElement === first) { event.preventDefault(); last.focus();} // Tab forward else if (!event.shiftKey && document.activeElement === last) { event.preventDefault(); first.focus();}}} Restore focus on close: // Before opening the modal storeTrigger(triggerElement: HTMLElement) { this.triggerEl = triggerElement;} // On modal close ngOnDestroy() { this.triggerEl?.focus();}
Issue 2 of 2: Edit File Modal Keyboard Trap
Describe the bug
Specifically in Safari, when the modal opens, keyboard focus is not properly managed. Users can tab out of the modal into background content and cannot tab back in, creating a functional keyboard trap. It appears to happen when UVA only or Embargo are selected. This violates the required modal dialog behavior defined in WCAG: Users must be able to move focus into and out of components using only the keyboard. The modal currently allows focus to escape but not return. When the modal appears, focus must move into it and remain within it until dismissed, preserving logical interaction order. The modal container lacks an accessible name via aria-labelledby, which can cause AT/browser combinations to incorrectly handle dialog focus. This issue blocks users from interacting with or closing the modal using keyboard-only navigation, making the modal inoperable for many users.
Page
Upload Person (Form)
WCAG Guideline
WCAG 2.1.1, 2.1.2, 2.4.3, 4.1.2
To Reproduce
Relevant code
Start of code snippet: \<ngb-modal-window role="dialog" tabindex="-1" aria-modal="true" class="d-block modal fade show"\>\<div role="document" class="modal-dialog modal-xl"\>\<div class="modal-content"\>\<ds-submission-section-upload-file-edit \_nghost-dspace-angular-c3076456883=""\>\<div \_ngcontent-dspace-angular-c3076456883=""\>\<div \_ngcontent-dspace-angular-c3076456883="" class="modal-header"\>\<h4 \_ngcontent-dspace-angular-c3076456883="" class="modal-title"\>Edit file\</h4\>\<button \_ngcontent-dspace-angular-c3076456883="" type="button" aria-label="Close" class="
Expected behavior
Move focus into the modal when it opens: Focus has to move to the first meaningful control immediately when the modal appears. This is usually the close button, but can also be the first field. Trap focus inside the modal while it is open: Tab and Shift+Tab have to move only within the modal elements. The background content shouldn't receive focus. Ensure the modal has an accessible name Add an id to the title and reference it via aria-labelledby on the modal container Return focus to the button that opened the modal when it closes Retain the current functionality of closing modal by pressing Esc
Suggested fix / example code
Adding accessible name: \<ngb-modal-window role="dialog" aria-modal="true" aria-labelledby="edit-file-title" tabindex="-1"\>\<div class="modal-dialog modal-xl"\>\<div class="modal-content"\>\<div class="modal-header"\>\<h4 id="edit-file-title" class="modal-title"\>Edit file\</h4\>\<button type="button" class="btn-close" aria-label="Close"\>\</button\>\</div\>\</div\> \</div\>\</ngb-modal-window\> Please note: the Javascript below are examples, but I didn't dive into the JS. The general functionality of what should be happening should hopefully be clear enough that you can make edits as needed. Move focus into modal when opened: // Called when opening the modal ngAfterViewInit() { const closeBtn = this.elementRef.nativeElement.querySelector('.btn-close'); (closeBtn || this.elementRef.nativeElement).focus();} Trap focus into modal: @HostListener('keydown', ['$event']) handleTabTrap(event: KeyboardEvent) { const focusableSelectors = [ 'button:not([disabled])', '[href]', 'input:not([disabled])', 'select:not([disabled])', 'textarea:not([disabled])', '[tabindex]:not([tabindex="-1"])' ]; const modal = this.elementRef.nativeElement; const focusable = Array.from(modal.querySelectorAll(focusableSelectors)); const first = focusable[0]; const last = focusable[focusable.length - 1]; if (event.key === 'Tab') { // Shift + Tab if (event.shiftKey && document.activeElement === first) { event.preventDefault(); last.focus(); } // Tab forward else if (!event.shiftKey && document.activeElement === last) { event.preventDefault(); first.focus(); } }} Restore focus on close: // Before opening the modal storeTrigger(triggerElement: HTMLElement) { this.triggerEl = triggerElement;} // On modal close ngOnDestroy() { this.triggerEl?.focus();}
Related work
- Lenguaje dominante
- TypeScript
- Estrellas
- 180
- Forks
- 577
- Merge medio
- 2 d 12 h
- PR fusionados (30 d)
- 111
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la 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 DSpace/dspace-angular
-
affects: 10.x affects: 9.x bug component: submission Difficulty: Low help wanted ux
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
DSpace/dspace-angular#6412 ·
Los mantenedores suelen responder en 3 días
-
accessibility affects: 10.x affects: 8.x affects: 9.x bug help wanted ux
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DSpace/dspace-angular#6364 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
Author browse links on item page open in a new tab, unlike other browse linksPosiblemente ocupada @jesielviana la tomó hace 18 días. Abiertoaffects: main bug component: Item low priority
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
DSpace/dspace-angular#6268 · 4 comentarios · 1 asignado ·
Los mantenedores suelen responder en 3 días
-
Mathjax single dollar sign delimiter configuration causes unintentional math rendering in abstractsAbiertobug needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
DSpace/dspace-angular#6263 ·
Los mantenedores suelen responder en 3 días
-
UI spacing regression on ds-generic-item-page-field (extra spaces around metadata values) in v10.xAbiertoaffects: 10.x affects: main bug component: Item ux
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
DSpace/dspace-angular#6254 · 1 comentario ·
Los mantenedores suelen responder en 3 días
Todos los issues de DSpace/dspace-angular
Issues similares
-
Plugin: sheet music can't be scrolled by hand before playbackPosiblemente ocupada @snakajima la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
receptron/jinglescript#51 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 9 días
-
clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster P3
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
openclaw/openclaw#186424 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
chore(worker): five module header comments describe the code from before later issues changed itAbiertoarea:dev U2-later
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
bentleypark/aiwatch#1824 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Pal-AI-Lab/Coopanion#469 ·
Los mantenedores suelen responder en 1 día