microsoft · deining · Nov 19, 2025
@@ -45,7 +45,7 @@ For each component tested, write out any specific notes per-step here. Use this
   - Be extra careful to verify the focus indicator both against the base state, and against other states like selected or pressed
   - If the control can contain focusable children like buttons or links, make sure to test those children's focus indicators as well. This is mostly relevant if the control has a different background color than the default page background (including in other states, like selected/pressed/etc).
 - [ ] Compare state vs. rest state: in addition to text/graphics needing contrast within each state, some states also need contrast against each other.
-  - Where this applies: focus (alread covered), and also states with meaning: selection, on/off states, checked, error, etc. Hover and mousedown/CSS ":pressed" do not count here.
+  - Where this applies: focus (already covered), and also states with meaning: selection, on/off states, checked, error, etc. Hover and mousedown/CSS ":pressed" do not count here.
   - Check states against the rest state, and also each other. For example, if the only visual indication of selection is a background color change, that color change must be at least 3:1 against the rest state, and also against the focus state, error state, etc.
   - If there are multiple indications of a state (e.g. a slight background color change + a check mark), only one needs to meet 3:1 contrast.
 
@@ -93,7 +93,7 @@ For each component tested, write out any specific notes per-step here. Use this
 ### Steps
 
 1. Open a window with only the control (e.g. no Storybook panels or UI)
-2. Use some combination of window resizing and zoom to set the brower viewport to 320px by 256px
+2. Use some combination of window resizing and zoom to set the browser viewport to 320px by 256px
 3. Find all permutations of state, props, and children that affect layout (e.g. opening a combobox, or expanding multiple levels of dropdown menus), and check that the control is visually and functionally coherent.
 4. If the control accepts any freeform text content (via children, slots, or props), create a test case that inserts and absurdly long text string in all possible places, and then do steps 1-3.
 

@@ -98,7 +98,7 @@ Each sample number entry links to a flamegraph, which looks like the following:
 
 <a target="_blank" href="https://user-images.githubusercontent.com/26070760/60136445-07304c00-9759-11e9-882a-33d73575dc15.png"><img src="https://user-images.githubusercontent.com/26070760/60136445-07304c00-9759-11e9-882a-33d73575dc15.png" width="1385"/></a>
 
-## Perf Test Results Intepretation
+## Perf Test Results Interpretation
 
 Since this PR improves perf for new Button components, we expect to see improvements in corresponding components:
 

