❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.
Target branch: develop
Observed behavior
Some observations after testing the keyboard navigation and screen reader output on the asset from #14788:
-
When using the Skip to main content link upon page load, focus lands on the Your library heading level 1, thus effectively bypassing the whole new search bar experience. That was appropriate for the old Library page design, but now the focus should, instead, land on the actual main landmark so the next interactive element in the Tab order is the search bar 🙂
-
Starting to type the search term in the field has good SR output, informing correctly about the number of possible matches that appear in the dropdown list, which are navigable with arrow keys and properly announced. What needs improvements is after the user selects one of those matches: page reloads and all the screen reader user hears is the (not very helpful) page title Learn document, while the focus has been returned to the top of the page.
What should have been communicated to the user through the SR output instead (for the scenario in the screenshot) is:
- Informing them that the filtering with the selected match has been performed.
- Page title should change to
More than 25 results for 'School', to give the proper context.
- Focus should land to the page main heading H1 (right now it is H2), which should be identical to the page title.
Screen reader output should be something like:
School 1 of 6
# user presses Enter to apply the match
Selected filtering match applied
More than 25 results for 'School' document
main landmark More than 25 results for 'School' heading level 1
# next in the Tab order is the first search result resource
-
The use of the button elements to represent the pills is a problematic one from the semantic point of view, as it gives no input to the SR user about their state, that is if/when those are already been selected and filtered the results by. Sighted user can see the visual difference between the 2 states, but look at the SR output after navigating through 4 selected pills, user has no information to conclude that those filters have already been applied and that they can unapply if they choose so.
The more semantically appropriate element to be used here is the checkbox (same discussion we were having for the picture login page), as it natively informs the user about its state (checked/unchecked), so they instantly know which filter matches have been applied. Style them as buttons if we must, but they should be checkboxes, not buttons.
Context
AI usage
None
❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.
Target branch:
developObserved behavior
Some observations after testing the keyboard navigation and screen reader output on the asset from #14788:
When using the Skip to main content link upon page load, focus lands on the Your library heading level 1, thus effectively bypassing the whole new search bar experience. That was appropriate for the old Library page design, but now the focus should, instead, land on the actual
mainlandmark so the next interactive element in the Tab order is the search bar 🙂Starting to type the search term in the field has good SR output, informing correctly about the number of possible matches that appear in the dropdown list, which are navigable with arrow keys and properly announced. What needs improvements is after the user selects one of those matches: page reloads and all the screen reader user hears is the (not very helpful) page title Learn document, while the focus has been returned to the top of the page.
What should have been communicated to the user through the SR output instead (for the scenario in the screenshot) is:
More than 25 results for 'School', to give the proper context.Screen reader output should be something like:
The use of the
buttonelements to represent the pills is a problematic one from the semantic point of view, as it gives no input to the SR user about their state, that is if/when those are already been selected and filtered the results by. Sighted user can see the visual difference between the 2 states, but look at the SR output after navigating through 4 selected pills, user has no information to conclude that those filters have already been applied and that they can unapply if they choose so.The more semantically appropriate element to be used here is the
checkbox(same discussion we were having for the picture login page), as it natively informs the user about its state (checked/unchecked), so they instantly know which filter matches have been applied. Style them as buttons if we must, but they should be checkboxes, not buttons.Context
AI usage
None