Father of 2 girls, music lover & casual gamer. Pixelpusher & Websitewrangler.
Living in beautiful Freiburg, Germany, at the foothills of the Black Forest.
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.
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.
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.
Father of 2 girls, music lover & casual gamer. Pixelpusher & Websitewrangler.
Living in beautiful Freiburg, Germany, at the foothills of the Black Forest.
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.
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.
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
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=_blankin 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:
and, of course, more more more things to keep in mind.
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.