focus changes not working as intended in the staff catalog

Bug #2038548 reported by Galen Charlton
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

The Angular staff catalog code tries to set the focus to the first relevant form input whenever you navigate to a tab on the search page. However, this does not work consistently:

- when you navigate with an explicit searchTab URL parameter, it works - e.g., /eg2/en-US/staff/catalog/search?searchTab=term or /eg2/en-US/staff/catalog/search?searchTab=ident
- when you navigate to the search form via the menu, it doesn't work - no specific focus is set
- when you change from one tab to another in the search form, it doesn't work; the focus stays with the tab selector

Note that for the last point, there's an accessibility question: do we actually want the focus to be moved to the form input in that circumstance?

This bug reflects the TODO around line 178 of Open-ILS/src/eg2/src/app/staff/catalog/search-form.component.ts:

// TODO: sometime the selector is not available in the DOM
// until even later (even with setTimeouts). Need to fix this.
// Note the error is thrown from selectRootElement(), not the
// call to .focus() on a null reference.

Galen Charlton (gmc)
tags: added: angular staffcatalog
tags: added: ux-keyboard
Revision history for this message
Galen Charlton (gmc) wrote :

Bug 1951267 is related to this.

Revision history for this message
Stephanie Leary (stephanieleary) wrote :

We definitely should not move focus from the tab to the query field when the user has changed tabs. I think we should remove focusTabInput() from ngOnNavChange, and leave it on ngAfterViewInit.

Setting focus on the query input is an accessibility issue in general, because there are previous fields in that form (format, field, and matching operator). For screen reader users, this effectively fast-forwards the user past the first three fields without telling them that there's something behind them that might be useful.

We could rearrange the form so that the field we want to autofocus is always first.

We could also / alternatively create a user preference that we always check before autofocusing anything. I think assistive technology users might want to opt out of autofocus altogether. It might also be handy for people who use barcode scanners a lot -- note that there is an open question about whether we should autofocus on the primary action button in modal dialogs, bug 1826584, in order to let the user continue using the Space or Enter keys.

tags: added: ux-forms
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.