Research Spike: Switching buttons to use the button element

[heff]

For v5.0 we've been discussing switching to <button> instead of <div> for all the UI buttons. The general opinion among usability experts is that <button> is still better than <div> even with all the accessibility enhancements you can do (e.g. ARIA) because certain screen readers still won't support the enhanced divs. A comment on css-tricks confirms this for the Nuance Natural Speak app at least, though it would be great to have more specific examples if anyone knows of a resource or has details on specific screen readers to add here.

This PR has the very minimum required to switch to buttons so that they still look right in all browsers. Tested so far in IE8, IE11, Chrome, Firefox, and Safari Desktop.

This does not consider additional specificity that will be need to protect the buttons from being affected by external styles. The next steps will be to add additional property settings and a more specific scope. We at least need enough to be safe within a framework like Foundation that adds a ton of styles to the base button element.

Related issues: #841, #1499, #1880
Related contributors: @gdkraus, @OwenEdwards, @baloneysandwiches, @karlgroves

[albell]

This is great. From my limited experimentation, JAWS, Voiceover and (from hearsay) other latest generation readers do announce any element as a "button" if it's given that ARIA role. Normalizing markup is nice, but it seems like the big win with switching to <button markup has more to do with the spacebar versus the enter key as the presumed event trigger. MDN:

"Warning: Be careful when marking up links with the button role. Buttons are expected to be triggered using the Space key, while links are expected to be triggered through the Enter key. In other words, when links are used to behave like buttons, adding role="button" alone is not sufficient. It will also be necessary to add a key event handler that listens for the Space key in order to be consistent with native buttons."

[gdkraus]

The biggest problem in the past was with Dragon Naturally Speaking not recognizing role="button" as a clickable element. DNS users can easily pull up a visual list of all of the clickable items so they can easily activate a clickable item anywhere on the page with voice commands. Because it couldn't recognize role="button" as clickable, the user had to repeatedly say "Tab" until the keyboard focus got to the play button in order to activate it. I believe the latest version of DNS fixes this. I can conform next week. I'm away at a conference right now.

I can do some screen reader tests next week too.

[heff]

To play devil's advocate a bit then:

• we already support both spacebar and enter on our div buttons
• Dragon has apparently improved
• I don't see Dragon or Nuance in this survey of readers (though they could be in the 5% of 'other')

If we can confirm that the rest of the readers there do support role="button" well, is this really a problem we need to fix? All things being equal we would anyway, but:

• We'll be opening the door for a lot more style conflicts from frameworks like Foundation
• We'll be breaking existing v4.0 skins more significantly (we're breaking them in minor ways for 5.0 either way)

[albell]

Fair point. If everyone's on latest browsers/readers, with polyfilled behavior, then the difference is increasingly moot. There's still something slightly grating about it though, like having block-level spans and inline divs 😿

(FWIW the default button styling in Foundation isn't too crazy or high-specificity.)

[dmlap]

lgtm

[mmcc]

Looks like we're going to do this, but this PR isn't going to carry the baton across the finish line. Closing in lieu of #1989 and we'll revisit post-ES6.