From b74019a543b958c5da6a159ea8fdf3489027410c Mon Sep 17 00:00:00 2001 From: Pat Keenan <75324075+PatKeenan@users.noreply.github.com> Date: Tue, 17 Dec 2024 16:38:54 -0500 Subject: [PATCH] Remove Duplicate Words & Fix Spacing Issue (#6045) --- docs/accessibility/configuration/axe-core-configuration.mdx | 4 ++-- docs/accessibility/core-concepts/how-it-works.mdx | 2 +- docs/api/commands/window.mdx | 2 +- docs/api/node-events/overview.mdx | 2 +- docs/app/core-concepts/best-practices.mdx | 2 +- docs/app/references/changelog.mdx | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/accessibility/configuration/axe-core-configuration.mdx b/docs/accessibility/configuration/axe-core-configuration.mdx index b5f10646d3..45cddca7a9 100644 --- a/docs/accessibility/configuration/axe-core-configuration.mdx +++ b/docs/accessibility/configuration/axe-core-configuration.mdx @@ -8,7 +8,7 @@ sidebar_label: 'Axe Core® configuration' -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 diff --git a/docs/accessibility/core-concepts/how-it-works.mdx b/docs/accessibility/core-concepts/how-it-works.mdx index d24b2d2b07..637640ab96 100644 --- a/docs/accessibility/core-concepts/how-it-works.mdx +++ b/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. diff --git a/docs/api/commands/window.mdx b/docs/api/commands/window.mdx index e2a16100e9..6afc4bf2e8 100644 --- a/docs/api/commands/window.mdx +++ b/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. diff --git a/docs/api/node-events/overview.mdx b/docs/api/node-events/overview.mdx index 57fc7dde69..acd7b1e02a 100644 --- a/docs/api/node-events/overview.mdx +++ b/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 diff --git a/docs/app/core-concepts/best-practices.mdx b/docs/app/core-concepts/best-practices.mdx index d6dbedf45e..3f71324796 100644 --- a/docs/app/core-concepts/best-practices.mdx +++ b/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. ## Assigning Return Values diff --git a/docs/app/references/changelog.mdx b/docs/app/references/changelog.mdx index dc9b073235..15f35d2fad 100644 --- a/docs/app/references/changelog.mdx +++ b/docs/app/references/changelog.mdx @@ -1511,7 +1511,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,