Open hostle83 opened 2 months ago
Good afternoon @tdonohue and @hostle83! My name is Andrea and I'm part of the Neki-it company. We studied this issue and thought of several possibilities to solve the problem.
Would the focus be on users who use assistive technologies? If so, we thought that using the “aria-live” attribute would help, as it indicates that a certain region of the page will be updated and describes the type of update that users can expect from that region. Reference: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-live
Another possibility would be to create an alert or confirmation modal that appears every time the search filter is selected. But this would reflect in a general sense, not just for users who make use of assistive technologies.
We would like to contribute to resolving this issue. We look forward to your feedback.
@Andrea-Guevara : Yes, the focus of this ticket is on users who use assistive technologies. But, it also can be seen as "odd" to any user that the entire page reloads anytime you change a search filter.
While I'm not against an aria-live
idea, I think it might be best to first investigate whether we can fix this problem by ensuring the page does not reload when you select/deselect a search filter. This is similar to how we fixed #3094 (which is a similar bug with the date slider). See the fix in #3236 , which was to update the date slider to no longer reload the page.
So, my preference would be to see if we can just stop reloading the entire page each time a filter is selected/removed. If there's no way to achieve that, we could consider an aria-live
.
If you'd still like to claim this, let us know.
Good afternoon @tdonohue!
I've been doing some tests to avoid reloading the search page when clicking on a filter option but I understand that this reload is necessary to update the url and bring the filter results.
I think I understood what was done on the date with the “submit” button; the user chooses a date and clicks the button, where the result is brought up without reloading the page. But if the user clicks on the date suggestions offered by DSpace, the reload will still happen.
Even with a similar implementation, the accessibility problem would remain. Generally, users who make use of assistive technology use the keyboard to reach their target, in this case the filter. And if they click on any suggestion in the filter, the page will reload without warning.
@Andrea-Guevara : I see. As noted, if we need to go with an aria-live
option, we can do so. I'm not against that. I just wanted to make sure there was not a way to achieve this similar to #3236
One thing to be aware of here is that we've found other needs for aria-live
, and so there's now a generic "Live Region" sevice & component that was just merged today in #3337. So, if you find that useful, it could be used in this scenario as well. See #3337 for more info, and feel free to ask questions there if you have questions about usage.
Describe the bug According to WCAG 2 Success Criterion: 3.2.2 On Input (A), users should be warned before a change of context occurs on a site. Currently, any change to a search filter selection reloads content and the page and there is no announcement to a screen reader user (exception: date range filter, this has been updated, see https://github.com/DSpace/dspace-angular/issues/3094) See https://www.w3.org/WAI/WCAG21/Understanding/on-input.html for reference.
To Reproduce Steps to reproduce the behavior:
Expected behavior Either warn the user of the change of context (reload) beforehand, or give the user to activate the change themselves by providing a button or similar functionality
Related work https://github.com/DSpace/dspace-angular/issues/3094