A sample from similar comments in our accessibility audit:
Description: When navigating the 'Browse Collections' page using a screen reader and actuating the 'Sort By:' elements, an incorrect status message is made to the user that does not describe the new change made to the page.
Expected Results: A status message narrating the activated change in order of presented elements is made to the user such as "[Title] - Sort ascending" or an alternative with the same level of clarity.
Part of the problem is that our sorting and paginating require reloading the page. ARIA roles like "live" are assuming dynamic content that don't involve the page load, often javascript-driven solutions. It would be helpful to find a relevant precedent for our use case. Gov.uk has a write up on notification banners that offers a possible solution. They use [aria-role="alert"] on notifications, and their rationale for "reacting to something the user has done" feels like it fits what Omeka is doing on the public browse views when sorting.
A sample from similar comments in our accessibility audit:
Part of the problem is that our sorting and paginating require reloading the page. ARIA roles like
"live"are assuming dynamic content that don't involve the page load, often javascript-driven solutions. It would be helpful to find a relevant precedent for our use case. Gov.uk has a write up on notification banners that offers a possible solution. They use[aria-role="alert"]on notifications, and their rationale for "reacting to something the user has done" feels like it fits what Omeka is doing on the public browse views when sorting.