@transferwise/components 0.0.0-experimental-4ba8514 → 0.0.0-experimental-2ea09db

package/src/withId/withId.story.tsx

@@ -24,7 +24,6 @@ DescribedButton.displayName = 'DescribedButton';
 
 export default {
   component: DescribedButton,
-  tags: ['docs-only'],
 } satisfies Meta<typeof withId>;
 
 export const WithoutId: Story = {};

package/src/moneyInput/MoneyInput.docs.mdx

@@ -1,34 +0,0 @@
-import { Meta } from '@storybook/blocks';
-
-<Meta title="Forms/MoneyInput/Known issues" />
-
-# Known accessibility issues
-
-There are few issues reported by Axe that are not fixable or safe to ignore at this point in time.
-
-## Form elements should have a visible label / Form elements must have labels
-
-While this requirement is normally considered as very serious, it's missing the fact that the input is wrapped by a labelled element with `role="group"`. We’ve tested it in NVDA on Windows and VoiceOver on MacOS, and discovered that if we were to satisfy Axe’s requirements, the screen reader would read out the label twice, something similar to `{Label Text} group, {Label Text} editable` (depending on the SR and the browser) which would result in an unnecessary noise. While the rule is valid, in this particular case the group label seems sufficient.
-
-#### Further resources
-
-- [Deque reference 1](https://dequeuniversity.com/rules/axe/4.9/label?application=axeAPI)
-- [Deque reference 2](https://dequeuniversity.com/rules/axe/4.9/label-title-only?application=axeAPI)
-- ['Group Labels Do Not Guarantee… Uniquity?' by Adrian Roselli](https://adrianroselli.com/2019/06/group-labels-do-not-guarantee-uniquity.html)
-
-## Buttons must have discernible text
-
-This affects HTML buttons with `role="combobox"` and deeply nested label text, not being discoverable by Axe. It is a known false-positive.
-
-#### Further resources
-
-- [Deque reference](https://dequeuniversity.com/rules/axe/4.9/button-name?application=axeAPI)
-- [axe-core github issue](https://github.com/dequelabs/axe-core/issues/4472)
-
-## ARIA hidden element must not be focusable or contain focusable elements
-
-This is a genuine problem – according to the accessibility guidelines, no element with `aria-hidden="true"` should have any focusable children. This issue is caused by the `SelectInput`'s third party dependency (`Headless UI`) and, by extension, is visible in few other places. Work is planned to address it.
-
-#### Further resources
-
-- [Deque reference](https://dequeuniversity.com/rules/axe/4.9/aria-hidden-focus?application=axeAPI)