Introducing accessibility to a search suggest dropdown

I've been working on a search suggest box for a project. You know the type: you start typing in the search box, and a list of suggestions appears below it.

(Disclaimer: this is the first time I've written about web accessibility, so be gentle. That said, I am by no means too proud to learn (thus this post), so I welcome any comments, changes, or corrections on my code.)

The part I'm going to write about isn't getting the list to show up (I'll just assume you know how to do that, because that's not the point of this post), but rather keyboard controls of the items within the list.

It's a pretty common UI pattern to be able to navigate search-suggest items with the keyboard, but the initial solution I wrote wasn't accessible at all. The focus stayed in the search input, all while changing the class (and therefore the visual aspect only) of the "keyboard-selected" list item. Pressing the enter key, while there was a "selected" item, would go to that item's URL instead of submitting the search form.

You can see a generic version of this functionality here:

https://codepen.io/peiche/pen/RgzwaK

The initial problem which presented itself was not (I am ashamed to admit) accessibility, but rather the action of opening the drop-down item's link. Some (but not all) needed to open in a new window, and using window.open() doesn't always work.

To clarify, it's actually not so much that it doesn't work, but rather that it gets blocked. Browsers (with the default security settings, anyway) will block any popup that isn't user-initiated. A popup opened within an element's click() event, for example, is treated as user-initiated. Opening a popup from within a keypress event, not so much. (Sure, you can rely on the user to allow the popup, but that's pretty bad UX.)

It occurred to me that pressing the enter key on a link that has focus behaves exactly the same as if it were clicked. So if a link with the target="_blank" property has focus, pressing the enter key will open it in a new window.

With this realization, I rewrote how the search box handles up and down arrow keypress events. The focus actually leaves the input field, and since <a> elements are focusable (they have to be, for accessibility reasons), the focus moves along the list of items. The focus() and blur() event, bound to each item in the list, toggles the class used to indicate visually which item is selected, as well as the aria-selected property.

https://codepen.io/peiche/pen/weLvEx

In retrospect, the focus (if you'll pardon the pun) of accessibility should have been first and foremost in writing the keyboard functionality for my input field's dropdown. Still, I'm happier with its behavior now than I was with the first version.

This post was originally published on eichefam.net.

Comments

[Marco Hengstenberg]

Hey Paul,

while I like the idea you had and the way it's built in that codepen is great, there is one thing you forgot:

people using the keyboard to navigate use the tab-key to move from link to link, not the up- and down-arrow-key.
Somehow you'd either need to tell sighted and non-sighted keyboard users that you changed this very common behaviour or add tabbing as a means to move through the dropdown links-list.

What I'd also advise is to get rid of the wrapping div container for the list and instead use a ul (or ol if the results are in a specific order) and wrap each link in a list-item then. That way users with a screenreader will be told that they are navigating a list, how many items are there and on which level of the list they are on.

The Codepen does not show me what happens on selection of one of the links. On clicking or focusing one of the links and tapping the enter-key, what is the expected behaviour? Will the value be added to the search-input or is it a direct navigation then?

Cheers and thanks for caring about a11y!
Marco

EDIT:
As I've also built a search input with a dropdown and I wanted it to be accessible I took awesomplete. A JS library for exactly that and it works like a charm. On top, if JS isn't there, I won't lose the search functionality of the input in the first place.

[Paul]

Marco,

Thanks so much for your input. Since this is my first foray into providing accessibility for a custom component, I greatly appreciate the feedback.

I rebuilt the list, taking your advice and making it a <ul>. I also added logic in the JavaScript that allows for tab and shift+tab behavior, updating the focus and aria-selected properties accordingly.

codepen.io/peiche/pen/rzBMWB

When the user hits the enter key on a focused list item, they're taken right to that link. In my original use case, some of the links in the suggest list have target="_blank, so the link will open in a new tab.

Thanks again for the great feedback!

Cheers,

Paul

[Marco Hengstenberg]

Hey Paul,

that's already a lot better! Great job.

If you wanted to learn more on the subject of Accessibility on the Web I totally recommend inclusive-components.design/
It's a website by my friend Heydon Pickering, who already wrote two books (one is only available as en eBook) on the subject and recently started this project.

Also I'd start following the Paciello Group because they are experts in the field of A11y AND help to shape the related guidelines.

I really hope you dig deeper into this subject as it is very very important (at least I think so). =)

Great stuff, keep on going, cheers,
Marco

P.S.: it's a preference thing but I'd refrain from using target=_blank in links as people cannot use the back-button to go through browser history, which is a very common pattern. =)

P.P.S.: I'd also suggest you to start trying out screenreader software (if you're on a Mac hit CMD + F5 to turn on VoiceOver) while browsing the pages you've built. It will give you a better picture of what it is like to use the web while non-sighted or when you have to rely on a software reading contents to you. Especially when it comes to interactive websites, things go awry very quickly when components are not built accessibly, like:

• interaction not explained
• icons without any accessible text
• buttons without their purpose explained
• updated content not announced (aria-live is very helpful here)

and, of course, more more more things to keep in mind.

[Paul]

Marco,

Thanks for the links and the encouragement. I agree that it's important, which is why I'm trying to learn more about it.

Personally, I agree with you on the use of target="_blank". I am but a lowly developer, however, and I have to do what they tell me. :)

Paul

P.S. Thanks for tip on VoiceOver.