Remove Duplicate Words & Fix Spacing Issue

docs/accessibility/configuration/axe-core-configuration.mdx

@@ -8,7 +8,7 @@ sidebar_label: 'Axe Core® configuration'
 
 <AccessibilityAddon />
 
-Configuration for Axe-Core® rules is available through your Account Executive. We we are happy to have a call with you to dial in your report config to make sure you are getting the most useful reports possible, and we find this onboarding very effective.
+Configuration for Axe-Core® rules is available through your Account Executive. We are happy to have a call with you to dial in your report config to make sure you are getting the most useful reports possible, and we find this onboarding very effective.
 
 In most cases, configuration of these rules as they run in Cypress Cloud isn't needed, because your implementation of any policies about what should "fail a build" is handled using the [Accessibility Results API](/accessibility/results-api), where you have full control over how to parse the results and what rules need to be reacted to. Keeping the results in Cypress Cloud broad helps you to still be able to see and understand all of the accessibility information, even if only a subset of the results would be considered blocking.
 
@@ -24,7 +24,7 @@ In most cases, configuration of these rules as they run in Cypress Cloud isn't n
 
 ## Component Testing
 
-Cypress Accessibility works great with component testing. In addition the the rules that are off by default, "page-level" rules do not run for component tests, since a component is usually a fragment mounted in an empty page that would not be expected to have things like headings or a `main` element.
+Cypress Accessibility works great with component testing. In addition the rules that are off by default, "page-level" rules do not run for component tests, since a component is usually a fragment mounted in an empty page that would not be expected to have things like headings or a `main` element.
 
 ## Updates to the Axe Core® library
 

docs/accessibility/core-concepts/how-it-works.mdx

@@ -11,7 +11,7 @@ The stages of the Cypress Accessibility process are as follows:
 
 1. As your run is recorded and specs are uploaded to Cypress Cloud, accessibility checks begin, based on the incoming [Test Replay](/cloud/features/test-replay) data, on the Cypress Cloud servers.
 1. When your run completes, the final specs are processed for accessibility checks. All earlier specs have already entered processing and are likely completed by the end of the run.
-1. Cypress Cloud organizes all the the Views (pages and components) that were rendered during the run, merging and deduplicating across tests so that page-level results and live DOM snapshots can be grouped together.
+1. Cypress Cloud organizes all the Views (pages and components) that were rendered during the run, merging and deduplicating across tests so that page-level results and live DOM snapshots can be grouped together.
 1. A combined "rule-level" report is created.
 1. The completed results are displayed in Cypress Cloud and are flagged in integrations such Slack as GitHub/Gitlab comments, and available CI via the Results API so that you can optionally fail your pipeline if your standards are not met.
 

docs/api/commands/window.mdx

@@ -174,7 +174,7 @@ It fails. But the interesting thing is that the type of `event` is
 `KeyboardEvent` when you `console.log(event)`.
 
 It's because Cypress uses an `iframe` to load the application under test. In
-other words, the `KeyboardEvent` used in the the code above and the
+other words, the `KeyboardEvent` used in the code above and the
 `KeyboardEvent` class from which the `event` variable is constructed are
 different `KeyboardEvent`s.
 

docs/api/node-events/overview.mdx

@@ -234,7 +234,7 @@ Cypress does this by spawning an independent `child_process` which then
 `requires` the [Cypress configuration file](/app/references/configuration).
 This is similar to the way Visual Studio Code or Atom works.
 
-This code will be executed using the the Node version that launched Cypress.
+This code will be executed using the Node version that launched Cypress.
 
 ### npm modules
 

docs/app/core-concepts/best-practices.mdx

@@ -236,7 +236,7 @@ recommend you approach testing your components, look to: [Cypress Component Test
 
 Selecting elements with data attributes, text content, or Testing Library locators can each have some different implications for accessibility,
 but none of these approaches is a "complete" accessibility test, and you will always need additional, accessibility-specific testing (including automated and manual tests) to confirm
-your application is working as expected for people with disabilities and the technology they use. See[our accessibility testing guide](/app/guides/accessibility-testing) for more details and comparisons of approaches.
+your application is working as expected for people with disabilities and the technology they use. See [our accessibility testing guide](/app/guides/accessibility-testing) for more details and comparisons of approaches.
 
 ## <Icon name="angle-right" /> Assigning Return Values
 

docs/app/references/changelog.mdx

@@ -1489,7 +1489,7 @@ _Released 1/03/2023_
 
 - Added support for mapping the `CYPRESS_PULL_REQUEST_ID`,
   `CYPRESS_PULL_REQUEST_URL`, and/or `CYPRESS_CI_BUILD_URL` environment
-  variables to the the corresponding Cloud run. This provides workarounds when
+  variables to the corresponding Cloud run. This provides workarounds when
   supported CI provider mappings are incorrect or unsupported CI providers are
   used. Addressed in [#25036](https://github.com/cypress-io/cypress/pull/25036).
 - Added new Cypress API,