[Deque Analysis] Search Results "serious" accessibility issues

[tdonohue]

Serious: This issue results in serious barriers for people with disabilities, and will partially prevent them from accessing fundamental features or content. People relying on assistive technologies will experience significant frustration as a result. Issues falling under this category are major problems, and remediation should be a priority.

Deque Analysis Summary

Search results page has a total of 10 "serious" accessibility issues (not including color contrast issues which are in other tickets):

1. (IDs: 468496, 468497) "ARIA input fields must have an accessible name" (on both of the Date range slider bars). An aria-label or aria-labelledby attribute should exist, or element needs a title.
2. (ID: 468900) "Selected/Active state of the element is missing. The selected state of an element is not conveyed to screen reader users." (This occurs on the list/grid view selectors in the top right.) Should be fixed by adding aria-current=true on the currently selected option. See also https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/current/
3. (ID: 468919) "The element functions as if it has two roles. Elements are allowed to have only one functioning role." (on all Facet values / checkboxes in sidebar).
   • "As of now, these checkboxes are wrapped within the anchor, hence the same element is announcing both link and checkbox roles and receiving focus twice, which result in a tab stop too."
4. (ID: 468937) "Button does not have a role" (for all expand/collapse +/- buttons in filter headers). These should either be literal <button> tags, or have a role="button" (or similar role) defined.
5. (ID: 468945) "Non-decorative content is inserted using CSS pseudo elements" (for the same expand/collapse +/- buttons in filter headers ... see previous issue as well).
   • RULE : Non-decorative content MUST NOT be inserted using CSS :before and :after pseudo-elements unless there is a way to access the content with CSS turned off.
   • HOW TO FIX: Fix this issue by including the content directly in the DOM using HTML.
6. (ID: 468959) "Hidden element receives focus" occurs on ALL checkboxes in the filters section. "These elements are receiving focus even it is visually hidden on the screen." To solve this, we need to make sure they don't receive focus when a filter section is collapsed
7. (ID: 469022) Temporary status message "Loading search results..." is not announced to screen readers.
   • Fix this issue by using ONE of the following techniques: (1) Set focus to the interstitial message: https://dequeuniversity.com/class/dynamic-updates2/notify-users/move-focus OR (2) Announce the interstitial message via an ARIA live region: https://dequeuniversity.com/class/dynamic-updates2/notify-users/aria-live
   • NOTE: This same issue obviously occurs anywhere we have a "Loading..." type of message, so we should fix this in the ds-loading tag generally for the entire app (e.g. other locations include IDs 469378, 470258, 470325, 470753)
8. (IDs 469023, 469026) "Programmatic label does not convey purpose of control." occurs in two places:
   • First, on the little "x" displayed on a selected filter (the "x" that allows you to remove that filter when it appears below the search box). Current name is "x", but it should be renamed to say "clear".
   • Second, on the date range links (which you can click on to quickly filter by a specific date range). The links need be named something like "Filter by date range [x - y]". Currently they have no label.

Full list of issues is viewable at (requires login): https://axeauditor.dequecloud.com/test-run/0856438a-a19a-11eb-bc31-b7d5be387c86/issues?activeTab=dt-issue&page=0&pageSize=50&sortField=ordinal&sortDir=asc&row=9&filter%5Bseverity%5D=3&filter%5Btype%5D=issue&filter%5Bpage_number%5D=1

Related work

Related also to #1168 (other Search Results issues), but this ticket is slightly lower priority.

More Information / Tools

• Consider using Deque's free Chrome plugin to check your work

[tdonohue]

@artlowel : Assigning this to you for analysis, as it's related to #1168 , but is the lower priority issues on the same page.

[Andrea-Guevara]

Hi @tdonohue, I'm Andrea Guevara, part of Neki-it. I analyzed item 7 with ID: 469022 of this issue with a screen reader and noticed that NVDA does identify the loading message... when it is shown. Even so, we can improve the accessibility of the component by using attributes such as aria-live=“polite” and aria-hidden=“true”. If it's interesting, I'd be happy to make these changes to the component.

[tdonohue]

@Andrea-Guevara : Thanks for that analysis/feedback. It does seem reasonable to me to improve the accessibility via aria-live and aria-hidden. So, if you find time to create a Pull Request for that, it would be appreciated.

[Andrea-Guevara]

@tdonohue Thanks for the feedback! request pull done. https://github.com/DSpace/dspace-angular/pull/3099

[tdonohue]

I've revisited this ticket today, and the only remaining issue is:

(ID: 468919) "The element functions as if it has two roles. Elements are allowed to have only one functioning role." (on all Facet values / checkboxes in sidebar). "As of now, these checkboxes are wrapped within the anchor, hence the same element is announcing both link and checkbox roles and receiving focus twice, which result in a tab stop too."

When testing the Search interface with a basic Chrome screen reader, I found that the checkboxes are announced but not the links. Focus only occurs on the checkbox. This behavior occurs both on demo.dspace.org (running pre-7.6.2) and sandbox.dspace.org (running pre-8.0)

This appears to solve the primary issue in 468919.

Therefore, I'm closing this ticket as all issues appear to be resolved in 7.6.2 and 8.0