@@ -70,7 +70,7 @@ export const Input: ForwardRefComponent<InputProps> = React.forwardRef((props, r
 👎 Cons:
 
 - Creating new composed component for each input `Dropdown`, `Input`, `TextArea` and `DatePicker`
-- Composed component apperance prop wouldn't match our Fluent V9 documentation
+- Composed component appearance prop wouldn't match our Fluent V9 documentation
 - Does not work if repos have dependencies of another project with Fluent V9 input components (Nova)
 - Composition approach is currently marked as unstable in v9
 
@@ -94,7 +94,7 @@ export const Input: ForwardRefComponent<InputProps> = React.forwardRef((props, r
 
 - Creating new composed component for each input `Dropdown`, `Input`, `TextArea` and `DatePicker`
 - Wrapper components in React's i.e. bigger React tree
-- Wrapper component apperance wouldn't match our Fluent V9 documentation
+- Wrapper component appearance wouldn't match our Fluent V9 documentation
 - Would work in iframes only within the TMP repository
 - Does not work if repos have dependencies of another project with Fluent V9 input components (Nova)
 

@@ -120,7 +120,7 @@ influences what happens during release.
 ### Pros
 
 - Changelogs are an extra resource for partners during upgrades
-- Easy to see what changed between versions during uprgades
+- Easy to see what changed between versions during upgrades
 - Keep implementation details out of public changelog
 
 ### Cons

@@ -26,7 +26,7 @@ makeStyles({
 
 ## Export tokens separately
 
-Initially we planed to support IE11 via runtime tricks, but with the deprecation of IE11, we are now able to leverage CSS Variables for tokens and theming purposes. We communicate this fact to customers so that they understand clearly what they are using.
+Initially we planned to support IE11 via runtime tricks, but with the deprecation of IE11, we are now able to leverage CSS Variables for tokens and theming purposes. We communicate this fact to customers so that they understand clearly what they are using.
 
 The proposal is to export `tokens` as a plain object:
 
@@ -122,7 +122,7 @@ In both scenarios above, `FluentProvider` will still inject all customer tokens
 
 Also, in case there is an ask for it, we can decide to export a primitive component in the future (named for example `TokensProvider`) whose only purpose would be to render variables for `Record<string, string | number>`.
 
-Finally, we will export a function to make the tokens to css variable mapping for any custom theme be programatically generated.
+Finally, we will export a function to make the tokens to css variable mapping for any custom theme be programmatically generated.
 
 ## Using custom tokens in `makeStyles()`
 

@@ -10,7 +10,7 @@ The purpose of this RFC is to find a solution to avoid unnecessary GitHub checks
 
 ## Problem statement
 
-Whenever someone creates a PR, independently of the content, the CI is triggered and added as a check for a successfull PR. This, along with Screener and CodeSandbox, is consuming unnecessary resources on our pipeline for, essentially, no reason.
+Whenever someone creates a PR, independently of the content, the CI is triggered and added as a check for a successful PR. This, along with Screener and CodeSandbox, is consuming unnecessary resources on our pipeline for, essentially, no reason.
 
 Apart from this, other PRs that actually need CI checks, will be delayed due to the lack of parallelism in our pipeline.
 By avoiding these checks, we can prevent a wasteful CI pipeline and accelerate work in PRs that bring value to our users.

@@ -34,7 +34,7 @@ The surrounding context of an app or website is also likely to influence user ex
 
 The content of options also influences user expectations -- there would be a greater expectation of space-to-type when options contain a space in them, for example multi-word options, names, states or cities.
 
-One of the risks is that the developers and designers may not be in a position to make a correct decision on the value of the prop. This is because options are usually either translations or user data, which may contain spaces that the authoring team was not aware of. We generally can't expect authors to understand all possible translations across supported languages or the specific validations of the user data at UI authoring time. While the occaisonal space character does not necessarily mean that space should not select, translations and user data do introduce the possibility of frequent spaces within multiple options.
+One of the risks is that the developers and designers may not be in a position to make a correct decision on the value of the prop. This is because options are usually either translations or user data, which may contain spaces that the authoring team was not aware of. We generally can't expect authors to understand all possible translations across supported languages or the specific validations of the user data at UI authoring time. While the occasional space character does not necessarily mean that space should not select, translations and user data do introduce the possibility of frequent spaces within multiple options.
 
 ## Problem statement
 

@@ -51,7 +51,7 @@ Nested focusable items should also be able to use list/grid focus behaviors.
 
 ### Restoring lost focus
 
-Often clicking on a widget (e.g button) can toggle an option and cause it to disappear. Without any intervention the focus will be lost and applied directly to the document body, which is undesireable for screen reader users.
+Often clicking on a widget (e.g button) can toggle an option and cause it to disappear. Without any intervention the focus will be lost and applied directly to the document body, which is undesirable for screen reader users.
 
 We should provide customers the ability to easily detect or avoid these situations by restoring focus to meaningful default elements.
 
@@ -95,7 +95,7 @@ Internally, `Tabster` leverages the [TreeWalker API](https://developer.mozilla.o
 `Tabster` has 2 levels of API:
 
 - Declarative with `data-tabster` DOM attribute
-- Functional that can accept DOM elemenets or functions
+- Functional that can accept DOM elements or functions
 
 Nesting focusables is a problem that `Tabster` explicitly tries to solve. It does this by bringing focus management to a lower level than the rendering framework, trying to accomplish this consistently without worrying about rendering cycles.
 
@@ -125,7 +125,7 @@ The bundle size of each of the different modules of the library are listed in th
 `Tabster's` Core API provides the following functionalities:
 
 - Groupper - handling groups of focusable elements.
-- Mover - hanling moving between (groups of) focusable elements.
+- Mover - handling moving between (groups of) focusable elements.
 - Focusable - utilities to find and verify focusable elements.
 - Focused element state - observes the currently focused element.
 - Keyboard navigation state - observes if the user is navigating with keyboard.
@@ -255,7 +255,7 @@ Below, we present a comparison between the functionality available in `FocusZone
 ##### IFocusZoneProps
 
 - `defaultTabbableElement?: string | ((root: HTMLElement) => HTMLElement)`
-  - _Description:_ Optionally defines the initial tabbable element inside the `FocusZone`. If a string is passed then it is treated as a selector for identifying the inital tabbable element. If a function is passed then it uses the root element as a parameter to return the initial tabbable element.
+  - _Description:_ Optionally defines the initial tabbable element inside the `FocusZone`. If a string is passed then it is treated as a selector for identifying the initial tabbable element. If a function is passed then it uses the root element as a parameter to return the initial tabbable element.
   - _What should we do about this prop?_ Is there an actual need for something like this? If so, we should probably find a solution in `@fluentui/react-tabster`. If not, we should skip this prop and regard it as "not needed". Anyways, it is too early right now to make a call on it and the actual API would probably have to look very different to what it looks like in `FocusZone` today.
 - `shouldResetActiveElementWhenTabFromZone?: boolean`
   - _Description:_ If true and the `Tab` key is not handled by `FocusZone`, resets current active element to null value. For example, when roving index is not desirable and focus should always reset to the default tabbable element.
@@ -275,6 +275,6 @@ Below, we present a comparison between the functionality available in `FocusZone
 - `shouldRaiseClicks?: boolean`
   - _Description:_ Determines whether the `FocusZone` will walk up the DOM trying to invoke click callbacks on focusable elements on Enter and Space keydowns to ensure accessibility for tags that do not guarantee this behavior.
 - `shouldInputLoseFocusOnArrowKey?: (inputElement: HTMLInputElement) => boolean`
-  - _Description:_ A callback method to determine if the input element should lose focus on arrow keys. Receives the input element which is to lose focus as a paramenter and returns true if the input element should lose focus and false otherwise.
+  - _Description:_ A callback method to determine if the input element should lose focus on arrow keys. Receives the input element which is to lose focus as a parameter and returns true if the input element should lose focus and false otherwise.
 - `stopFocusPropagation?: boolean`
   - _Description:_ Whether the `FocusZone` should allow focus events to propagate past the `FocusZone`.
@@ -454,7 +454,7 @@ And it seems to be a problem? 🤔 Well, it _seems_ that tearing is by design he
 
 > Example: https://stackblitz.com/edit/vitejs-vite-3gsvqu
 >
-> Example also contains additional scenarios for `useTranstion()` and `useDeferredValue()` hooks. The goal is to check if tearing is an issue with these hooks.
+> Example also contains additional scenarios for `useTransition()` and `useDeferredValue()` hooks. The goal is to check if tearing is an issue with these hooks.
 >
 > **Note**: POC is based on `useSyncExternalStore()` shim, but `useSyncExternalStore()` could be also used directly.
 

@@ -34,7 +34,7 @@ Many new engineers can find it hard to adapt to a new codebase, especially when
 <!--
 Why are we making this change? What problem are we solving? What do we expect to gain from this?
 
-This section is important as the motivation or problem statement is indepenent from the proposed change. Even if this RFC is not accepted this Motivation can be used for alternative solutions.
+This section is important as the motivation or problem statement is independent from the proposed change. Even if this RFC is not accepted this Motivation can be used for alternative solutions.
 
 In the end, please make sure to present a neutral Problem statement, rather than one that motivates a particular solution
 -->
@@ -43,7 +43,7 @@ Many new developers might have questions on the patterns that we follow to write
 
 ## Detailed Design or Proposal
 
-<!-- This is the bulk of the RFC. Explain the proposal or design in enough detail for the inteded audience to understand. -->
+<!-- This is the bulk of the RFC. Explain the proposal or design in enough detail for the intended audience to understand. -->
 
 ### Hook based architecture
 

@@ -107,7 +107,7 @@ const Example = (props: ButtonProps) => {
 ### Global CSS override in apps
 
 We recommend users to use the [prefers-reduced-motion](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion),
-since that gives cross platform support without addtional performance costs
+since that gives cross platform support without additional performance costs
 of specific selectors or JavaScript runtime. Additionally, _**not all animations need to be disabled**_, and limited
 animations like colour change are still acceptable for users that need reduced motion.
 

@@ -16,7 +16,7 @@ Field requires integration between its parts to ensure that the label, error mes
 
 ## Detailed Design or Proposal
 
-Implement a single `<Field>` component, which does the layout for field, including slots for `label`, `validationMesssage`, and `hint`.
+Implement a single `<Field>` component, which does the layout for field, including slots for `label`, `validationMessage`, and `hint`.
 
 The control is the child, and Field adds the following props to the child using cloneElement (or a render function):
 

@@ -10,7 +10,7 @@ This RFC proposes that all Fluent UI contexts be registered in the global scope
 ## Problem statement
 
 Many of our partners have complex dependency trees. The complexity in dependency management means that duplicate
-packages can exist in `node_modules` folders. Although duplicate depedencies should generally be avoided, this still
+packages can exist in `node_modules` folders. Although duplicate dependencies should generally be avoided, this still
 happens quite often due to these factors:
 
 - Propagating dependency bumps downstream can be slow

@@ -57,7 +57,7 @@ A list of support for `key` [can be found in MDN](https://developer.mozilla.org/
 
 ### Compatibility with e.keyCode
 
-In order to comfortably use both `key` and `keyCode` during a transition phase and also in the future if we ever find out one might be preferrable to another, we should implement the new package to be compatible with both. This can be done with a `key` and `keycode` naming convention.
+In order to comfortably use both `key` and `keyCode` during a transition phase and also in the future if we ever find out one might be preferable to another, we should implement the new package to be compatible with both. This can be done with a `key` and `keycode` naming convention.
 
 ```typescript
 import { ArrowDownKey, ArrowDownKeyCode } from '@fluentui/react-keyboard-key';

@@ -76,13 +76,13 @@ Current HC FUI theme uses the following five colors - `white`, `black`, `hyperli
 The implementation of the hard coded high contrast theme in Fluent UI, is mainly driven by designers. The existence
 of this theme (rather than allowing OS to handle all high contrast theming) is driven by the fact that not all
 platforms can be controlled by the operating system. For example, the Electron browser does not recognize input
-from the operating system about `forced-colors`. MacOS uses its own propietary color inverting as a means of support
+from the operating system about `forced-colors`. MacOS uses its own proprietary color inverting as a means of support
 for high contrast which does not follow Windows. In these scenarios it would be appropriate to use the hard coded
 high contrast theme to either add high contrast support where there is none, or ensure some level of consistency
 with the Windows operating system.
 
 While there are benefits of providing a theme that provides more contrast than others, it is not necessary. The reasons
-for this theme are the result of technical contraints for certain platforms and a certain amount of legacy.
+for this theme are the result of technical constraints for certain platforms and a certain amount of legacy.
 Users should be warned that for the highest class of accessibility support, apps need to fully support windows high
 contrast mode. This theme does not contribute to that goal.
 

@@ -1088,7 +1088,7 @@ function App() {
   const [visible, setVisible] = useState(false);
   const motion = useMotion(visible);
 
-  const className = mergeClasses(classes.root, classes[motion.state] /* simplied example */);
+  const className = mergeClasses(classes.root, classes[motion.state] /* simplified example */);
 
   return (
     <>

@@ -110,7 +110,7 @@ Examples include:
 - Input components like `Input`, `Checkbox`, `Dropdown`, etc. These wrap the actual `<input>` or `<select>` element with styling/layout elements, but the `<input>` or `<select>` should be the primary slot.
 - Example from v8 (may look different in converged): Modal's actual React root element is usually a Layer, but from a user standpoint it makes a lot more sense to apply top-level props to the modal _content's_ root element.
 
-### Propsed Implementation
+### Proposed Implementation
 
 #### Typings