Icons in staff client menu bars should be hidden from screen readers

[Jane Sandberg]

Font awesome (and several other sources) recommend that decorative icons, such as the ones in the AngularJS and Angular navbars, have the aria-hidden attribute affixed to them, to indicate to screen readers that it's safe to skip reading those icons to the user.

In 3.2 release candidate, neither the Angular nor the AngularJS navbar has icons with those aria-hidden attributes.

[Mike Risher (mrisher)]

Jane, I wanted to clarify the work. By navbar, are you referring to the dark green top nav on all pages? (See attached screenshot)

The home icon on the far left and the icon on the far right shouldn't be hidden, because there is no text associated with them and they have useful functionality. That leaves only the downward pointing arrows after "Search", "Circulation", etc. (class="caret" in the HTML). Is that what you're saying we should apply aria-hidden to? Or perhaps I'm missing something?

[Jane Sandberg (sandbergja)]

Oh, good clarification, Mike! Once you open up one of the navbar menus, it's all the little icons on each of the entries. For example, if you open up the Cataloging menu, there are icons next to the entries for "Search the catalog", "Item status", etc.

If you look at the accessibility tree to inspect some of these entries, they are a little weird. On the Angular side, for example, there are entries called "question_answer Item Status", "redoRetrieve Last Bib Record", "format_paint MARC Batch Edit", etc.

[Mike Risher (mrisher)]

I applied aria-hidden="true" to 69 icons in the navbar. I intentionally didn't apply it to the far left and far right icons (home and list) because there is no other text associated with them.

Branch here:

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

Re-reading the original description, there is a reference to an Angular JS navbar. I'm thinking that's something that was around in 2018 but not currently? If I'm missing anything, please let me know and I'm happy to address it.

[Galen Charlton (gmc)]

> Re-reading the original description, there is a reference to an Angular
> JS navbar. I'm thinking that's something that was around in 2018 but not
> currently? If I'm missing anything, please let me know and I'm happy to
> address it.

No, it's still there, as a good portion of the web staff interface still
uses AngularJS. The relevant file that also needs to be updated is
Open-ILS/src/templates/staff/navbar.tt2.

[Mike Risher (mrisher)]

Thanks for that, Galen. I went in and made the same changes to the Angular JS navbar. 82 icons were modified. The branch is the same as before:

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

[Terran McCanna (tmccanna)]

Hi Mike - I am getting a conflict error when I try to cherry-pick this to current master. Can you take a look?

[Mike Risher (mrisher)]

I cherry picked this and pushed a branch with the latest code.
Looks like the conflicts were due to some minor changes on the navigation. For example, on the latest master there are 2 different options "Search the Catalog" and "Search the Catalog (Traditional)"

Branch here:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrisher/lp1795720-navbar-accessibility-aug-14-2020

[Rogan Hamby (rogan-hamby)]

I went to test this and discovered that MacOS voice over actually doesn't read the menus at all, which is unfortunate so I can't test this. Another screen reader like JAWS or MS's Narrator may still be useful for testing.

But that made me question my testing assumption. I don't think we've ever explicitly said what screen readers we would try to support so I don't know what our minimum qualification for testing here is. If it's just "they are aria hidden and it doesn't cause conflicts" that's one thing (I'll be glad to test for that) or are we seeing if they work with some list of screen readers such as Narrator and Voice Over?

This may ultimately be a wider discussion but if what we're testing just on this bug is the aria-hidden attributes I'll be glad to take another look and sign off if appropriate.

[Mike Risher (mrisher)]

re: screen readers 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

Personally I've been testing accessibility issues with NVDA / Windows 10.

[Mike Risher (mrisher)]

Here are improved testing instructions:

You'll need a screen reader for testing. JAWS and NVDA are popular options. Instructions for using them 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)]

I think more accessibility reviews are in order and the tools above are an excellent place to start - a quick look at the new Firefox Accessibility Inspector identified some focusability issues with the navigation menus that should be addressed.

However, for the purposes of moving this bug forward in the meantime, I have tested this patch and confirmed that the aria-hidden attribute does appear on both the old and new navigation menu items.

My sign off is at:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mccanna/lp1795720-navbar-accessibility-aug-14-2020-signoff

[Galen Charlton (gmc)]

Tested and pushed to master, rel_3_5, and rel_3_4. Thanks, Mike and Terran!