[Support request] Search input focus

[Steven]

A few items related to search we think we’ve run in to:

1) Focus – when choosing the search icon to open the search bar, the focus doesn’t automatically get placed on the search input field. This is for keyboard (on Enter key), mouse click, or touch on mobile. It would be great if focus was given when the search icon is selected. This may also solve the issue of using the keyboard to tab to the search icon, pressing enter, having the search input box displayed, but the next tab key press takes focus away from the search bar entirely. You have to use Shift + Tab to get to the search input field after opening the search bar with the Enter key which isn’t intuitive.

2) When you enter a search term and press the Esc key or click/touch the close search X to quite search, the last search terms are not cleared from the search input. If Search is activated again on the same page, it requires you to delete the previous terms before searching again. It also reads back the search terms when the search input box receives focus with screen readers.

3) Might consider adding role=”search” attribute to the search <form> tag. https://www.w3.org/TR/wai-aria-practices/examples/landmarks/search.html

4) Maybe look at the behavior of the search icon that changes when it’s toggled back and forth so screen reader users have a better understanding of what the search icon will do in its different states. https://www.smashingmagazine.com/2017/09/building-inclusive-toggle-buttons/

[Tom]

Awesome feedback, thank you!

1. This should happen by default. For example, check out the navigation search here: https://gpsites.co/marketer/

2. This has been brought up a few times. I’m going to get it done in GP 2.4.

3. Will read up one this.

4. Can you explain a bit more here? Not too sure what I should be looking for.

Thanks again!

[Steven]

#1 – found the culprit. Was reusing a bit of CSS from the internet for styling the search box and it was causing an issue with focus landing on the search input field somehow. Sorry for the false report.

#2 Great!

#3 There may be several places in the theme roles could be used. We tried implementing them in our current site. If you search on “role” in the page source, it may give you an idea of how we used it. For example, navigation, menubar, menu, menuitem, search, main, region (footer). In combination with aria-label it can provide a better screen reader/navigation experience. https://www.w3.org/WAI/PF/aria/roles#landmark_roles

#4 Look at using aria-label and modifying it using JavaScript based on the state of the button. This will allow the button to be read by screenreaders when it receives focus and still make sense. Currently screen readers just read “Search – internal link list item” for the search button. It could read something like “Open search bar” and when the search bar is active, the aria-label would change to “Close search bar”. I also noticed when using ChromeVox (Chrome screen reader extension we use for accessibility testing), the search box doesn’t appear to get focus after tabbing to the search button and pressing the enter key. I believe this focus issue is separate from the root cause of #1 above.

Thanks for being open to making accessibility improvements. I have a an ulterior motive in bring these items up. I’m hoping GeneratePress can be my “gold standard” for accessibility when recommending base themes to all of my colleges in other gov agencies. Fair warning – I’m pretty obsessed with accessibility 😉

Appreciate all of your time this.

[Tom]

3. I know in some cases the role attribute isn’t needed. For example, if you’re using a <nav> element, there’s no need to use role to say it’s a navigation element. I’ll comb through the theme to make sure we’re not missing anything.

4. Awesome, love this. Will get it added in GP 2.4.

Accessibility is extremely important to me, so I appreciate every little bit of feedback that I can use to improve the theme. Thank you! 🙂

[Tom]

Just working on this – for #4, would the aria-label replace the screen-reader-text element we’re currently using?

[Steven]

Yes – I believe the screen reader text isn’t needed if the aria-label is added to the tag and toggled based on the state of the search box.

<a href="#" aria-label="Open Search Bar">
<a href="#" aria-label="Close Search Bar">

[Steven]

You could also go with a <button> vs. an <a> tag. When a screen reader reads them:

Open Search Bar Internal Link List Item
Open Search Bar Button

Just makes it more clear without the extra language around internal links. But I understand that’s a bigger change.

[Tom]

Awesome, I’ve gone ahead and implemented this in GP 2.4: https://github.com/tomusborne/generatepress/commit/b1fbdf6d8e50754ad4333e3dcd250941a6d022a0

Thank you!

[Author]

Posts