Updating docs copy for accessibility false positives (#4856)

* Updating docs copy to mention how to supress accessbility false positives

* address review comments

* Make example less storybook specific

* fix syntax coloring

Author: LFDanLu

packages/@react-aria/select/docs/useSelect.mdx

@@ -521,8 +521,16 @@ In right-to-left languages, the select should be mirrored. The arrow should be o
 and the selected value should be on the right. In addition, the content of list options should
 flip. Ensure that your CSS accounts for this.
 
-### False positive on `<HiddenSelect />` in accessibility tools
+## Accessibility
 
-When using &lt;<TypeLink links={docs.links} type={docs.exports.HiddenSelect} />&gt; some accessibility tools such as AXE or pa11y might give a false positive.
-The data attribute `data-rsp-a11y-ignore` is included on the hidden select element and can be used to ignore the false positives in these tools.
+### False positives
 
+The HiddenSelect may trigger a [known accessibility false positive](https://github.com/adobe/react-spectrum/wiki/Known-accessibility-false-positives#picker)
+from automated accessibility testing tools. This is because the HiddenSelect is included to specifically aid with browser form autocomplete
+and is hidden from screen readers via `aria-hidden` since users don't need to interact with it. We manage focus internally
+so that focusing this hidden select element will always shift focus to the Select's trigger button instead. Automated accessibility testing tools have no way of
+knowing that we manage the focus in this way and thus throw this false positive.
+
+To facilitate the suppression of this false positive, the `data-a11y-ignore="aria-hidden-focus"` data attribute is automatically applied to the
+problematic element and references the relevant `AXE` rule. Please use this data attribute to target the problematic element and exclude it
+from your automated accessibility tests as shown [here](./accessibility.html#false-positives).

packages/@react-spectrum/picker/docs/Picker.mdx

@@ -464,3 +464,17 @@ function Example() {
   );
 }
 ```
+
+## Accessibility
+
+### False positives
+
+Picker may trigger a [known accessibility false positive](https://github.com/adobe/react-spectrum/wiki/Known-accessibility-false-positives#picker)
+from automated accessibility testing tools. This is because we include a visually hidden select element alongside the Picker to specifically aid with browser form autocomplete
+and hide it from screen readers via `aria-hidden` since users don't need to interact with the hidden select. We manage focus internally
+so that focusing this hidden select will always shift focus to the Picker's trigger button element instead. Automated accessibility testing tools have no way of
+knowing that we manage the focus in this way and thus throw this false positive.
+
+To facilitate the suppression of this false positive, the `data-a11y-ignore="aria-hidden-focus"` data attribute is automatically applied to the
+problematic element and references the relevant `AXE` rule. Please use this data attribute to target the problematic element and exclude it
+from your automated accessibility tests as shown [here](../react-aria/accessibility.html#false-positives).

packages/dev/docs/pages/react-aria/accessibility.mdx

@@ -104,3 +104,24 @@ All React Aria components are tested across a wide variety of devices, browsers,
 * [NVDA](https://www.nvaccess.org) on Windows in Firefox and Chrome
 * [VoiceOver on iOS](https://www.apple.com/accessibility/iphone/vision/)
 * [TalkBack](https://www.android.com/accessibility/) on Android in Chrome
+
+### False positives
+
+There are a number of known accessibility false positives in React Aria and React Spectrum, currently documented here in our [wiki](https://github.com/adobe/react-spectrum/wiki/Known-accessibility-false-positives).
+These are commonly caught by automated accessibility testing tools and can cause unnecessary noise in your own accessibility audits.
+To facilitate the suppression of these false positives, the data attribute `data-a11y-ignore` is included on the problematic elements
+with the relevant `AXE` rule set as its value. Below is a list of the currently available data selectors and their equivalent `AXE` rules:
+
+```tsx
+{
+  rules: [
+    {
+      id: 'aria-hidden-focus',
+      selector: 'body *:not([data-a11y-ignore="aria-hidden-focus"])'
+    }
+  ]
+}
+```
+
+This set of rules should be included in your accessibility test framework's `AXE` config, such as in the [automated Storybook test runner](https://storybook.js.org/docs/7.1/react/writing-tests/accessibility-testing#a11y-config-with-the-test-runner)
+or for the [Storybook a11y addon](https://storybook.js.org/docs/7.1/react/writing-tests/accessibility-testing#global-a11y-configuration).

packages/react-aria-components/docs/Select.mdx

@@ -1017,3 +1017,17 @@ function MySelect(props) {
   );
 }
 ```
+
+## Accessibility
+
+### False positives
+
+Select may trigger a [known accessibility false positive](https://github.com/adobe/react-spectrum/wiki/Known-accessibility-false-positives#picker)
+from automated accessibility testing tools. This is because we include a visually hidden select element alongside the Select to specifically aid with browser form autocomplete
+and hide it from screen readers via `aria-hidden` since users don't need to interact with the hidden select. We manage focus internally
+so that focusing this hidden select will always shift focus to the Select's trigger button instead. Automated accessibility testing tools have no way of
+knowing that we manage the focus in this way and thus throw this false positive.
+
+To facilitate the suppression of this false positive, the `data-a11y-ignore="aria-hidden-focus"` data attribute is automatically applied to the
+problematic element and references the relevant `AXE` rule. Please use this data attribute to target the problematic element and exclude it
+from your automated accessibility tests as shown [here](./accessibility.html#false-positives).