Search Widget: implement keyboard navigation and accessibility

mozilla / remote-newtab

Remotely-hosted New Tab Page

https://mozilla.github.io/remote-newtab/src/

Mozilla Public License 2.0

15 stars 7 forks source link

Search Widget: implement keyboard navigation and accessibility #188

Closed rlr closed 8 years ago

rlr commented 8 years ago

f? @k88hudson

How do I test this with our testing infra? Should I be sending keystrokes to the textbox and making sure the right things change?
Any ideas on how to make it cleaner/better/awesomer?
Right now Search.js needs to know about IDs used in SearchMagic.js. Yuck. Should I pass the ID prefixes as props down to SearchMagic.js?
I tried overcomment parts of the code because I was getting lost myself in there. Let me know if it was too much or too little.
This only covers the search widget. The current new tab page also tabs through all the tiles but it only focuses on the pinning and blocking links. I think that's weird because it doesn't allow you to follow through on the tile link via keyboard. It's probably a bug. That part should be easy to implement once we decide how we want it to behave.

k88hudson commented 8 years ago

Hmm, I'm thinking we might want to take a different approach to structuring this in order to make it a bit less intense:

convert the suggestions and/or search options to a different element type like maybe an option group or buttons
possibly combine the search/search magic into a single component, or at least create a container component to make the tabbing stuff less :fearful:

This is a great start!

rlr commented 8 years ago

yeah. at this point it doesn't make sense to have two separate components for them, I agree. making it all more like a form with form elements is an awesome idea.

rlr commented 8 years ago

Just vidyo'd with @k88hudson... Next steps:

Combine the two modules
Go through the feedback so far and fix it
See if we can change the current behavior of keeping the text input in focus the whole time (consult with the a11y experts on this). That would give us more options to just let the browser's default tab handling work without special js.
Learn how to write tests and write them.

rlr commented 8 years ago

OK, ^^ I've combined the two modules into one and went through some of the feedback. I didn't fix the nasty keypress handler code yet in case we are lucky and can remove it...

So what's next? Do we want to show this to MarcosZ or something else? Behavior-wise and a11y attribute-wise, this is pretty close to what is in about:home, current about:newtab and the search box. And it follows the blog post MarcosZ pointed out (role=listbox and role=options).

marcoscaceres commented 8 years ago

this is pretty close to what is in about:home, current about:newtab and the search box.

FWIW, I don't know if anyone ever checked about:newtab's original code for accessibility. I would be cautious about using that as any sort of benchmark. Same with the search box - might be wrong, but the original search code seemed like a total hack.

rlr commented 8 years ago

FWIW, I don't know if anyone ever checked about:newtab's original code for accessibility.

Probably not. The only part that seems to be accessible is the search box.

Same with the search box - might be wrong, but the original search code seemed like a total hack.

MarcosV pointed us to about:home which has the same search box as about:newtab and the top search box that is part of the chrome. And playing with it and looking at the aria/role stuff, it's exactly what he suggests in https://www.marcozehe.de/2014/03/11/easy-aria-tip-7-use-listbox-and-option-roles-when-constructing-autocomplete-lists/

k88hudson commented 8 years ago

Ok looks way better R+

rlr commented 8 years ago

1a98c02fc9354ce9c8281974479e64ff03ca325d