Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search overlay: Improve accessibility #9035

Merged
merged 5 commits into from
Dec 2, 2020
Merged

Search overlay: Improve accessibility #9035

merged 5 commits into from
Dec 2, 2020

Conversation

BatJan
Copy link
Contributor

@BatJan BatJan commented Oct 2, 2020

Prerequisites

  • I have added steps to test this contribution in the description below

Description

I have been wanting to take a stab at this forever since reading this wonderful article https://nolanlawson.com/2019/11/05/what-ive-learned-about-accessibility-in-spas/ on my way home from #umbUkFest10 ❤️

It's the part under the headline "The final boss: accessible autocomplete", which inspired me to improve the search feature in the backoffice.

However due to how the search results are currently wrapped I'm not able to add the parts including the use of ´aria-activedescendant´ and the parts about role="option" so that's been omitted for now since I think it needs to be addressed in another PR - Unless @MMasey for or another brilliant person with BE skills is able to figure out if the data we get returned from the API call to /umbraco/backoffice/UmbracoApi/Entity/SearchAll could be changed around so we get all the results in one go but still with the ability to make a distinction between the categories etc. or maybe we can flatten the data we already receive in the FE somehow that I have not thought yet - It's something I would be happy to discuss at least :-)

Ok, enough chatter - The following improvements have been made with this PR and they can stand alone as is

  • Added role="dialog", aria-describedby and aria-labelledby attributes along with a sr-only section containing the sreen reader friendly title and description, which are required for dialog's, which the search overlay is 😃
  • Added a relationship between the search <input> and the <div> containing the search results using ´aria-owns´, which is used when a normal parent/child markup relationship is not possible to achieve. This attribute connetcs the two by using the id search-results
  • Exposing whether or not the search is "expanded" / has results so to speak by adding ´aria-expanded´
  • Added the ´aria-autocomplete="list"´ letting screen readers know that autosuggests will happen and appear in a list
  • Added a description about how to navigate the list for screen readers only and adding the ´aria-describedby´ attribute on the input field
  • Removed the tabindex="-1" attribute on the clear button since we need to be able to tab to it in order for it to be accessible. It's an extra step before tabbing into the results but I think we will cope! Besides it's nice to tab to the clear button first incase you just want to cleae the search field 👼
  • Added aria-hidden="true" to the <div class="umb-search-group__title"> since another sr-only text have been added to announce where the item was found since the umb-search-group__title makes sense in a visual context the screen reader is not picking up the name when tabbing / navigating back and forth using the up/down arrow keys. Hence this change
  • Finally I have changed the <i> to <umb-icon> thoughout the view

Ok, so a lot of stuff going on here - It's by purpose I have not added the umb-focus.lock directive since it does not handle adding focus on elements that are not there initially - This will be improved in the #8522 PR - Once it's done this view will need it too 😃

Copy link
Contributor

@nathanwoulfe nathanwoulfe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And again with the lovely work @BatJan
Same as the last one too - I fixed up the language conflicts, but otherwise all good.

Interested to hear too what would need to change in the search result data structure, it should be possible to modify the shape on the client, but might be more efficient to do so server-side...

🎅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants