Accessible field labels in patron search and edit

[Terran McCanna]

All forms in the web staff client need to be checked to be sure they are labeled to reduce confusion when read by screen readers (JAWS, etc.)

Example: Patron Search form fields
There are some inconsistencies in how the fields are read depending on whether user is tabbing through the fields or using navigation arrows through the fields. Adding field names or labels might make the behavior more consistent.

Example: Patron Search Results row checkboxes
All of the checkboxes currently read as "Checkbox not checked select row" which doesn't differentiate them from each other in any way. Labels should be able to solve that problem.

Example: Patron Search Results navigation buttons
Three navigation buttons have titles that are read if tabbing through them in NVDA ("button start - button previous page - button next page"), but if using the arrow navigations they just read "button - button - button."

Example: Patron Edit form field labels
Field labels have <label> tags but they don't explicitly point to the fields they are associated with. Standard behavior would be for user to navigate to the First Name label and instead of reading just the label, it would read the label and the field contents (for example, NVDA would read "Clickable First Name edit has autocomplete Alexandra"). If user hit Enter, the cursor focus would go into the First Name field.

With the current form, when you navigate with NVDA it first reads "First Name" and then if you click again, it reads as "Edit Required has Autocomplete Alexandra." This makes a certain amount of sense if there is something in the field, but less sense when the field is blank because then the field just reads "Edit Required has Autocomplete".

If user is tabbing through the fields instead of using the arrows for navigation, you may get a lot of "Edit Required has Autocomplete" in a row without any indication what the fields are. If it was labeled correctly, tabbing to the field would read more like "First name edit has autocomplete Alexandra"

Read more at:
https://www.w3.org/WAI/tutorials/forms/labels/

[Jane Sandberg (sandbergja)]

Related bug in the public catalog: https://bugs.launchpad.net/evergreen/+bug/1735768

[Jane Sandberg (sandbergja)]

Another specific example where this would be helpful: in the Z39.50 screen, the checkboxes for the Z39.50 servers aren't associated with their labels. Associating the checkboxes with their labels would also allow catalogers to click on the label to check/uncheck the box, which would be handy.

[Mike Risher (mrisher)]

This task is large in scope and will involve web forms spread out over many completely different areas of Evergreen. It seems too complicated and involved for a single bug. In an effort to organize it, I've created a task to do an audit of all of evergreen (Bug #1887857) and have started creating new bugs for various sections that need work. If it's alright, I'm going to treat this bug, #1615800, as dealing solely with patron pages.

I've pushed a branch to address the various problems. Much new labelling has been added:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrisher/lp1615800-patron-accessibility

Please note that a few of the changes rely on edits to shared directives. Those edits are already done and can be found on bug #1887866.

re: Patron Search Results row checkboxes
The checkboxes as I found them are differentiated from each other. The reader says "Row 2", for example for the second row. Maybe someone improved them after this bug was created in 2016.

Some of the original bug report talks about how behavior is inconsistent with arrow keys vs. with tabs. I haven't been able to confirm this on my end. NVDA isn't letting me navigate at all with arrow keys. Maybe it behaved differently when this bug was written. If it's still an issue, please provide info on what screen reader you're using as well as specific examples of inconsistent behavior.

[Mike Risher (mrisher)]

Forgot to mark this one "pullrequest". This is ready for testing. Testing instructions:

1. You'll need a screen reader for testing. This seems to indicate a recent EG accessibility audit utilized JAWS version 18 and NVDA.

https://wiki.evergreen-ils.org/lib/exe/fetch.php?media=accessibility:evergreen_evaluation_report.pdf

2. Create a branch which has both changes to the shared directives (bug #1887866) and these changes to the patron pages (branch is in comment #3 above)

3. Test to see if the issues detailed above have been addressed. Places to test include Patron Search form fields, Patron Edit form field labels, Patron Search Results navigation buttons

[Mike Risher (mrisher)]

Re: the testing instructions for a screen reader

JAWS and NVDA are popular options. Instructions here: https://developer.paciellogroup.com/blog/2015/01/basic-screen-reader-commands-for-accessibility-testing/

If installing a screen reader isn't practical, Firefox can be used to test accessibility also. https://developer.mozilla.org/en-US/docs/Tools/Accessibility_inspector

[Terran McCanna (tmccanna)]

The new Firefox Accessibility Inspector is really handy at first glance, at least. In reviewing the Angular navigation bar, for example, it makes it really easy to see where things need to have keyboard focusability added.

[Terran McCanna (tmccanna)]

This includes a lot of good accessibility improvements to these two screens. There are still a few spots that could use work, but I will open separate bugs for those.

There were some minor merge conflicts as well, so I've resolved those and included my signoff here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1615800-patron-accessibility-signoff

[Terran McCanna (tmccanna)]

Pls ignore my last one in #7 - new attempt here:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1615800-patron-accessibility-rebase2-signoff

[Jane Sandberg (sandbergja)]

Good improvement! Thanks, Terran and Mike. Pushed to rel_3_6, rel_3_7, and master.