LG-4682: Resolve confirmation step button scroll-to-top, role

[aduth]

Why: Since "Print" and "Copy" are not navigable, they should not be rendered as links, since (a) this has the effect of scrolling the user to the top of the page when clicking the buttons and (b) they are announced to assistive technology as links. Since they behave as buttons, they should be rendered as such.

Implementation notes:

This refactors a fair bit of how these elements are rendered:

1. Replaces BassCSS grid with USWDS
2. Use margins instead of line breaks
3. Implements and renders a new ClipboardButtonComponent

Notes on ClipboardButtonComponent:

• This will be useful for upcoming implementation in LG-5456 for success indicators for clipboard buttons
• While this introduces a (seemingly-redundant) new dependency for clipboard API, it would be my goal that this would eventually replace the existing clipboard dependency. The idea behind this is that we can ideally rely on native browser APIs, potentially removing the polyfill altogether if/when support for Internet Explorer is dropped.
• The two new ViewComponent implementations may be a bit excessive, but (a) I did not feel it would be appropriate for a ClipboardButtonComponent to handle button details such as rendering the outline variant, (b) with a potential future goal of extracting design system components to a library gem, it would be expected that such an implementation would exist, and (c) it was a useful exercise in understanding how component inheritance may work.
• While this would be a perfect use-case for a customized built-in element of the button element, the general consensus I've read is that customized built-in elements are effectively dead-on-arrival, due to Apple's refusal to support them in Safari.
  • A possible alternative is to avoid wrapping the <button> element and assign all necessary behaviors of a button to lg-clipboard-button (role="button", click, and keyboard handlers), but this would be rather cumbersome, and a wrapper is much more straightforward to implement.

[aduth]

One possible future awkwardness we may run into is that because we're just wrapping the base markup, things like tag_options[:class] will apply to the child element, not the root. A small difference, but personally I'd expect tag_options to apply to the root element.

[zachmargolis]

LGTM

[zachmargolis]

what's arguments here?

[aduth]

what's arguments here?

From what I understand, evaluate_async_script wraps the given script in a function, called with a callback function argument (last argument?).

So it ends up being something like...

(function(/* callback */) {
  navigator.clipboard.readText().then(arguments[0])
})(callback);

arguments being the JavaScript keyword to reference the given function arguments.

[zachmargolis]

neat, I wish *they'd call it it something clearer like resolve lol 😂

*they = the webdriver/capybara devs

[aduth]

Initially I'd hoped it would infer the promise value and treat it as something more like...

copied_text = page.evaluate_async_script('navigator.clipboard.readText()')

(() => navigator.clipboard.readText())().then(callback);

[zachmargolis]

😍

[solipet]

LGTM