Web Staff Client - Accessibility and Button Placement

Bug #1615805 reported by Terran McCanna
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Committed
Medium
Unassigned

Bug Description

Users expect submit buttons to be at the end of forms, and users utilizing screen reading software face greater issues when they are located elsewhere.

It may be possible to add additional submit buttons that are only readable by screen readers at the end of forms to accommodate users that require screen reading software.

Example: Patron Search form Search & Clear Form buttons
The buttons are in the middle of the form instead of at the end of the form. They are read directly after the middle name field, so if the user is just searching by name it is fine, but if the user goes beyond the name fields to search by barcode or username or some other field, it is not clear how to get back to the search field.

Example: Patron Edit form Save and Save & Clone buttons
The buttons are in line before the form fields begin, and since the autofocus goes to the first open field, when the user completes the form, there isn't a Save button at the bottom, and they have to either cycle through all of the other page elements first or search for the button using their navigation search tools.

Revision history for this message
Eva Cerninakova (ece) wrote :

I have tested the patron edit form using the NVDA and I can confirm the problem.

Beside the issue described by Terran I have also found, that when jumping by the active elements of the screen (fields, links etc.) using TAB key or screen reader shortcut in the Patron Edit form interface, the Copy/Print links related to the Mailing address in the "Patron summary display" appear between the "Save & clone" button and the "OPAC/Staff Client User Name" field. It is confusing by my opinion as the user don't know, what are the Copy/Print links related to. It would be at least useful to add the title to both links, to inform the user that those links are related to the Mailing address.

Andrea Neiman (aneiman)
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Eva Cerninakova (ece) wrote :

This bug is related to the bug 1818904.

tags: removed: webstaffclient
Changed in evergreen:
assignee: nobody → MaryAnn Alexander (maryann-alexander)
Revision history for this message
Kyle Huckins (khuckins) wrote :

MaryAnn and I have been investigating which UIs are affected, with a focus on Angular-specific interfaces. Branching these out into manageable bug reports, so we can address these more quickly:

Patron Search (Angular): https://bugs.launchpad.net/evergreen/+bug/1950500
Providers Administration (Angular): https://bugs.launchpad.net/evergreen/+bug/1950507
Grid UIs (Angular): https://bugs.launchpad.net/evergreen/+bug/1950509
Record Editor (Angular): https://bugs.launchpad.net/evergreen/+bug/1950510

Patron Edit (AngularJS): https://bugs.launchpad.net/evergreen/+bug/1950502
Serials Template (AngularJS): https://bugs.launchpad.net/evergreen/+bug/1950505

tags: added: ux-buttons
Revision history for this message
Diane Disbro (ddisbro) wrote :

3.9
Related to this issue is the inability to click Save in both Register Patron and Edit when a message informing staff that XXX number of patrons have the same phone number touches the bottom of the Save button. Staff need to scroll down a little so that the Save button doesn't touch the message in order to be able to activate the Save function.

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

Here is a branch that rearranges the DOM order of buttons for the patron search form in both Angular and AngularJS: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sleary/LP1615805-patron-search-button-placement

This uses CSS Grid layout (https://wiki.evergreen-ils.org/doku.php?id=newdevs:grid) rather than Flexbox. Grid allows us to specify exactly where elements should go, which means we can place the buttons after all the form fields but still place them in the upper right corner. I've included styles to turn off the grid below certain breakpoints, which should make this form more usable on smaller screens.

To be clear, this is intended as an accessibility band-aid, and a temporary measure on the path to revamping this form entirely.

To test, tab through the form fields. You should skip over the search and clear buttons at first, and reach them only after you've cycled through all the inputs. (This will be a little odd for sighted keyboard users, but the improvement for screen reader users is worth the trade-off in this case.)

tags: added: pullrequest
Andrea Neiman (aneiman)
Changed in evergreen:
assignee: MaryAnn Alexander (maryann-alexander) → nobody
Revision history for this message
Eva Cerninakova (ece) wrote :

I have tested this on https://bugsquash.mobiusconsortium.org/ and I can confirm that the button placement works as expected, i.e., I can only reach buttons "Search" and "Clear form" after going through all search form field.

Revision history for this message
Eva Cerninakova (ece) wrote :

I have additionally tested the problems described in comments #2 and #4, and I can confirm that both are no more an issue.
I consent to signing off on it with my name, Eva Cerniňáková and my email address, <email address hidden>.

Galen Charlton (gmc)
tags: added: signedoff
Blake GH (bmagic)
Changed in evergreen:
assignee: nobody → Blake GH (bmagic)
Revision history for this message
Blake GH (bmagic) wrote :

Thank you Stephanie! Pushed to main!

Changed in evergreen:
milestone: none → 3.13-beta
assignee: Blake GH (bmagic) → nobody
status: Confirmed → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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