Add form instructions for screen readers

[jechols]

Adds very basic explanation of the tab/enter keys for keyboard-only users (or users who simply prefer the keyboard)

[jechols]

As the form is now essentially doing everything the default way, I think this is all we need, but I'm not sure on a couple points:

• Do we want these instructions styled in some cool way?
• Do we want to use "sr-only" to just hide them except for screen-reader users?
• Is there a better way to word this?

[jcoyne]

Seems like <p> would be a more semantic tag.

[jechols]

I think you're right - let me fix that

[hackartisan]

Cool styling idea: put the words 'tab', 'space', and 'enter' in little keyboard-looking boxes, e.g.: http://michaelhue.com/keyscss/

[hackartisan]

Wording idea (a little more terse): 'Use the tab key to navigate the form, press space when
focused on to activate a button to add or remove fields, and press
enter to submit the whole form when focused on simple text fields.'

Another idea (more detailed re: 'enter'):
Use Tab to move focus to the next form element. On a button, use Space to activate. On a button or simple text field, use Enter to submit the whole form. In a long text field, use Enter to add a new line.'

I've been told, though, that I tend to use language that is too technical when writing this stuff

[jechols]

I'll check out the keys css thing - I think the "kbd" tag is proper anyway, so adding a bit of CSS only helps.

As for the enter situation - enter only submits within a text field. There's been some confusion on that point, but the original change I made to make enter submit forms doesn't actually override the enter key, it just returns the enter key to the default behavior. If you tab over a button and hit enter, it's the same as a button click. The good news is most people will be used to this functionality. The bad news is that if we want to explain it precisely, we have to explain that enter in a text area doesn't submit the form, etc.

And the more explanation we add, the more screen reader users have to listen through on every form. I'm not sure how to balance the text given that. I'm gonna dig through webaim - I am sure I once read about something (other than just skip links) to make that kind of explanation easy to skip past.

[jechols]

Oh, keys.css is licensed as MIT - including its code directly in here may be questionable. I have no idea, I'm not a license guy. I'll add <kbd> tags, but I want to hear from others before included non-public-domain code.

[hackartisan]

Sounds good! And thanks for clarifying.

[jechols]

Oh this is neat - bootstrap gives us nice styling out of the box! keys.css is nicer, but we have a pretty good default at least.

[hackartisan]

Rad, I think the bootstrap style looks totally good / sufficiently fancy!

[jechols]

Okay, used your more terse wording and added the kbd tags. The biggest downside is the need for the raw call on the translation, but I'm not sure there's a good alternative to get those semantic kbd tags.