diff --git a/docs/architecture/component-patterns.md b/docs/architecture/component-patterns.md
index 6d9ff3df0812f..9efc6a06671e3 100644
--- a/docs/architecture/component-patterns.md
+++ b/docs/architecture/component-patterns.md
@@ -18,6 +18,9 @@ packages/react-components/react-<name>/library/src/
 ├── utils/                                # Optional: shared utilities
 ├── testing/
 │   └── isConformant.ts                   # Conformance tests
+├── stories/src/<Name>/
+│   ├── <Name>Accessibility.md            # Optional: concise accessibility guidance
+│   └── <Name>AccessibilitySpec.mdx       # Optional: full component accessibility spec
 ├── <Name>.ts                             # Root barrel per component
 └── index.ts                              # Package export
 ```
@@ -124,3 +127,11 @@ export const Component: ForwardRefComponent<ComponentProps> = React.forwardRef((
   return renderComponent_unstable(state);
 });
 ```
+
+## Accessibility patterns
+
+Refer to `<Name>Accessibility.md` or `<Name>BestPractices.md` for high-importance accessibility requirements.
+
+Check `<Name>AccessibilitySpec.mdx` for the full description of accessibility behaviors, including keyboard interaction, assistive tech behaviors, high contrast and reduced motion styles, content restrictions, and guidance on extending the control without breaking accessibility.
+
+Most packages only have one `<Name>AccessibilitySpec.mdx` covering all components in the package -- for example, `MenuAccessibilitySpec.mdx` covers `Menu`, `MenuList`, `MenuItem`, `MenuItemCheckbox`, `MenuItemLink`, `MenuItemRadio`, `MenuItemSwitch`, etc.
diff --git a/packages/react-components/react-button/stories/src/Button/ButtonAccessibilitySpec.mdx b/packages/react-components/react-button/stories/src/Button/ButtonAccessibilitySpec.mdx
new file mode 100644
index 0000000000000..019daaacd3925
--- /dev/null
+++ b/packages/react-components/react-button/stories/src/Button/ButtonAccessibilitySpec.mdx
@@ -0,0 +1,173 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title="Concepts/Developer/Accessibility/Components/Button" />
+
+# Button Accessibility Spec
+
+`Button` triggers an action or event when activated. It is the foundational building block for more specialized button variants in this package — `CompoundButton`, `MenuButton`, `SplitButton`, and `ToggleButton` — each of which has its own accessibility considerations beyond what is covered here.
+
+By default, `Button` renders a native HTML `<button>` element and inherits all of its built-in accessibility behavior. When rendered as an anchor (`as="a"`), additional ARIA attributes and keyboard handlers are applied to make it behave like a button.
+
+## Usage
+
+### When to choose Button
+
+#### Button vs. anchor / Link
+
+Use `Button` when activation triggers an action on the page, such as submitting a form, opening a dialog, or running a command. Use a link (`<a>` or Fluent's `Link` component) when activation navigates the user to a different page or location.
+
+A good indication that something should be a link is if the URL changes when clicked, even if routing is handled via JavaScript. Using a link allows end users to perform actions like copying the URL, opening in a new window or tab, and accessibility benefits such as appearing in a screen reader's links dialog.
+
+If the visual design calls for a button-styled control that navigates somewhere, render `Button` as an anchor with `as="a"` and an `href`. This preserves link semantics (so screen readers announce it as a link, and users can open it in a new tab) while keeping the visual styling of a button.
+
+#### Button vs. ToggleButton
+
+`ToggleButton` should be used when a control represents a binary on/off state that persists after activation, such as toggling bold formatting in an editor. `Button` should be used for actions that do not have a persistent on/off state.
+
+#### Button vs. MenuButton / SplitButton
+
+Use `MenuButton` when activating the control should open a menu of options. Use `SplitButton` when there is a primary default action plus a related menu of variations on that action. Use `Button` when there is a single action with no associated menu.
+
+### Implementing Button
+
+#### Label
+
+Authors must provide an accessible label for every `Button`. The label is what assistive technologies announce when the button receives focus.
+
+For buttons with visible text content, the text content automatically serves as the accessible name:
+
+```tsx
+<Button>Save</Button>
+```
+
+For icon-only buttons (a `Button` with an `icon` slot but no children), an `aria-label` must be provided, since there is no visible text:
+
+```tsx
+<Button icon={<EditRegular />} aria-label="Edit" />
+```
+
+When pairing a `Button` with separate visible label text (for example, when a tooltip is providing the label), use `aria-labelledby` to point at the id of that text.
+
+When using the Fluent `Tooltip` control with a `Button` where the Tooltip represents the primary labelling text, use the `relationship="label"` attribute to provide the accessible name:
+
+```tsx
+<Tooltip content="Edit" relationship="label">
+  <Button icon={<EditRegular />} />
+</Tooltip>
+```
+
+#### Content
+
+Use concise, action-oriented labels. A single verb is usually best, with a noun included if there is any room for interpretation about what the verb acts on (for example, "Delete folder" rather than "Delete"). Use sentence-style capitalization.
+
+#### Content restrictions
+
+The following content types should not be used within children or slots of `Button`:
+
+- Any interactive or focusable content (links, other buttons, inputs).
+- Any structured content, such as tables, lists, or headings.
+
+Focusable content nested inside a button is not reliably reachable by assistive technologies when the root renders as `<button>` or `<div role="button">`.
+
+The following content types may be used within children and slot content of `Button`:
+
+- Images and icons (decorative; the button itself provides the accessible name)
+- Generic elements like `<span>`, without `tabindex` or `role` properties
+- Fluent's `<Text>` component
+
+#### Disabled vs. disabledFocusable
+
+`Button` exposes two ways to indicate that the control cannot be activated:
+
+- `disabled` — the button is not focusable and cannot be activated. This is the default disabled behavior of the underlying `<button>` element.
+- `disabledFocusable` — the button is still programmatically focusable, but it is not in the tab order and activation is blocked. The hook applies `aria-disabled="true"` and intercepts click and key activation.
+
+Outside of very specific edge cases, prefer using the `disabled` attribute for buttons. Assistive tech like screen readers can still read disabled controls, the `disabled` attribute should not be avoided for discoverability by screen readers.
+
+`disabledFocusable` should be used in these cases:
+
+1. The Button is inside a control with arrow key navigation. The only such control that a `Button` should appear in is `Toolbar`.
+2. The Button can become disabled when activated. In this case, use `disabledFocusable` so that the user does not lose their keyboard focus. This affects screen reader users the most since losing focus causes them to lose their cursor's place on the page.
+
+Both `disabled` and `disabledFocusable` apply the same disabled visual styling.
+
+#### Anchor (`as="a"`)
+
+When `Button` is rendered as an anchor with `as="a"`, the underlying element is `<a>` rather than `<button>`. To preserve button-like semantics and behavior, `useARIAButtonProps` adds:
+
+- `role="button"` when no `href` is present (so the element is exposed as interactive to assistive technology; an `<a>` element with no `href` is semantically equivalent to a `<span>`)
+- `tabIndex={0}` so the element is keyboard focusable when no `href` is present
+- Synthetic <kbd>Space</kbd> activation, since anchors do not natively activate on <kbd>Space</kbd>
+
+When `href` is present, the role remains the default link role, and the control is announced as a link. When the anchor is disabled, `href` is removed to prevent navigation, and `role="link"` is set explicitly so the element is still announced as a (disabled) link rather than silently changing role.
+
+#### Color contrast and appearance variants
+
+Each appearance variant has different color contrast considerations:
+
+- `primary` uses brand background colors. The text color is paired with the brand background to meet 4.5:1 contrast in the supported themes.
+- `secondary` (default) and `outline` rely on the page background. They must be placed over a background light or dark enough that the button's border meets 3:1 contrast against the page background, and the text meets 4.5:1 contrast.
+- `subtle` and `transparent` have no border and no background at rest. They must be placed over a background that provides 4.5:1 contrast against the button's text color.
+
+Authors are responsible for ensuring the button is placed on a background where these contrast requirements are met. The included themes guarantee contrast within the default page surfaces.
+
+#### Target size
+
+[WCAG 2.5.8 Target Size (Minimum)](https://w3c.github.io/wcag/understanding/target-size-minimum.html) requires interactive controls to be at least 24×24 CSS pixels. `Button`'s default styles meet this requirement at all sizes, including the smallest icon-only size (24×24). When overriding layout styles such as `padding`, `min-width`, `min-height`, or `font-size`, authors must verify the rendered button is still at least 24×24.
+
+## Semantics
+
+| Element                          | Role mapping | States and properties                                                 |
+| -------------------------------- | ------------ | --------------------------------------------------------------------- |
+| Default (`<button>`)             | button       | `type="button"`, `disabled` or `aria-disabled="true"` when disabled   |
+| Anchor with `href` (`as="a"`)    | link         | `aria-disabled="true"` and `role="link"` when disabled (no `href`)    |
+| Anchor without `href` (`as="a"`) | button       | `role="button"`, `tabIndex="0"`, `aria-disabled="true"` when disabled |
+
+## Keyboard interaction
+
+### Navigate to button
+
+`Button` is a single tab stop.
+
+| Key                               | Result                                              |
+| --------------------------------- | --------------------------------------------------- |
+| <kbd>Tab</kbd>                    | Moves focus to the button                           |
+| <kbd>Shift</kbd> + <kbd>Tab</kbd> | Moves focus to the button from a later focus target |
+
+When either `disabled` or `disabledFocusable` is set, the button is removed from in the tab order.
+
+### Activate button
+
+| Key              | Result                                                |
+| ---------------- | ----------------------------------------------------- |
+| <kbd>Enter</kbd> | Activates the button (fires `onClick`)                |
+| <kbd>Space</kbd> | Activates the button on key release (fires `onClick`) |
+
+For native `<button>` elements, this behavior comes from the browser. For anchors rendered with `as="a"`, `useARIAButtonProps` from `@fluentui/react-aria` attaches `onKeyDown` and `onKeyUp` handlers to call `click()` on <kbd>Enter</kbd> and <kbd>Space</kbd>, matching native button behavior. <kbd>Space</kbd> activates on key release (matching the platform convention) and the default scroll behavior is suppressed on key down.
+
+When the button is disabled (`disabled`, `disabledFocusable`, or `aria-disabled="true"`), <kbd>Enter</kbd> and <kbd>Space</kbd> activation is blocked and the click event is not fired.
+
+## Windows contrast themes (high contrast mode)
+
+`Button` adapts to Windows contrast themes (high contrast mode) using system colors inside `@media (forced-colors: active)`:
+
+- Default appearance uses the default system mappings for colors
+- `primary` explicitly maps to `Highlight` (background) and `HighlightText` (text and border) so the visual emphasis of the primary action is preserved in high contrast mode.
+- `:hover` and `:hover:active` states swap to the inverse pairing (`HighlightText` background with `Highlight` text and border) so interactive feedback remains visible.
+- Disabled states use `GrayText` for text, border, and icon, which allows `disabledFocusable` to match the native platform colors for `disabled`.
+
+### Potential high contrast mode pitfalls
+
+The Button control uses `forcedColorAdjust: none` in three places:
+
+- `:hover` styles on the default button
+- `:hover:active` and `:active:focus-visible` on the default button
+- All styles on the `primary` button
+
+This is important because if any custom styles targeting those selectors override `background` or `color` directly instead of updating tokens, it is likely that the correct high contrast color styles will need to be re-declared `forced-colors` media query.
+
+## Motion and animation
+
+`Button` has a short transition (`durationFaster`) on `background`, `border`, and `color` when interaction state changes. This transition is shortened to `0.01ms` when [`prefers-reduced-motion: reduce`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion) is set, effectively disabling the animation while preserving the final visual state.
+
+There is no other motion or animation on `Button`.
diff --git a/packages/react-components/react-button/stories/src/MenuButton/MenuButtonAccessibilitySpec.mdx b/packages/react-components/react-button/stories/src/MenuButton/MenuButtonAccessibilitySpec.mdx
new file mode 100644
index 0000000000000..e938cc6495e56
--- /dev/null
+++ b/packages/react-components/react-button/stories/src/MenuButton/MenuButtonAccessibilitySpec.mdx
@@ -0,0 +1,85 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title="Concepts/Developer/Accessibility/Components/MenuButton" />
+
+# MenuButton Accessibility Spec
+
+`MenuButton` is a `Button` that opens a menu when activated. It renders a trailing chevron icon to communicate the presence of an associated menu, and manages `aria-expanded` to reflect whether the menu is currently open.
+
+`MenuButton` extends `Button` and inherits all of its accessibility behavior. This spec only covers what is **specific** to `MenuButton`. For label requirements, the difference between `disabled` and `disabledFocusable`, anchor (`as="a"`) rendering, contrast considerations across appearance variants, target size, motion, and base keyboard activation, see the [Button Accessibility Spec](?path=/docs/concepts-developer-accessibility-components-button--docs).
+
+## Usage
+
+### When to choose MenuButton
+
+Use `MenuButton` when activation should open a menu of items for the user to choose from. If activation performs a single direct action with no associated menu, use `Button`. If activation performs a primary action and the user needs an alternate way to reach related variations, use `SplitButton`.
+
+Despite its name, it is possible to use `MenuButton` for any Button that opens/closes a non-modal popup, such as a Popover.
+
+`MenuButton` is the typical trigger for the `Menu` component, and is what `MenuTrigger` produces by default when its `disableButtonEnhancement` prop is not set.
+
+### Implementing MenuButton
+
+#### Use with Menu and MenuTrigger
+
+The recommended pattern is to wrap `MenuButton` in `MenuTrigger` inside a `Menu`. `MenuTrigger` handles the ARIA wiring (`aria-haspopup`, `aria-controls`, and toggling `aria-expanded`) and the keyboard behavior to open and close the menu, including <kbd>Down</kbd> arrow to open the menu and place focus on the first item, and <kbd>Esc</kbd> to close the menu and return focus to the trigger.
+
+```tsx
+<Menu>
+  <MenuTrigger disableButtonEnhancement>
+    <MenuButton>Open menu</MenuButton>
+  </MenuTrigger>
+  <MenuPopover>
+    <MenuList>
+      <MenuItem>Item a</MenuItem>
+      <MenuItem>Item b</MenuItem>
+    </MenuList>
+  </MenuPopover>
+</Menu>
+```
+
+When used this way, `MenuButton`'s only ARIA responsibility is reflecting the open/closed state via `aria-expanded`, which `MenuTrigger` sets.
+
+#### Standalone use
+
+If `MenuButton` is used outside of `MenuTrigger`, the author is responsible for:
+
+1. Setting `aria-expanded` to reflect whether the menu is currently open. `MenuButton` normalizes the `aria-expanded` prop to a boolean — string values like `"true"` and `"false"` are accepted and converted, but the attribute is always rendered as a boolean.
+2. Setting `aria-haspopup="menu"` if the button opens a Fluent Menu, or other popup that has `role="menu".
+3. Optional: For buttons that open a popup with `role="dialog"`, setting `aria-haspopup="dialog"` is recommended. MenuButton should not be used for any other supported values of `aria-haspopup` aside from `menu` and `dialog`.
+4. Move keyboard focus into the popup when it opens, and return focus to the `MenuButton` when the popup closes.
+
+Standalone use is uncommon; prefer the `Menu` + `MenuTrigger` pattern unless there is a concrete reason not to.
+
+#### Label
+
+Like `Button`, `MenuButton` requires an accessible label. The label rules from [Button](?path=/docs/concepts-developer-accessibility-components-button--docs) apply unchanged.
+
+The trailing chevron `menuIcon` is decorative and does not contribute to the accessible name. For an icon-only `MenuButton` (a `MenuButton` with no children), provide an `aria-label` describing what the menu contains, not the chevron itself — for example, `aria-label="More actions"` rather than `aria-label="Expand"`.
+
+When an icon-only `MenuButton` has both an `icon` slot and no children, the `menuIcon` is omitted from the rendered output (see [renderMenuButton.tsx](packages/react-components/react-button/library/src/components/MenuButton/renderMenuButton.tsx#L20)) so the button does not render two icons.
+
+## Semantics
+
+`MenuButton`'s root element has the same role mapping as `Button`. The only addition is the `aria-expanded` attribute on the root, which is always present (rendered as either `true` or `false`).
+
+| Slot     | Role   | Notes                                                                                          |
+| -------- | ------ | ---------------------------------------------------------------------------------------------- |
+| root     | button | `aria-expanded` is always set; `aria-haspopup` and `aria-controls` are added by `MenuTrigger`. |
+| icon     | —      | Decorative leading icon, same as `Button`.                                                     |
+| menuIcon | —      | Decorative trailing chevron (`ChevronDownRegular` by default).                                 |
+
+Because the chevron is decorative, screen readers communicate the presence of the associated menu through `aria-haspopup` (announced as "menu") and `aria-expanded`, not through the icon itself.
+
+## Keyboard interaction
+
+`MenuButton` itself implements only the activation keys inherited from `Button` — <kbd>Enter</kbd> and <kbd>Space</kbd>. The keys that interact with the menu (<kbd>Down</kbd>, <kbd>Esc</kbd>, type-ahead, etc.) are handled by `Menu` and `MenuTrigger`, not by `MenuButton`, and are documented in the `Menu` accessibility spec.
+
+## Windows contrast themes (high contrast mode)
+
+`MenuButton` adds an "expanded" visual state on top of `Button`'s appearance variants. When `aria-expanded="true"`, the button changes to a selected/pressed style. In Windows contrast themes:
+
+- The expanded state uses the same system colors as the equivalent `Button` `:hover` state, so the open state remains visible in forced colors.
+- The leading `icon` slot's color is set to `Highlight` on hover when expanded, ensuring the icon stays visible against the hover background.
+
+All other forced-colors behavior is inherited from `Button`.
diff --git a/packages/react-components/react-button/stories/src/SplitButton/SplitButtonAccessibilitySpec.mdx b/packages/react-components/react-button/stories/src/SplitButton/SplitButtonAccessibilitySpec.mdx
new file mode 100644
index 0000000000000..948a7777ef1a9
--- /dev/null
+++ b/packages/react-components/react-button/stories/src/SplitButton/SplitButtonAccessibilitySpec.mdx
@@ -0,0 +1,101 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title="Concepts/Developer/Accessibility/Components/SplitButton" />
+
+# SplitButton Accessibility Spec
+
+`SplitButton` is a composite control: it pairs a primary action `Button` with a secondary `MenuButton` that opens a menu of related variations on that action. The two buttons are visually joined but are independently focusable and independently activatable.
+
+`SplitButton` is composed of `Button` and `MenuButton`, and inherits all of their accessibility behavior. This spec only covers what is **specific** to the composite. For label requirements, the difference between `disabled` and `disabledFocusable`, anchor (`as="a"`) rendering, contrast considerations, target size, motion, and base keyboard activation, see the [Button Accessibility Spec](?path=/docs/concepts-developer-accessibility-components-button--docs) and the [MenuButton Accessibility Spec](?path=/docs/concepts-developer-accessibility-components-menubutton--docs).
+
+## Usage
+
+### When to choose SplitButton
+
+Use `SplitButton` when there is a single primary action that the user is most likely to take, **and** a set of related variations on that action that should be available without taking up additional space at rest. The classic example is a "Send" button with a chevron that opens "Send later", "Schedule send", etc.
+
+If there is no clear primary action — only a set of equally-weighted choices — use `MenuButton` instead. If there is a primary action with no associated menu, use `Button`.
+
+### Implementing SplitButton
+
+#### Use with Menu and MenuTrigger
+
+The recommended pattern is to use `SplitButton` with a `Menu` and `MenuTrigger`, passing the `MenuTrigger` props onto the `menuButton` slot:
+
+```tsx
+<Menu positioning="below-end">
+  <MenuTrigger disableButtonEnhancement>
+    {(triggerProps: MenuButtonProps) => (
+      <SplitButton
+        menuButton={{ ...triggerProps, 'aria-label': 'More send options' }}
+        primaryActionButton={{ onClick: send }}
+      >
+        Send
+      </SplitButton>
+    )}
+  </MenuTrigger>
+  <MenuPopover>
+    <MenuList>
+      <MenuItem>Send later</MenuItem>
+      <MenuItem>Schedule send</MenuItem>
+    </MenuList>
+  </MenuPopover>
+</Menu>
+```
+
+This wires the menu half to the popup correctly (`aria-haspopup`, `aria-expanded`, `aria-controls`) and leaves the primary half as a plain action button.
+
+#### Label
+
+The two halves of `SplitButton` need separate accessible names because they are separate focusable controls.
+
+- The **primary action button** is labelled the same way any `Button` is labelled — usually by its visible text content, or by `aria-label` if there is none.
+- The **menu button** is labelled by the primary action button by default. `useSplitButton_unstable` assigns `id` to the primary action button and sets `aria-labelledby` on the menu button to point at it, **only** if the consumer has not already provided `aria-label` or `aria-labelledby` on the `menuButton` slot ([useSplitButton.ts:62-69](packages/react-components/react-button/library/src/components/SplitButton/useSplitButton.ts#L62-L69)).
+
+This default produces a useful fallback announcement: a screen reader announces the menu half with the primary action's text plus the role ("menu button") and the `aria-expanded` state. For the "Send" example, without an `aria-label` the menu button would be announced as "Send, menu button, collapsed".
+
+It is good practice to provide a more descriptive, localized, custom accessible name to the `menuButton` slot such as "More send options" in the earlier example.
+
+#### Disabled state
+
+Setting `disabled` or `disabledFocusable` on `SplitButton` cascades down to both the primary action button and the menu button via the slot default props ([useSplitButton.ts:32-58](packages/react-components/react-button/library/src/components/SplitButton/useSplitButton.ts#L32-L58)). The two halves cannot be independently disabled at the top level — to disable only one, pass `disabled` directly on the `primaryActionButton` or `menuButton` slot.
+
+The visual disabled styling is applied to both halves, plus a disabled border color on the inner seam between them so the visual joinery still reads as disabled.
+
+#### Target size
+
+The menu half of `SplitButton` is narrower than a standalone `MenuButton` because it does not render text. To meet [WCAG 2.5.8 Target Size (Minimum)](https://w3c.github.io/wcag/understanding/target-size-minimum.html), the styles enforce a minimum width of 24px on the menu button via the `MIN_TARGET_SIZE` constant ([useSplitButtonStyles.styles.ts:17](packages/react-components/react-button/library/src/components/SplitButton/useSplitButtonStyles.styles.ts#L17)).
+
+When overriding layout styles, authors must verify that **both** halves remain at least 24×24 CSS pixels. This is especially relevant for the menu half at the `small` size, where it is closest to the minimum.
+
+## Semantics
+
+`SplitButton` renders a non-interactive `<div>` wrapper around two independently-focusable buttons:
+
+| Slot                | Role   | States and properties                                                                                                        |
+| ------------------- | ------ | ---------------------------------------------------------------------------------------------------------------------------- |
+| root                | none   | A plain `<div>` with no role.                                                                                                |
+| primaryActionButton | button | All `Button` semantics. Carries an internal `id` used for menu button labelling.                                             |
+| menuButton          | button | All `MenuButton` semantics. `aria-expanded` is always set; `aria-labelledby` points at the primary action button by default. |
+
+The wrapper does not have a group role or any composite role. `SplitButton` is two independent buttons that happen to be visually adjacent; assistive tech treats them as two separate tab stops and announces each individually.
+
+When customizing the SplitButton or placing it into arrow-navigation regions like Toolbar, it is important to ensure that the root slot is never focusable and does not get an interactive role.
+
+## Keyboard interaction
+
+`SplitButton` produces **two tab stops**: the primary action button and the menu button, in that DOM order. When used within arrow-navigation groups like Toolbar, `SplitButton` has two arrow stops. This behavior should not be overridden -- for robust cross-platform screen reader accessibility, it is important that each button is independently exposed and focused.
+
+## Focus indicator
+
+Each half has its own visually distinct focus indicator.
+
+## Windows contrast themes (high contrast mode)
+
+The inner seam between the primary action button and the menu button has its own forced-colors handling in `useSplitButtonStyles.styles.ts`:
+
+- For `primary`, the inner border uses `HighlightText` at rest and `Highlight` on hover and active — opposite of the outer border — so the visual division between the two halves stays visible against the highlighted background.
+- For `subtle` and `transparent`, the inner border uses transparent background tokens, matching the rest of the button.
+- When disabled, the inner border uses `GrayText` to match the rest of the disabled border.
+
+All other forced-colors behavior is inherited from `Button` and `MenuButton`.
diff --git a/packages/react-components/react-checkbox/stories/src/Checkbox/CheckboxAccessibilitySpec.mdx b/packages/react-components/react-checkbox/stories/src/Checkbox/CheckboxAccessibilitySpec.mdx
new file mode 100644
index 0000000000000..704fe0c525524
--- /dev/null
+++ b/packages/react-components/react-checkbox/stories/src/Checkbox/CheckboxAccessibilitySpec.mdx
@@ -0,0 +1,148 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title="Concepts/Developer/Accessibility/Components/Checkbox" />
+
+# Checkbox Accessibility Spec
+
+`Checkbox` lets a user toggle an option on, off, or — in some cases — into a mixed state representing partial selection of a group. Internally it renders a real `<input type="checkbox">` element with a custom visual indicator, and uses the native input for all ARIA semantics and keyboard interaction.
+
+Because the underlying control is a native checkbox, `Checkbox` inherits the browser's built-in accessibility behavior: focus, role, checked state, and the platform keyboard contract are all handled by the browser. The visible square (or circle) the user sees is a separate `aria-hidden` element rendered next to the input; it does not contribute to the accessibility tree.
+
+## Usage
+
+### When to choose Checkbox
+
+#### Checkbox vs. Switch
+
+This is largely a visual choice -- both Checkbox and Switch are standalone controls that support on/off user input and communicate their state and state changes in almost identical ways. One difference is that Checkbox supports an `indeterminate` or `checked="mixed"` state, and Switch does not. The Switch control uses an `<input type="checkbox">` as the underlying interactive element, so all keyboard behavior is identical. While Switch adds`role="switch"`, the difference to screen reader users is negligible.
+
+#### Checkbox vs. ToggleButton
+
+ToggleButton is another control with an on/off user-selected state. The difference here is also largely visual, though ToggleButton is semantically a button and hints towards users that pressing it will have an immediate effect on the page. Checkbox, in contrast, is traditionally a form control. However, in the modern web, checkbox inputs may be used outside of a form and have immediate effects when toggled. Both choices are ultimately accessible for any standalone on/off user input.
+
+#### Checkbox vs. Radio
+
+Use `Checkbox` when multiple options can be selected independently, or when a single option can be turned on or off. Use a `RadioGroup` when the user must choose exactly one from a set of mutually exclusive options.
+
+#### Multiselect Dropdown vs. Checkboxes
+
+For fewer than ~10 options, a checkbox group is significantly more usable and accessible than a multiselect `Dropdown` or `Combobox`. Prefer checkboxes for small option sets.
+
+#### Tri-state (mixed) checkboxes
+
+Use `checked="mixed"` when the checkbox controls a group of sub-options that are partially selected (for example, a "Select all" master checkbox above a list where some but not all items are selected). The mixed state is announced by screen readers as "mixed" or "partially checked", and is the standard ARIA pattern for this case.
+
+The `circular` shape variant is **only** appropriate for tasks-style UI (a checklist), where it is unambiguously a completion control. Do not use `circular` for general form checkboxes — users will mistake it for a radio button.
+
+### Checkbox within other controls
+
+There are multiple other types of composite widgets that will sometimes visually display a checked/unchecked icon: multiselect Dropdown and Combobox, Tree, and Menu. However, all of these have their own specific semantic ways of exposing selection (e.g. `role="menuitemcheckbox` inside a `role="menu"` or `aria-checked` on a `role="treeitem"`). Checkbox should not be directly used in any of these controls. Nested interactives are forbidden, so Checkbox is not a valid child of a menuitem, option, or treeitem.
+
+Instead of using the Checkbox control within these composite widgets, use the styles for the check indicator directly as a visual-only indication of selection combined with the component-specific selection semantics for the control in question.
+
+Checkbox may be used directly within Toolbar, which is the only composite / arrow-navigation control that supports flexible interactive children.
+
+### Implementing Checkbox
+
+#### Programmatic label
+
+`Checkbox` does not render its own visible label text unless the `label` prop is set. Authors must provide a label one of three ways:
+
+```tsx
+<Checkbox label="I agree to the terms" />
+```
+
+The `label` prop renders a `<label>` element with `htmlFor` pointing at the internal input id, so clicking the label text toggles the checkbox.
+
+When `Checkbox` is wrapped in `Field`, the field's label is associated with the checkbox automatically via the same `htmlFor` mechanism, and there is no need to set `label` on the checkbox itself:
+
+```tsx
+<Field label="I agree to the terms">
+  <Checkbox />
+</Field>
+```
+
+If neither of those layouts fits, use `aria-label` or `aria-labelledby` on the `<Checkbox>` to point at visible label text elsewhere on the page. `aria-label` should be avoided when a visible label is available, since screen reader and voice control users benefit from the labels matching what they see on screen.
+
+#### Visual label
+
+Per [WCAG 3.3.2 — Labels or Instructions](https://w3c.github.io/wcag/understanding/labels-or-instructions.html), every checkbox needs a visible label or visibly associated text. The visible text and the programmatic accessible name should match.
+
+A checkbox with **no** visible label (only an `aria-label`) is acceptable only when the surrounding visual context makes the meaning obvious — for example, checkboxes in the first column of a table, where another column in the row serves as the visible label.
+
+#### Field integration
+
+When `Checkbox` is inside `Field`, `Field` automatically applies:
+
+- `id` — generated and used for the `<label htmlFor>` association.
+- `aria-labelledby` — set if the consumer overrides `id` so that the input is still labelled correctly.
+- `aria-describedby` — points at the field's validation message and hint, merged with any consumer-provided value.
+- `required` — applied as the native attribute on the `<input>` (Checkbox opts in to `supportsRequired`).
+
+`Checkbox` does **not** automatically set `aria-invalid` from `Field`'s `validationState`. There is no error visual styling on the checkbox itself; communicate validation through the field's validation message text.
+
+When `Checkbox` is not inside `Field`, the consumer is responsible for `aria-describedby`, `aria-invalid`, and `required` if those are needed.
+
+#### Tri-state (mixed)
+
+`Checkbox` exposes its tri-state via the `checked` and `defaultChecked` props, which accept `true`, `false`, or the string `"mixed"`. Internally, `"mixed"` maps to the native [`indeterminate`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox#indeterminate_state_checkboxes) property on the `<input>`, which is what assistive technologies read to announce "mixed" or "partially checked".
+
+The mixed state can only be set programmatically (it is not a value the user can toggle to). The standard pattern is:
+
+1. The consumer determines that not all sub-items are selected and sets `checked="mixed"` on the master checkbox.
+2. The user activates the master checkbox.
+3. `onChange` fires with `data.checked = false` (since the native input was indeterminate before activation, the browser treats the activation as a transition away from indeterminate).
+4. The consumer updates its model — typically clearing or selecting all sub-items — and the next render passes a non-mixed `checked` value.
+
+Because the mixed → next-state transition is driven by the consumer's `onChange` handler, authors must ensure that handler updates state in a way that does not leave the checkbox stuck in `"mixed"` after a user toggle.
+
+#### Disabled
+
+`Checkbox` supports the native `disabled` attribute, which removes the input from the tab order and prevents toggling. There is no `disabledFocusable` analog — checkboxes that need to remain focusable in a roving-tabindex context should use the native disabled behavior, since a disabled form input is reliably announced by screen readers.
+
+When disabled, the cursor on the root becomes `default`, all colors switch to disabled tokens, and the indicator's color is mapped to `GrayText` in Windows contrast themes.
+
+#### Click target
+
+The hidden `<input>` is sized to cover the visible indicator plus the surrounding padding, so clicking anywhere on the indicator (or the empty space immediately around it) toggles the checkbox. Clicking the `<label>` element also toggles the checkbox via the native `<label htmlFor>` association.
+
+When customizing layout, ensure the combined indicator + click-padding area remains at least 24×24 CSS pixels per [WCAG 2.5.8 Target Size (Minimum)](https://w3c.github.io/wcag/understanding/target-size-minimum.html). The default sizes meet this.
+
+## Semantics
+
+`Checkbox` is a composition of a native input, a visual indicator, and an optional label:
+
+| Slot      | Role              | States and properties                                                                                                                                                                        |
+| --------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| root      | none              | A plain `<span>` with no role; used for layout, focus-within outline, and click-target sizing.                                                                                               |
+| input     | checkbox (native) | `type="checkbox"`; `checked` reflects `true`/`false`; `indeterminate` reflects `"mixed"`; `disabled`, `required`, `aria-labelledby`, `aria-describedby` as applied by Field or the consumer. |
+| indicator | none              | A `<div>` with `aria-hidden="true"`; the visible square or circle. Purely presentational.                                                                                                    |
+| label     | label (native)    | A `<label htmlFor={input.id}>` from `@fluentui/react-label`. Clicking it toggles the input.                                                                                                  |
+
+Note: never set `aria-checked` on a Checkbox, since it conflicts in unexpected and unsupported ways with the native `checked` property.
+
+Focus lives on the `<input>` element. The visible focus indicator is drawn on the root via `:focus-within` from `createFocusOutlineStyle` in `@fluentui/react-tabster`, because the actual `<input>` is `opacity: 0` and would not show its native focus ring.
+
+The indicator is not part of the accessibility tree. Screen readers announce the checkbox using the native input's role and `checked`/`indeterminate` state, with the label text as its accessible name — the visual checkmark is not announced separately.
+
+## Keyboard interaction
+
+`Checkbox` is a single tab stop. All keyboard behavior comes from the native `<input type="checkbox">` element.
+
+| Key                               | Result                                           |
+| --------------------------------- | ------------------------------------------------ |
+| <kbd>Tab</kbd>                    | Moves focus to the checkbox.                     |
+| <kbd>Shift</kbd> + <kbd>Tab</kbd> | Moves focus to the checkbox from a later target. |
+| <kbd>Space</kbd>                  | Toggles the checkbox. Fires `onChange`.          |
+
+There is no <kbd>Enter</kbd> activation on a checkbox — pressing <kbd>Enter</kbd> inside a form submits the form, matching native behavior.
+
+When `disabled` is set, the input is removed from the tab order entirely and is not interactable.
+
+## Windows contrast themes (high contrast mode)
+
+`Checkbox` relies on native browser behavior to provide forced-colors values for most interaction states. The component itself only adds one explicit forced-colors rule: the disabled state maps the root and indicator colors to `GrayText`, so the disabled affordance matches the platform's disabled-control color. This is because the border is on the indicator slot and not on the native input, so does not automatically set the correct color based on the input element's state.
+
+## Motion and animation
+
+`Checkbox` has no animation. State changes (checked / unchecked / mixed) are immediate. There is therefore nothing to gate on `prefers-reduced-motion`.
diff --git a/packages/react-components/react-combobox/stories/src/Dropdown/DropdownAccessibility.mdx b/packages/react-components/react-combobox/stories/src/Dropdown/DropdownAccessibilitySpec.mdx
similarity index 100%
rename from packages/react-components/react-combobox/stories/src/Dropdown/DropdownAccessibility.mdx
rename to packages/react-components/react-combobox/stories/src/Dropdown/DropdownAccessibilitySpec.mdx
diff --git a/packages/react-components/react-input/stories/src/Input/InputAccessibilitySpec.mdx b/packages/react-components/react-input/stories/src/Input/InputAccessibilitySpec.mdx
new file mode 100644
index 0000000000000..d4d6f7733baff
--- /dev/null
+++ b/packages/react-components/react-input/stories/src/Input/InputAccessibilitySpec.mdx
@@ -0,0 +1,186 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title="Concepts/Developer/Accessibility/Components/Input" />
+
+# Input Accessibility Spec
+
+`Input` is a single-line text entry control. It wraps a native HTML `<input>` element in a styled `<span>` container, with optional `contentBefore` and `contentAfter` slots for in-field decoration (icons, units, prefixes, or action buttons).
+
+Because the rendered control is a real `<input>`, `Input` inherits the browser's built-in accessibility behavior for text fields: caret movement, selection, IME composition, autofill, password masking, spellcheck, and the platform-native keyboard contract are all handled by the browser. This spec covers what Fluent layers on top: labelling, the `Field` integration, the `contentBefore` / `contentAfter` slots, validation, and visual considerations.
+
+## Usage
+
+### When to choose Input
+
+`Input` is for free-form single-line text entry. The component supports a constrained set of text-based `type` values: `text` (default), `email`, `password`, `search`, `tel`, `url`, `date`, `datetime-local`, `month`, `number`, `time`, and `week`. For non-text input types like `button`, `checkbox`, or `radio`, use the appropriate Fluent component instead.
+
+#### Input vs. SpinButton
+
+Use `SpinButton` (not `Input` with `type="number"`) when the value is a number within a defined range and the user benefits from incremental adjustment with arrow keys, or from explicit min/max boundaries that are announced to assistive technology. `Input type="number"` does not enforce min/max in a way screen readers reliably announce, and does not support non-numerical characters such as commas, dollar signs, etc.
+
+#### Input vs. Textarea
+
+Use `Textarea` when the user needs to enter multi-line content (comments, descriptions, free-form notes). Use `Input` for single-line entry, even if the value is long — the input will scroll horizontally rather than wrap.
+
+#### Input vs. Combobox / Dropdown
+
+If the user is selecting from a known set of values, prefer `Combobox` (which allows freeform entry alongside selection) or `Dropdown` / `Select`. `Input` should be reserved for cases where the value space is open-ended.
+
+### Implementing Input
+
+#### Programmatic Label
+
+`Input` does not render its own label. Authors must always associate the input with visible label text. The recommended pattern is to wrap `Input` in a `Field`, which sets `id` and the label association automatically:
+
+```tsx
+<Field label="Full name">
+  <Input />
+</Field>
+```
+
+If `Field` is not appropriate for the layout, use `Label` directly with `htmlFor`:
+
+```tsx
+<Label htmlFor="full-name">Full name</Label>
+<Input id="full-name" />
+```
+
+Other options:
+
+1. `aria-labelledby="label-id"` on the `<Input>`, pointing at the id of visible label text elsewhere on the page.
+2. `aria-label="label text string"` on the `<Input>`. Use sparingly — some sort of visible or contextual label is required.
+
+#### Visual Label
+
+All form fields including Input require a visible label per [WCAG 3.3.2 -- Labels or Instructions](https://w3c.github.io/wcag/understanding/labels-or-instructions.html). That label does not need to be a `<label>` element, but there must be text that is visually associated with the input that functions as its label. The programmatic accessible name of the input should match that text.
+
+There are only two exceptions to this rule:
+
+1. For top-level search inputs that have a search icon -- the search icon is considered generally understood and can function as the visible label for one search input in the current context. If there are multiple search inputs with different functions, they will still require a specific text label, however.
+2. In chat applications such as Teams or M365 Copilot, where the main content area contains exactly one chat input, usually at the bottom of the pane. In this case, we consider the surrounding context (it being a chat application) + visual language of the input staying at the bottom of the pane to be sufficient for a user to understand what the input does.
+
+#### Placeholder
+
+The `placeholder` prop is **not** a substitute for a label. Placeholder text disappears as soon as the user starts typing, while WCAG requires a persistent visual label to be present. Placeholder also fails contrast requirements in some themes by design.
+
+Because the `placeholder` is not persistent, it also should never be used for user instructions such as "Type / for more suggestions", unless those instructions are easily accessible elsewhere.
+
+#### Field integration
+
+When `Input` is rendered inside `Field`, `Field` automatically wires up:
+
+- `id` — generated and applied so the field's `<Label>` `htmlFor` points at the input.
+- `aria-labelledby` — set if the consumer's `id` does not match the label's `htmlFor` (so the input is still labelled even when the consumer overrides the id, or if Field is used with an element that does not support native `<label>` + `for` association).
+- `aria-describedby` — set to point at the validation message and hint elements, merged with any consumer-provided `aria-describedby`.
+- `aria-invalid` — set to `true` when `Field`'s `validationState` is `"error"`.
+- `required` — applied as the native attribute when `Field` is marked required (Input opts in to `supportsRequired`, so the attribute used is `required`, not `aria-required`).
+
+When `Input` is **not** inside `Field`, the consumer is responsible for any of these attributes that are needed (`aria-describedby` for hint/error text, `aria-invalid` for validation state, `required`).
+
+#### contentBefore and contentAfter
+
+The `contentBefore` and `contentAfter` slots render inside the visual input border, on either side of the editable text. They are rendered as siblings of the `<input>` element in DOM order: `contentBefore` precedes the input, `contentAfter` follows it.
+
+Three common patterns each have different accessibility implications:
+
+**Decorative icon.** A non-interactive icon describing the field (for example, a magnifying glass on a search field). The icon is purely visual and does not need to be in the accessible name or focusable.
+
+```tsx
+<Field label="Search">
+  <Input contentBefore={<SearchRegular />} />
+</Field>
+```
+
+**Action button.** A `Button` that performs an action related to the input (for example, a microphone button to dictate input). The button is a separate focusable control with its own accessible name.
+
+```tsx
+<Field label="First name">
+  <Input contentAfter={<Button appearance="transparent" icon={<MicRegular />} aria-label="Start dictation" />} />
+</Field>
+```
+
+The button is reached by <kbd>Tab</kbd> after the input (or before it, if placed in `contentBefore`). Authors must ensure the button has its own accessible name — the input's label does not propagate to it.
+
+**Presentational text that completes the field's meaning.** For example, a `$` prefix and `.00` suffix on an amount field. These are visible text that materially affects how the input value should be read, but they are **not** part of the input's value or its accessible name by default. To make the input announce as "Amount to pay, dollars, dot zero zero", the consumer must write concise human-readable alternative text and include it in `aria-labelledby` or an `aria-label` explicitly:
+
+```tsx
+<Field label="Amount to pay">
+  <Input
+    contentBefore={<Text id="prefix">$</Text>}
+    contentAfter={<Text id="suffix">.00</Text>}
+    aria-labelledby={`${fieldLabelId} prefix suffix`}
+  />
+</Field>
+```
+
+This is the consumer's responsibility — `Input` does not infer the accessible name from `contentBefore` / `contentAfter`. The [ContentBeforeAfter](?path=/story/components-input--content-before-after) story demonstrates all three patterns.
+
+#### Disabled
+
+`Input` supports the native `disabled` attribute, which removes the input from the tab order and prevents value changes. There is no `disabledFocusable` analog for `Input` — keeping a disabled text field in the tab order is rarely useful, and the native disabled behavior is the standard. The `readonly` attribute is a native alternative state for inputs that is still focusable and allows text to be read and copied but not edited.
+
+When disabled, the focus underline animation and focus outline are suppressed, the cursor becomes `not-allowed`, the border switches to `colorNeutralStrokeDisabled` (or `GrayText` in forced colors), and any `contentBefore` / `contentAfter` content is colored to match.
+
+Focusable content placed in `contentBefore` / `contentAfter` is **not** automatically disabled by the parent `Input`'s `disabled` prop; authors who want the inner button to also be disabled must pass `disabled` on it explicitly.
+
+#### Validation
+
+When `Input` is inside `Field` with `validationState="error"`, `aria-invalid="true"` is applied to the `<input>` and the wrapper switches to the red border style. Outside of `Field`, the consumer can set `aria-invalid` directly — the red border style keys off the rendered `aria-invalid` attribute on the `<input>` ([useInputStyles.styles.ts:336](packages/react-components/react-input/library/src/components/Input/useInputStyles.styles.ts#L336)), so styling and ARIA stay in sync.
+
+The error **message** itself is not provided by `Input`. Use `Field`'s `validationMessage` (which is automatically wired into `aria-describedby`), or wire your own message element via `aria-describedby`. An `aria-invalid` value with no accompanying description tells the user the field is invalid but does not tell them why.
+
+Both `error` and `warning` validation states give the `validationMessage` a `role=alert` and will be announced to screen reader users as soon as they appear. Other validation states will not cause the message to be announced automatically. If this behavior is desired, use the `useAnnounce` utility to do so.
+
+#### Color contrast and appearance variants
+
+All inputs must have some part of their boundary meet 3:1 contrast against the background behind the input. The placeholder or value text are not sufficient to meet this requirement. Each appearance variant meets this contrast requirement in a different way:
+
+- `outline` (default) — the bottom border specifically uses `colorNeutralStrokeAccessible`, which is darker than the surrounding border tokens to meet the indicator-contrast requirement.
+- `underline` — only the bottom border is visible at rest, and meets 3:1 contrast against the background.
+- `filled-darker` and `filled-lighter` — these must be placed on a surface that provides at least 3:1 contrast against the input's background color, so the boundary of the input is still discernible.
+- `filled-darker-shadow` and `filled-lighter-shadow` — **deprecated**. Do not use in new code; they emit a console error in development.
+
+The bottom focus border (`::after`) uses `colorCompoundBrandStroke`, which is the brand color and is guaranteed to meet 3:1 against all supported page surfaces in the included themes.
+
+### Placing Input within an arrow-navigation region like Toolbar or Menu
+
+It is not recommended to place an input inside a horizontal arrow-navigable region like a `Toolbar`, since left/right arrow keys are already used within an input to move through characters in its value. If this is done, the consumer must provide a custom way to switch between navigating the input value and navigating the `Toolbar` with arrow keys.
+
+An `input` is not technically a valid child of other arrow-navigable controls like `Menu` -- doing so violates the ARIA spec's parent/child requirements for `role=menu`, as well as others like `role=tree` or `role=listbox`. However, the practical consequences of doing so are relatively low in severity **if** the input is the first interactive child of the menu or listbox. Exercise caution when doing so, and document both the ARIA violation and reason for doing so.
+
+If Input is used within a vertical arrow-navigation region like Menu or Listbox, do not put any interactive controls like `button` inside the `contentBefore` and `contentAfter` slots.
+
+## Semantics
+
+`Input` renders a wrapping `<span>` for styling and the actual `<input>` element for editing:
+
+| Slot          | Role             | States and properties                                                                                                                  |
+| ------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| root          | none             | A plain `<span>` with no role; used only for visual border and focus styling.                                                          |
+| input         | textbox (native) | `type` attribute; `aria-invalid`, `aria-describedby`, `aria-labelledby`, `disabled`, `required` as applied by `Field` or the consumer. |
+| contentBefore | none             | A `<span>` with no role; contains decorative or interactive content placed before the input.                                           |
+| contentAfter  | none             | A `<span>` with no role; contains decorative or interactive content placed after the input.                                            |
+
+Focus lives on the `<input>` element. The visual focus state (the animated bottom border) is applied to the root via `:focus-within`, but the focused element from a screen reader and keyboard perspective is always the `<input>`.
+
+The wrapping `<span>` is **not** a `<label>`. Clicking on the wrapper padding or on a non-focusable `contentBefore` / `contentAfter` does not move focus to the input. If a label-like click-to-focus surface is needed, wrap the input in a `<Label htmlFor>` or use `Field`, which provides the label semantics.
+
+## Keyboard interaction
+
+`Input` is a single tab stop. All editing key behavior comes from the browser's native `<input>` implementation and matches platform conventions.
+
+When `disabled` is set, the input is removed from the tab order entirely, and is not interactable.
+
+Focusable content placed in `contentBefore` or `contentAfter` is a separate tab stop. Within the rendered DOM order, the tab sequence is: `contentBefore` (if focusable) → `input` → `contentAfter` (if focusable).
+
+## Windows contrast themes (high contrast mode)
+
+`Input` relies almost entirely on the browser's native `<input>` behavior in Windows contrast themes. The native input adapts its background, text, caret, and placeholder colors to the user-selected theme without explicit overrides in the component's styles.
+
+The only explicit forced-colors rule on `Input` is for the disabled state: the border switches to `GrayText` so the disabled affordance matches the system disabled-control color. This is because the border style is on the parent root node and not on the `<input>` element itself, so it does not natively pick up the disabled state's color.
+
+Because `contentBefore` and `contentAfter` are arbitrary user-supplied content, their forced-colors behavior is the consumer's responsibility. Decorative icons typically need no special handling; interactive content (like a `Button` inside `contentAfter`) inherits whatever forced-colors handling that component provides.
+
+## Motion and animation
+
+The bottom focus border has two animations — one for focus in and one for focus out — using `durationNormal` (focus in) and `durationUltraFast` (focus out) respectively. Both animations are shortened to `0.01ms` when [`prefers-reduced-motion: reduce`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion) is set, effectively disabling the motion while preserving the final visual state. There is no other motion on `Input`.
diff --git a/packages/react-components/react-radio/stories/src/RadioGroup/RadioGroupAccessibilitySpec.mdx b/packages/react-components/react-radio/stories/src/RadioGroup/RadioGroupAccessibilitySpec.mdx
new file mode 100644
index 0000000000000..1e9b6f74aa51f
--- /dev/null
+++ b/packages/react-components/react-radio/stories/src/RadioGroup/RadioGroupAccessibilitySpec.mdx
@@ -0,0 +1,163 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title="Concepts/Developer/Accessibility/Components/RadioGroup" />
+
+# Radio and RadioGroup Accessibility Spec
+
+`RadioGroup` and `Radio` together implement the standard radio-button selection pattern: a group of mutually exclusive options where exactly one can be selected at a time. `RadioGroup` provides the `role="radiogroup"` container that aggregates the individual `Radio` items into a single labelled control, and propagates `name`, `value`, `disabled`, and `required` to its children via context.
+
+Each `Radio` renders a real `<input type="radio">` element with a custom visual indicator. As with `Checkbox`, the native input handles all ARIA semantics, focus, and keyboard interaction; the visible circle is `aria-hidden` and purely presentational.
+
+## Usage
+
+### When to choose Radio / RadioGroup
+
+#### Radio vs. Dropdown / Select
+
+Use `RadioGroup` when there are a small number of mutually exclusive options (roughly 2–6) and seeing all options at once helps the user decide. Use `Dropdown` or `Select` when the option list is long, when the options take a lot of vertical space, or when the selected value is more important than the alternatives.
+
+#### Radio vs. Checkbox or Switch
+
+Use `Radio` when exactly one option must be selected and the options are mutually exclusive. Use `Checkbox` or `Switch` for independent on/off toggles, or when multiple selections from a set are allowed.
+
+### Radio/RadioGroup within other controls
+
+RadioGroup and Radio should not be used within other composite controls like Menu, Tree, or Listbox. All of these have their own specific ways of exposing single-selection, and do not support nesting interactive controls like Radio within them. Instead of using the Radio control within these composite widgets, use the styles for the indicator directly as a visual-only indication of selection combined with the component-specific selection semantics for the control in question.
+
+Radio and RadioGroup also should not be used directly within Toolbar, since Radios change selection as you arrow between them. If used within a Toolbar, this means the user would not be able to arrow past a RadioGroup without altering their selection. Instead of using RadioGroup and Radio, use the ToolbarRadioGroup and ToolbarRadioButton made for this purpose, which do not alter selection on focus.
+
+## Implementing Radio and RadioGroup
+
+### Always use RadioGroup
+
+Individual `Radio` components must always be rendered inside a `RadioGroup`. `RadioGroup` provides:
+
+- `role="radiogroup"` on the wrapper `<div>`, which tells assistive technologies to treat the contained radios as a single composite control.
+- A shared `name` attribute on every child `Radio`'s `<input>`, which is what the browser uses to enforce mutual exclusivity and to expose the group via the platform accessibility API. If `name` is not provided, `RadioGroup` generates one.
+- Propagation of `value` / `defaultValue` so the selected `Radio` is determined by comparing each `Radio`'s `value` against the group's `value`.
+- Propagation of `disabled`, `required`, and `aria-describedby` to all child radios.
+
+A stand-alone `Radio` outside of `RadioGroup` does not have a group container, is not announced as part of a set, and does not share a `name` with sibling radios — which means the browser will not enforce mutual exclusivity. Always wrap radios in `RadioGroup`.
+
+### RadioGroup label
+
+`RadioGroup` requires a label that names the _group_ as a whole — for example, "Favorite fruit", not the individual options. The recommended pattern is `Field`:
+
+```tsx
+<Field label="Favorite fruit">
+  <RadioGroup>
+    <Radio value="apple" label="Apple" />
+    <Radio value="banana" label="Banana" />
+  </RadioGroup>
+</Field>
+```
+
+`Field` sets `aria-labelledby` on the `RadioGroup` to point at the field's label text. Without `Field`, use `aria-labelledby` or `aria-label` directly on the `RadioGroup`:
+
+```tsx
+<Label id="fruit-label">Favorite fruit</Label>
+<RadioGroup aria-labelledby="fruit-label">
+  ...
+</RadioGroup>
+```
+
+### Radio labels
+
+Each individual `Radio` also needs its own label, which is what the `Radio`'s `label` prop provides. The `Radio`'s label is rendered as an associated `<label>` element so clicking the label text selects the radio. Avoid using `aria-label` or `aria-labelledby` on `Radio` controls unless it is an edge case such as rendering them in the first column of a Table or DataGrid.
+
+### Visual labels
+
+Per [WCAG 3.3.2 — Labels or Instructions](https://w3c.github.io/wcag/understanding/labels-or-instructions.html), the group needs a visible label and also each radio needs a visible label.
+
+For radios, the visible label is rendered from the `label` prop. The label slot may contain inline content (text, a `Text` component) or images. It is generally best practice to not include interactive elements in the label — focusable content inside a `<label>` causes the click-to-select behavior to misroute.
+
+For sublabels or extra descriptive text per radio, render the additional text outside the `label` slot and wire it to the radio via `aria-describedby`. The [RadioGroupLabelSubtext](?path=/story/components-radiogroup--label-subtext) story demonstrates this pattern.
+
+### Field integration
+
+When `RadioGroup` is rendered inside `Field`, `useFieldControlProps_unstable` automatically applies:
+
+- `aria-labelledby` — points at the field's label.
+- `aria-describedby` — points at the field's validation message and hint, merged with any consumer-provided value. This is also propagated through context to each child `Radio`'s `<input>`.
+- `required` — propagated to each child `Radio` via context, applied as the native `required` attribute on each `<input>`.
+
+`RadioGroup` does **not** automatically set `aria-invalid` from `Field`'s `validationState`. There is no error visual on the radios themselves; the validation message text is what communicates the error.
+
+### onChange behavior
+
+The `onChange` callback fires on **selection**, not deselection. When the user picks a new radio in the group, only the newly-selected `Radio`'s `onChange` fires, with the new `value` as data. The previously-selected radio does not fire `onChange` for its deselection.
+
+For most cases, prefer `RadioGroup`'s `onChange`, which fires on any selection change in the group and provides the newly-selected `value` regardless of which radio was selected.
+
+### Disabled
+
+`disabled` on `RadioGroup` propagates to every child `Radio` via context, applied as the native `disabled` attribute. Setting `disabled` on an individual `Radio` only disables that radio while leaving the others interactive — useful for showing an unavailable option in an otherwise-enabled group.
+
+There is no `disabledFocusable` analog. A disabled `Radio` is removed from the tab order, but the group's overall tab stop remains on the next non-disabled radio.
+
+### Layout
+
+`RadioGroup`'s `layout` prop controls how radios are arranged visually:
+
+- `vertical` (default) — one radio per line. Best for option lists where each label may be long.
+- `horizontal` — radios on a single line with the label after each indicator.
+- `horizontal-stacked` — radios on a single line with the label _below_ each indicator. Each `Radio`'s `labelPosition` defaults to `"below"` in this layout.
+
+Layout is purely visual; it does not change the DOM order of radios or the keyboard behavior.
+
+## Semantics
+
+### RadioGroup
+
+| Slot | Role       | States and properties                                                                              |
+| ---- | ---------- | -------------------------------------------------------------------------------------------------- |
+| root | radiogroup | `aria-labelledby` or `aria-label` (required); `aria-describedby` (optional); no native `required`. |
+
+`RadioGroup` is a `<div>` with `role="radiogroup"`. The `required` and `disabled` props are not exposed as ARIA properties on the group itself — they are propagated to each child `Radio`'s `<input>` as native attributes.
+
+### Radio
+
+| Slot      | Role           | States and properties                                                                                                                             |
+| --------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| root      | none           | A plain `<span>` with no role; used for layout and focus-within outline.                                                                          |
+| input     | radio (native) | `type="radio"`, shared `name` from group context, `checked` from value comparison, `disabled`, `required`, `aria-describedby` from group context. |
+| indicator | none           | A `<div>` with `aria-hidden="true"`; the visible circle. Purely presentational.                                                                   |
+| label     | label (native) | A `<label htmlFor={input.id}>` from `@fluentui/react-label`. Clicking it selects the radio.                                                       |
+
+Focus lives on each radio's `<input>` element. The visible focus indicator is drawn on the radio's root via `:focus-within` from `createFocusOutlineStyle` in `@fluentui/react-tabster`, because the actual `<input>` is `opacity: 0`.
+
+The indicator is `aria-hidden` — screen readers announce the radio using the native input's role and `checked` state, with the label text as its accessible name and the group's label as the surrounding group name.
+
+## Keyboard interaction
+
+`RadioGroup` participates in the standard radio-button keyboard pattern, which the browser implements natively:
+
+| Key                                            | Result                                                                                                                                      |
+| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| <kbd>Tab</kbd>                                 | Moves focus into the group. If a radio is selected, focus lands on the selected radio. If none is selected, focus lands on the first radio. |
+| <kbd>Shift</kbd> + <kbd>Tab</kbd>              | Reverses the order above.                                                                                                                   |
+| <kbd>Down</kbd> arrow / <kbd>Right</kbd> arrow | Moves focus to the next radio in the group and selects it. Wraps to the first after the last.                                               |
+| <kbd>Up</kbd> arrow / <kbd>Left</kbd> arrow    | Moves focus to the previous radio in the group and selects it. Wraps to the last before the first.                                          |
+| <kbd>Space</kbd>                               | Selects the focused radio (no-op if already selected).                                                                                      |
+
+Critically, the entire group is a **single tab stop**, not one tab stop per radio. <kbd>Tab</kbd> moves _past_ the group, not between its radios; arrow keys move between radios. This is the standard browser-implemented behavior for `<input type="radio">` elements that share a `name` and are inside a `radiogroup`. All arrow keys move focus between radios, regardless of the visual layout.
+
+Selection follows focus when navigating with arrow keys — moving focus to a radio with arrow keys also selects it. This matches both the native browser behavior and the ARIA radiogroup pattern.
+
+Disabled radios are skipped during arrow-key navigation.
+
+## Windows contrast themes (high contrast mode)
+
+`Radio` includes explicit forced-colors handling in `useRadioStyles.styles.ts`:
+
+- **Unchecked:** the indicator border uses `ButtonBorder` so the outline of each option is visible against the system background.
+- **Checked:** the indicator border, the filled inner circle (`::after`), and the checkmark color all map to `Highlight`, matching the platform's selected-control color.
+- **Disabled:** the indicator border, fill, and label text map to `GrayText`, matching the platform's disabled-control color.
+
+`RadioGroup` has no forced-colors handling of its own — it is a layout `<div>` and inherits the page's forced-colors background.
+
+The focus indicator (`createFocusOutlineStyle` on each Radio's root) uses tokens that resolve to the user-selected outline color in forced colors.
+
+## Motion and animation
+
+Neither `Radio` nor `RadioGroup` has any animation. Selection changes are immediate. There is no `prefers-reduced-motion` handling to apply.
diff --git a/packages/react-components/react-spinbutton/stories/src/SpinButton/SpinButtonAccessibility.mdx b/packages/react-components/react-spinbutton/stories/src/SpinButton/SpinButtonAccessibilitySpec.mdx
similarity index 100%
rename from packages/react-components/react-spinbutton/stories/src/SpinButton/SpinButtonAccessibility.mdx
rename to packages/react-components/react-spinbutton/stories/src/SpinButton/SpinButtonAccessibilitySpec.mdx
diff --git a/packages/react-components/react-textarea/stories/src/Textarea/TextareaAccessibilitySpec.mdx b/packages/react-components/react-textarea/stories/src/Textarea/TextareaAccessibilitySpec.mdx
new file mode 100644
index 0000000000000..de291bd540f20
--- /dev/null
+++ b/packages/react-components/react-textarea/stories/src/Textarea/TextareaAccessibilitySpec.mdx
@@ -0,0 +1,176 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title="Concepts/Developer/Accessibility/Components/Textarea" />
+
+# Textarea Accessibility Spec
+
+`Textarea` is a multi-line text entry control. It wraps a native HTML `<textarea>` element in a styled `<span>` container that provides the focus-indicator border animation. There is no slot for in-field decoration — `Textarea` exposes only the wrapper and the textarea itself.
+
+Because the rendered control is a real `<textarea>`, `Textarea` inherits the browser's built-in accessibility behavior for multi-line text fields: caret movement, line wrapping, selection, IME composition, autofill, spellcheck, scrolling, and the platform-native keyboard contract are all handled by the browser. This spec covers what Fluent layers on top: labelling, the `Field` integration, the `resize` prop, validation, and visual considerations.
+
+## Usage
+
+### When to choose Textarea
+
+`Textarea` is for free-form multi-line text entry: comments, descriptions, free-form notes, or any value that may legitimately wrap to multiple lines.
+
+#### Textarea vs. Input
+
+Use `Textarea` when the value may contain newlines or wrap across multiple visual lines. Use `Input` for single-line entry, even if the value is long — an `Input` scrolls horizontally rather than wrapping, which is the correct behavior for fields like name, email, or URL where the value is semantically a single line.
+
+A useful rule of thumb: if pressing <kbd>Enter</kbd> should commit the value (submit a form, run a search), use `Input`. If pressing <kbd>Enter</kbd> should insert a newline in the value, use `Textarea`.
+
+#### Textarea vs. a rich text editor
+
+Use `Textarea` for plain-text content. Use a rich text editor when the user needs to apply formatting (bold, italic, lists, links). A rich text editor is significantly more complex to make accessible than a `Textarea` — only adopt one when the formatting requirement is real or when nested links and buttons are needed.
+
+### Implementing Textarea
+
+#### Programmatic Label
+
+`Textarea` does not render its own label. Authors must always associate the textarea with visible label text. The recommended pattern is to wrap `Textarea` in a `Field`, which sets `id` and the label association automatically:
+
+```tsx
+<Field label="Description">
+  <Textarea />
+</Field>
+```
+
+If `Field` is not appropriate for the layout, use `Label` directly with `htmlFor`:
+
+```tsx
+<Label htmlFor="description">Description</Label>
+<Textarea id="description" />
+```
+
+Other options:
+
+1. `aria-labelledby="label-id"` on the `<Textarea>`, pointing at the id of visible label text elsewhere on the page.
+2. `aria-label="label text string"` on the `<Textarea>`. Use sparingly — some sort of visible or contextual label is required.
+
+#### Visual Label
+
+All form fields including Textarea require a visible label per [WCAG 3.3.2 -- Labels or Instructions](https://w3c.github.io/wcag/understanding/labels-or-instructions.html). That label does not need to be a `<label>` element, but there must be text that is visually associated with the textarea that functions as its label. The programmatic accessible name of the textarea should match that text.
+
+There is one exception worth calling out for `Textarea` specifically: in chat applications such as Teams or M365 Copilot, where the main content area contains exactly one chat composer, the surrounding context plus the visual language of the composer staying anchored at the bottom of the pane is generally sufficient for users to understand what the textarea does. Even in this case, an `aria-label` is required so the textarea has a programmatic name.
+
+#### Placeholder
+
+The `placeholder` prop is **not** a substitute for a label. Placeholder text disappears as soon as the user starts typing, while WCAG requires a persistent visual label to be present. Placeholder also fails contrast requirements in some themes by design.
+
+Because the `placeholder` is not persistent, it also should never be used for user instructions such as "Press Enter to add a new line" or "Type @ to mention someone" unless those instructions are easily accessible elsewhere — for example, in a hint slot provided by `Field`.
+
+#### Field integration
+
+When `Textarea` is rendered inside `Field`, `Field` automatically wires up:
+
+- `id` — generated and applied so the field's `<Label>` `htmlFor` points at the textarea.
+- `aria-labelledby` — set if the consumer's `id` does not match the label's `htmlFor` (so the textarea is still labelled even when the consumer overrides the id).
+- `aria-describedby` — set to point at the validation message and hint elements, merged with any consumer-provided `aria-describedby`.
+- `aria-invalid` — set to `true` when `Field`'s `validationState` is `"error"`.
+- `required` — applied as the native attribute when `Field` is marked required.
+- `size` — propagated from `Field` so the textarea matches the field's size.
+
+When `Textarea` is **not** inside `Field`, the consumer is responsible for any of these attributes that are needed (`aria-describedby` for hint/error text, `aria-invalid` for validation state, `required`).
+
+#### Resize
+
+The `resize` prop maps directly to the CSS `resize` property on the `<textarea>` and controls whether the user can drag a corner handle to resize the field:
+
+- `none` (default) — no resize handle. The textarea expands and scrolls within its size-defined min/max height.
+- `vertical` — the user can drag the bottom edge to make the textarea taller or shorter.
+- `horizontal` — the user can drag the right edge to make the textarea wider or narrower.
+- `both` — the user can drag the bottom-right corner to resize in both axes.
+
+The resize handle is a browser-native control and is only operable by mouse or touch pointer. **There is no keyboard equivalent** for the resize gesture, and assistive technologies do not expose the handle as a separate focusable target. This is a known limitation of the native `<textarea>` element across browsers, not a Fluent-specific issue.
+
+`resize: 'none'` is the default because it avoids exposing an inaccessible handle. When using any other value, ensure the textarea's default size is large enough that resizing is a convenience, not a requirement — a keyboard-only user who cannot operate the handle should never be forced to resize the field to use it.
+
+The size variants set bounded `min-height` and `max-height`: small (40–200px), medium (52–260px), large (64–320px). When the textarea is set to `resize: 'none'` and the content exceeds the max-height, the browser-native vertical scrollbar appears inside the textarea.
+
+#### Disabled
+
+`Textarea` supports the native `disabled` attribute, which removes the textarea from the tab order and prevents value changes. There is no `disabledFocusable` analog for `Textarea` — keeping a disabled text field in the tab order is rarely useful, and the native disabled behavior is the standard. The `readonly` attribute is a native alternative state for textareas that is still focusable and allows text to be read, selected, and copied but not edited.
+
+When disabled, the focus underline animation and focus outline are suppressed, the cursor becomes `not-allowed`, and the border switches to `colorNeutralStrokeDisabled` (or `GrayText` in forced colors). The disabled state also disables the resize handle, regardless of the `resize` prop value.
+
+#### Validation
+
+When `Textarea` is inside `Field` with `validationState="error"`, `aria-invalid="true"` is applied to the `<textarea>` and the wrapper switches to the red border style. Outside of `Field`, the consumer can set `aria-invalid` directly — the red border style keys off the rendered `aria-invalid` attribute on the `<textarea>` ([useTextareaStyles.styles.ts:227](packages/react-components/react-textarea/library/src/components/Textarea/useTextareaStyles.styles.ts#L227)), so styling and ARIA state stay in sync.
+
+The error **message** itself is not provided by `Textarea`. Use `Field`'s `validationMessage` (which is automatically wired into `aria-describedby`), or wire your own message element via `aria-describedby`. An `aria-invalid` value with no accompanying description tells the user the field is invalid but does not tell them why.
+
+Both `error` and `warning` validation states give the `validationMessage` a `role=alert` and will be announced to screen reader users as soon as they appear. Other validation states will not cause the message to be announced automatically. If this behavior is desired, use the `useAnnounce` utility to do so.
+
+#### Character limits
+
+When using `maxLength` to cap the value, consider also exposing a visible character counter so users — especially those with cognitive disabilities — can see how much space remains before they hit the limit. Wire the counter to the textarea via `aria-describedby` so screen reader users hear the remaining count when the field is focused.
+
+Do **not** put `aria-live="polite"` (or any other live region) directly on the counter element. Firing a live region while the user is actively typing collides with the screen reader's native keyboard echo — the reader is already announcing each typed character, and a simultaneous live-region update either gets dropped, gets queued behind every keystroke, or talks over the echo. As a rule, **never trigger a live-region announcement at the same time the user is typing.**
+
+Instead, use the [`useTypingAnnounce`](https://storybooks.fluentui.dev/react/?path=/docs/utilities-aria-live-usetypingannounce--docs) utility, which is designed for exactly this case. It debounces announcements so they fire only after the user pauses typing, which lets the screen reader's typing echo finish without interference and avoids flooding the live region with every keystroke. Trigger it when the remaining character count crosses a meaningful threshold (for example, the last 20 characters), not on every input event.
+
+`maxLength` itself is a native attribute on `<textarea>` and is enforced by the browser — additional characters past the limit are silently dropped, which can be confusing without a visible counter.
+
+#### Color contrast and appearance variants
+
+All textareas must have some part of their boundary meet 3:1 contrast against the background behind the textarea. The placeholder or value text are not sufficient to meet this requirement. Each appearance variant meets this contrast requirement in a different way:
+
+- `outline` (default) — the bottom border specifically uses `colorNeutralStrokeAccessible`, which is darker than the surrounding border tokens to meet the indicator-contrast requirement.
+- `filled-darker` and `filled-lighter` — these must be placed on a surface that provides at least 3:1 contrast against the textarea's background color, so the boundary of the textarea is still discernible.
+- `filled-darker-shadow` and `filled-lighter-shadow` — **deprecated**. Do not use in new code; they emit a console error in development.
+
+`Textarea` does not include an `underline` appearance like `Input` does, because the additional visual weight of an underline-only boundary is less useful at the larger sizes of a multi-line field.
+
+The bottom focus border (`::after`) uses `colorCompoundBrandStroke`, which is the brand color and is guaranteed to meet 3:1 against all supported page surfaces in the included themes.
+
+### Placing Textarea within an arrow-navigation region like Toolbar or Menu
+
+It is not recommended to place a textarea inside an arrow-navigable region like a `Toolbar`, `Menu`, or `Listbox`. The arrow keys, <kbd>Home</kbd>, <kbd>End</kbd>, and <kbd>Enter</kbd> are all already used within a textarea to move the caret and insert newlines, and these conflict with the keyboard contract of arrow-navigation containers. The conflict is stronger than for `Input`, because the textarea also consumes <kbd>Up</kbd> / <kbd>Down</kbd> arrows for vertical caret movement.
+
+Additionally, `<textarea>` is not a valid descendant of most arrow-navigation containers (`role=menu`, `role=tree`, `role=listbox`), and doing so violates the ARIA specification's parent/child requirements.
+
+If a multi-line input is genuinely needed inside one of these regions — for example, a chat composer that appears within a menu surface — use a Dialog/`role=dialog` or Popover container instead, and place the menu before or after the textarea in the dialog.
+
+## Semantics
+
+`Textarea` renders a wrapping `<span>` for styling and the actual `<textarea>` element for editing:
+
+| Slot     | Role             | States and properties                                                                                                                         |
+| -------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| root     | none             | A plain `<span>` with no role; used only for visual border and focus styling.                                                                 |
+| textarea | textbox (native) | `aria-invalid`, `aria-describedby`, `aria-labelledby`, `disabled`, `required`, `readonly`, `maxLength` as applied by `Field` or the consumer. |
+
+Focus lives on the `<textarea>` element. The visual focus state (the animated bottom border) is applied to the root via `:focus-within`, but the focused element from a screen reader and keyboard perspective is always the `<textarea>`.
+
+Native browsers expose `<textarea>` with the `textbox` role and announce it as a multi-line edit field — for example, NVDA announces "edit, multi-line". This is what tells screen reader users that <kbd>Enter</kbd> will insert a newline rather than commit the value.
+
+## Keyboard interaction
+
+`Textarea` is a single tab stop. All editing key behavior comes from the browser's native `<textarea>` implementation and matches platform conventions. Notable behaviors specific to multi-line text fields:
+
+- <kbd>Enter</kbd> inserts a newline. It does **not** submit a surrounding form (unlike single-line `<input>`).
+- <kbd>Up</kbd> and <kbd>Down</kbd> arrows move the caret between lines.
+- <kbd>Tab</kbd> moves focus out of the textarea (it does not insert a tab character). This is the standard HTML behavior
+  and is what allows keyboard users to escape the field.
+
+When `disabled` is set, the textarea is removed from the tab order entirely and is not interactable.
+
+The resize handle (when `resize` is not `'none'`) is not a separate tab stop, is not keyboard-operable, and is not exposed to assistive technologies as a focusable target. See [Resize](#resize) above.
+
+## Windows contrast themes (high contrast mode)
+
+`Textarea` relies almost entirely on the browser's native `<textarea>` behavior in Windows contrast themes. The native textarea adapts its background, text, caret, placeholder, and scrollbar colors to the user-selected theme without explicit overrides in the component's styles.
+
+The only explicit forced-colors rule on `Textarea` is for the disabled state: the border switches to `GrayText` so the disabled affordance matches the system disabled-control color. This is because the border style is on the parent root node and not on the `<textarea>` element itself, so it does not natively pick up the disabled state's color.
+
+The resize handle's appearance in forced colors is determined by the browser. Authors should not attempt to restyle the resize handle, as doing so can break its forced-colors behavior.
+
+## Motion and animation
+
+The bottom focus border has two animations — one for focus in and one for focus out — using `durationNormal` (focus in) and `durationUltraFast` (focus out) respectively. Both animations are shortened to `0.01ms` when [`prefers-reduced-motion: reduce`](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion) is set, effectively disabling the motion while preserving the final visual state. There is no other motion on `Textarea`.
+
+## Known issues
+
+- The browser-native resize handle is not keyboard-operable and is not exposed to assistive technologies. Authors using any `resize` value other than `'none'` should ensure the default field size is sufficient for users who cannot operate the handle. Consider exposing a separate keyboard-operable size toggle if larger sizes are critical to the user's task.
+- `maxLength` silently drops typed characters past the limit. Always pair `maxLength` with a visible character counter wired via `aria-describedby`, and ideally screen reader notifications using `useTypingAnnounce`.