Keyboard navigation for UI (mainly for forms)

[webmaxru]

It's important to provide mouse free UX for submitting and editing activities. tabindex-based navigation is the main part of it. For now after pressing TAB the focus doesn't go to the next field but disappears. Has to be fixed for all forms (main) and other UI elements.

[justinribeiro]

Just as an FYI, this is a known issue in iron-overlay-behavior (there is a PR sitting that hasn't been reviewed that resolves this: PolymerElements/iron-overlay-behavior#200). There is not a good workaround currently (focus is hard), but once that PR lands we should be golden.

[LostInBrittany]

Yeah, as Justin said, I'm kinda been waiting for that fix for a moment...

The only workaroround I could do now it some hand coded focus routine for the form, and since PolymerElements/iron-overlay-behavior#200 should arrive to master soon, I'd prefer to wait for it...

[justinribeiro]

I say we wait. :-) My two cents.

[LostInBrittany]

I'm not sure it will be ready for 2.0.0-Beta, so I'm removing the label...

[justinribeiro]

Worst case, we update the dep to point to that hash and ship the PR (without it being in mainline).

[justinribeiro]

I've pushed a PR that will need further testing and probably a few tweaks, but it basically gets us an okay keyboard experience (make sure to run bower update and select the hash version for iron-overlay-behavior). Click to see the video below on YouTube showing what it looks like in action.

It is not the end-all-be-all, but it works around the problem will discovering others (particularly that paper-button with disabled pegged to a property basically makes tabindex not work which required me to some validation on the fields, or that paper-menu-dropdown can't take focus() which is really heart warming). I'm not going to go into the full list of somewhat random things I had to do to make this smooth but the code will tell the tale.

Comments (and testing before merge) very very welcome. :-)