* SVG accessibility fixes
- add `focusable="false"` to all SVGs, to stop IE from including the `<svg>` in its default focus cycle
- completely hide decorative SVGs using `aria-hidden="true"`
- add `role="img"` to meaningful/"content" SVGs, ensure they have an appropriate `<title>` and/or `aria-label`
- simplify placeholder default title
* Simplify usage of placeholder.svg in the docs
- in most cases, no need for separate/redundant text and title (now that we make text itself part of the alternative text explicitly)
- no need (expect in rare cirumstances) to describe the placeholder image (unless the look of the image is important/the actual content, as is the case with the image thumbnail class)
* Simplify example.html rewriting of <svg> to <img> code sample
- as the `alt` for the placeholder isn't really important, just add an ellipsis instead (otherwise, to be correct, we'd have to construct the whole "title+text" construct like we do now in the
placeholder.svg itself
* Change svgo configuration to retain role attribute and add/force focusable=false
- regarding `focusable=false`, see https://github.com/svg/svgo/issues/1011 (which would be the "proper" SVGO fix) and the (hacky) solution https://github.com/svg/svgo/pull/817
The latest (2.6.2) docsearch.js version now displays results as standard `<a href>` links, allowing users to `ctrl`-click on them to trigger default browser behavior of opening in a new tab.
To maintain backward compatibility, this behavior has only been enabled to users that didn't define their own `handleSelected` method.
This PR updates your `docsearch()` code to take advantage of the new `<a href>` template, by removing your custom `handleSelected` and moving its behavior to the `transformData` call. Namely, what you wanted to avoid was jumping to the first `<h1>` of the pages, which would prevent users from seeing the header. This PR checks if the suggestion targets the `#content` anchor (meaning it goes to this first `<h1>`) and remove it.
Behavior should be the same, but at least now you can enjoy the `ctrl`-click :)
With the current docs directory setup, I'm making too many mistakes and have to manually address path changes and directory moves on deploy. This makes for a frustrating experience developing locally and shipping releases. With this PR, we're basically back to the same setup from v3—duplicating the dist directory into our docs directory. Not the most ideal, but very straightforward for me as the release manager.
Mark Otto