- add `sr-only` "Bootstrap", which will be part of the accessible name
- extra `sr-only` text to give some context - that the dropdown is about switching versions
- remove the redundant id/aria-labelledby for the dropdown
- change the control from `<a>` to `<button>`
* Manually backport 32630
Dynamic tabs: use buttons rather than links
* Tweak unit test
* Tweak unit tests
* More tweakage
* show() should also bail if `disabled` attribute is set
* Tweak tests
* Simplify test for relatedTarget
* Temporarily remove problematic test
(as i can't get local tests to run just noww)
* Revert previous
* test: fix broken test cases for tab.js
* test: fix role=tablist invalid on nav element
* test: prefer <div/> over <div></div>
* Manually backport 32630
Dynamic tabs: use buttons rather than links
* test: fix broken test cases for tab.js
* Fixes
* Remove and ignore lock file
Co-authored-by: alpadev <alpa.muc@gmail.com>
Co-authored-by: Mark Otto <markd.otto@gmail.com>
Co-authored-by: Mark Otto <markdotto@gmail.com>
manual backport of #34886
per https://www.w3.org/TR/html-aria/#docconformance
> It is NOT RECOMMENDED to use `aria-disabled="true"` on an `a` element with an `href` attribute.
>
>NOTE
>If a link needs to be "disabled", remove the `href` attribute.
This PR removes the unnecessary `href="#"`, `tabindex="-1"`, and `aria-disabled="true"` from disabled links in both docs pages and examples. `aria-disabled="true"` *is* kept for disabled link-based buttons (that have `role="button"`) as there it's appropriate to use (you *want* to convey to assistive technologies that this thing you're claiming is a button is also disabled at the moment)
Further, the PR extends the "Link functionality caveat" to show the "proper" way (removing `href` and adding `.disabled` class only) to disable a link, but then explains what to do if that's not possible (and then keeps an example with all the traditional `href="#" tabindex="-1" aria-disabled="true"`, but explains clearly that it's not ideal). Same sort of explanation is also added to the pointer event utilities page
`aria-haspopup="true"` is really intended to signal that an ARIA `menu` will be opened on activation. as a result, some assistive technologies will announce controls with `aria-haspopup="true"` as a menu or menu item (e.g. JAWS and NVDA).
In addition, `aria-haspopup` seems to trigger a bug in Edge/Narrator where the `aria-expanded` state is not correctly announced at the moment when `aria-haspopup` is present.
This now makes the dropdown button more like a generic disclosure widget control - see also https://www.w3.org/TR/wai-aria-practices-1.2/examples/disclosure/disclosure-navigation.html01
* Add a callout for the sanitizer in popovers and tooltips
* Add second reference to sanitizer in the options
Co-authored-by: XhmikosR <xhmikosr@gmail.com>
