* Make <content> element explicitly non-focusable
Some browsers (Firefox, upcoming versions of Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=585413) make containers with `overflow: auto` / `overflow: scroll` (and the `-x` / `-y` variants) keyboard-focusable. This leads to a very awkward experience for assistive technology users navigating through the extension window, as for every view, the entire `<content>` container receives focus (and screen readers try to announce all its content in one go) before you reach the actual first control. To counteract this behaviour, this adds an explicit `tabindex="-1"` to these elements.
* Change `<content>` to `<main>`
More semantically accurate. See https://github.com/bitwarden/browser/pull/2245#issuecomment-1104553312
* Update scss to target `main` instead of `content`
* Change the previously existing `<main>` to generic `<div>`, tweak styles accordingly
Can't have two separate `<main>` elements, especially not nested ones. The original `<main>` was really just a handy wrapper for the component, but semantically should be neutral
* Add iframe allow to initial load
Chrome seems to balk at this attribute being added after the fact. It
may be a race condition or an intentional block, but adding to the
template fixes our missing allow attribute problem.
* Update jslib
- more semantically accurate, will expose these as buttons to assistive technologies
- note: while having block-level elements like `<div>` inside a `<button>` is an html validation error, it does not affect functionality as long as there's no more structure inside it
Patrick H. Lauke
Vincent Salucci
Oscar Hinton
Matt Gibson
Kyle Spearrin