diff --git a/instructions/a11y.instructions.md b/instructions/a11y.instructions.md
index f6a31750..78b3908e 100644
--- a/instructions/a11y.instructions.md
+++ b/instructions/a11y.instructions.md
@@ -52,7 +52,7 @@ In addition to producing accessible code, GitHub Copilot and similar tools must
   - The exception is when a static element, like a heading, is expected to receive keyboard focus programmatically (e.g., via `element.focus()`), in which case it should have a `tabindex="-1"` attribute.
 - Hidden elements must not be keyboard focusable.
 - Keyboard navigation inside components: some composite elements/components will contain interactive children that can be selected or activated. Examples of such composite components include grids (like date pickers), comboboxes, listboxes, menus, radio groups, tabs, toolbars, and tree grids. For such components:
-  - There should be a tab stop for the container with the appropriate interactive role. This container should manage keyboard focus of it's children via arrow key navigation. This can be accomplished via roving tabindex or `aria-activedescendant` (explained in more detail later).
+  - There should be a tab stop for the container with the appropriate interactive role. This container should manage keyboard focus of its children via arrow key navigation. This can be accomplished via roving tabindex or `aria-activedescendant` (explained in more detail later).
   - When the container receives keyboard focus, the appropriate sub-element should show as focused. This behavior depends on context. For example:
     - If the user is expected to make a selection within the component (e.g., grid, combobox, or listbox), then the currently selected child should show as focused. Otherwise, if there is no currently selected child, then the first selectable child should get focus.
     - Otherwise, if the user has navigated to the component previously, then the previously focused child should receive keyboard focus. Otherwise, the first interactive child should receive focus.
@@ -91,7 +91,7 @@ A skip link MUST be provided to skip blocks of content that appear across severa
 - `Tab` = Move to the next interactive element.
 - `Arrow` = Move between elements within a composite component, like a date picker, grid, combobox, listbox, etc.
 - `Enter` = Activate the currently focused control (button, link, etc.)
-- `Escape` = Close open open surfaces, such as dialogs, menus, listboxes, etc.
+- `Escape` = Close open surfaces, such as dialogs, menus, listboxes, etc.
 
 #### Managing focus within components using a roving tabindex
 
@@ -113,7 +113,7 @@ When using roving tabindex to manage focus in a composite component, the element
 
 - Prefer dark text on light backgrounds, or light text on dark backgrounds.
 - Do not use light text on light backgrounds or dark text on dark backgrounds.
-- The contrast of text against the background color must be at least 4.5:1. Large text, must be at least 3:1. All text must have sufficient contrast against it's background color.
+- The contrast of text against the background color must be at least 4.5:1. Large text, must be at least 3:1. All text must have sufficient contrast against its background color.
   - Large text is defined as 18.5px and bold, or 24px.
   - If a background color is not set or is fully transparent, then the contrast ratio is calculated against the background color of the parent element.
 - Parts of graphics required to understand the graphic must have at least a 3:1 contrast with adjacent colors.
@@ -194,7 +194,7 @@ First, determine if the graphic is informative or decorative.
 
 - All interactive elements must have a visual label. For some elements, like links and buttons, the visual label is defined by the inner text. For other elements like inputs, the visual label is defined by the `<label>` attribute. Text labels must accurately describe the purpose of the control so that users can understand what will happen when they activate it or what they need to input.
 - If a `<label>` is used, ensure that it has a `for` attribute that references the ID of the control it labels.
-- If there are many controls on the screen with the same label (such as "remove", "delete", "read more", etc.), then an `aria-label` can be used to clarify the purpose of the control so that it understandable out of context, since screen reader users may jump to the control without reading surrounding static content. E.g., "Remove what" or "read more about {what}".
+- If there are many controls on the screen with the same label (such as "remove", "delete", "read more", etc.), then an `aria-label` can be used to clarify the purpose of the control so that it is understandable out of context, since screen reader users may jump to the control without reading surrounding static content. E.g., "Remove what" or "read more about {what}".
 - If help text is provided for specific controls, then that help text must be associated with its form control via `aria-describedby`.
 
 ### Navigation and menus