cypress-io · AtofStryker · May 8, 2025 · Apr 8, 2025 · Apr 8, 2025 · Apr 8, 2025
diff --git a/docs/accessibility/changelog.mdx b/docs/accessibility/changelog.mdx
@@ -24,7 +24,7 @@ sidebar_position: 200
 
 ## Week of 2/24/2025
 
-- [Cypress Accessibility Branch Review](/accessibility/core-concepts/comparing-reports) has entered beta. Read the docs to learn how to compare runs and automatically spot newly introduced issues.
+- [Cypress Accessibility Branch Review](/accessibility/core-concepts/compare-reports) has entered beta. Read the docs to learn how to compare runs and automatically spot newly introduced issues.
 
 ## Week of 1/13/2025
 

diff --git a/...ility/core-concepts/comparing-reports.mdx → ...ibility/core-concepts/compare-reports.mdx b/...ility/core-concepts/comparing-reports.mdx → ...ibility/core-concepts/compare-reports.mdx
@@ -29,7 +29,7 @@ Comparing the results from different runs is useful in multiple scenarios.
 - **Detecting content issues**: Sometimes content editors can introduce accessibility issues unrelated to code changes. Seeing the example issues presented visually, in context, helps you quickly triage whether you are dealing with a recent code change issue, or a content authorship problem.
 - **Reviewing AI-generated code changes**: The increased use of AI to generate and/or review front-end code creates some increased risks of accessibility regressions making it to production. The increase or decrease of accessibility issues when reviewing a pull request helps you understand the impact of the change.
 - **Tracing the introduction of issues**: With dropdowns for each run, it's easy to rapidly compare different A and B runs to find the exact commit that introduced a problem.
-- **Demonstrating the resolution of issues**: Confirm the effect of your improvements, and share overview with your team to more quickly review code changes.
+- **Demonstrating the resolution of issues**: Confirm the effect of your improvements, and share the overview with your team to more quickly review code changes.
 
 ## Content of the report
 
@@ -49,47 +49,8 @@ This organization of the report brings the most significant results to the top -
 
 ## How to compare runs
 
-The first step is to get to the Branch Review area of Cypress Cloud, which will let you compare one branch against another - or different runs on the same branch, if needed. We refer to be baseline fun for comparison as the `base` run, and the changes we are comparing with as the `changed` run.
-
-There are a number of ways to get to Branch Review depending on where you are looking at your Cypress results. In all cases, once you've picked a `changed` run, you can adjust the automatically-selected `base` run to any branch or run in the project.
-
-### From a Pull Request
-
-<DocsImage
-  src="/img/accessibility/core-concepts/branch-review-pull-request.png"
-  alt="A pull request comment from Cypress with an arrow pointing to the 'View all changes introduced in this branch' link. Test results and some accessibility score and violation information is also visible in the comment. The project has an 86.86% accessibility score, with  9 failed elements. Failed rule counts are 1 critical, 1 serious, 3 moderate, and 0 minor."
-/>
-
-Click the "View all changes introduced in this branch" link at the bottom of the Test Results table. You will enter branch review with the current PR's branch and latest run pre-selected as the "changed" run.
-
-### From the run list
-
-Click the branch name associated with the run. This will take you to Branch Review with that branch's newest run pre-selected as the `changed` run.
-
-<DocsImage
-  src="/img/accessibility/core-concepts/branch-review-run-card.png"
-  alt="A couple of cards showing various details about Cypress test runs, including pass/fail counts and metadata. An arrow points to the branch name."
-/>
-
-### From the project list
-
-<DocsImage
-  src="/img/accessibility/core-concepts/branch-review-project-card.png"
-  width="40%"
-  alt="A card showing the name of an example project and related branches to choose."
-/>
-
-The project card shows three active branches for the project. You can click through to any of these to enter Branch Review with the newest run on that branch pre-selected as the `changed` run.
-
-### From the main navigation
-
-<DocsImage
-  src="/img/accessibility/core-concepts/branch-review-side-nav.png"
-  width="40%"
-  alt="The main Cypress Cloud navigation showing Latest Runs, Branches, and Analytics menu items. An arrow points to Branches."
-/>
-
-When inside of a project, you can select "Branches" in the main navigation to see a full, filterable list of available branches and choose one to set as the `changed` run.
+The first step is to get to the [Branch Review](/cloud/features/branch-review.mdx) area of Cypress Cloud, which will let you compare one branch against another - or different runs on the same branch, if needed.
+You can access this area by clicking the branch name associated with a run, or in several other ways. [Learn more about how to compare runs](/cloud/features/branch-review.mdx).
 
 ## FAQ
 
@@ -99,9 +60,11 @@ The best subjects to compare are passing runs that ran similar tests on the same
 
 That said, it still possible and valid to compare runs from different points in time with different sets of test results, as long as you bear in mind all the potential sources of difference between the two runs, which you can evaluate for yourself as you explore the results.
 
+In order to see unified changes for your entire test suite, you need to group all the tests together under a single Cypress run, for each report. Learn more about this in the [Branch Review Best Practices documentation](/cloud/features/branch-review#Best-Practices).
+
 ### What is the purpose of the Beta label?
 
-This indicates the feature is ready for use and actively seeking feedback based on real usage of the current implementation. We have a few known issues to work through on our side before we consider this fully production-ready and remove the beta label. These issues only affect a subset of projects -- in most cases everything is working as intended. If you see anything unexpected, please hit the feedback button and let us know.
+This indicates the feature is ready for use and actively seeking feedback based on real usage of the current implementation. We have a few known issues to work through on our side before we consider this fully production-ready and remove the beta label. These issues only affect a subset of projects -- in most cases everything is working as intended. If you see anything unexpected, please use the feedback button and let us know.
 
 ### Why do I see some views (pages or components) changing from run-to-run?
 

diff --git a/docs/accessibility/core-concepts/how-it-works.mdx b/docs/accessibility/core-concepts/how-it-works.mdx
@@ -15,7 +15,7 @@ Cypress Accessibility seamlessly integrates accessibility testing into your deve
 1. **Processing**: When your run completes, the final specs are processed for accessibility checks. Earlier specs have already entered processing and are likely completed by the end of the run.
 1. **Organizing Views**: Cypress Cloud groups Views (pages and components) rendered during the run, merging and deduplicating across tests. This ensures page-level results and live DOM snapshots are organized effectively.
 1. **Generating reports**: A combined "rule-level" report is created, summarizing all detected accessibility violations.
-1. **Displaying results**: Results are displayed in Cypress Cloud in the run details area as well as in [Branch Review](/accessibility/core-concepts/comparing-reports) for comparing runs. Accessibility is also flagged in integrations (e.g., Slack, GitHub/GitLab comments), and accessible via the [Results API](/accessibility/results-api) for optional CI pipeline actions (e.g., failing builds based on unmet standards).
+1. **Displaying results**: Results are displayed in Cypress Cloud in the run details area as well as in [Branch Review](/accessibility/core-concepts/compare-reports) for comparing runs. Accessibility is also flagged in integrations (e.g., Slack, GitHub/GitLab comments), and accessible via the [Results API](/accessibility/results-api) for optional CI pipeline actions (e.g., failing builds based on unmet standards).
 
 ## About Axe Core®
 

diff --git a/docs/accessibility/get-started/introduction.mdx b/docs/accessibility/get-started/introduction.mdx
@@ -27,7 +27,7 @@ Cypress Accessibility adds detailed accessibility checks and workflows in Cypres
   label="See a demo"
   icon="action-play-small"
   className="!mb-2 mr-1"
-  href="https://www.loom.com/share/eedb1d18c22942d39a5ed2471ae72788?sid=e39f791e-c0b3-4efc-9770-cbfac403c3b9"
+  href="https://on.cypress.io/accessibility-demo-video"
 />
 <Btn
   label=" Explore an example project"
@@ -75,7 +75,7 @@ From there, you can integrate with CI to set your own standards for handling the
       href="/accessibility/guides/detect-changes"
       aria-labelledby="card-title-8"
     >
-      <Icon name="chart-line" />
+      <Icon name="shield-halved" />
       <h3 id="card-title-8">Detect and manage changes</h3>
       <p>
         Compare reports in detail to review only _new_ accessibility issues, use

diff --git a/docs/accessibility/guides/detect-changes.mdx b/docs/accessibility/guides/detect-changes.mdx
@@ -11,7 +11,7 @@ sidebar_position: 70
 
 Cypress Accessibility supports three main paths to observing and acting on changes in the accessibility report for your projects:
 
-- Run comparisons with [Branch Review](/accessibility/core-concepts/comparing-reports)
+- Run comparisons with [Branch Review](/accessibility/core-concepts/compare-reports)
 - The [Results API](/accessibility/results-api) to fail builds or trigger alerts when results don't meet your standards
 - [Analytics](/cloud/features/analytics/enterprise-reporting#Cypress-Accessibility) for high-level trend-spotting and analysis
 
@@ -33,7 +33,7 @@ Use Branch review when reviewing a pull request made by another developer or bef
 
 Since this reduces the amount of violations to review to just what was affected by the PR code changes, you won't spend any time looking for what's relevant -- and if there is no difference, you'll know your PR does not affect the accessibility score and is safe to merge.
 
-See the main [Accessibility Branch Review docs](/accessibility/core-concepts/comparing-reports) for a video demo of this workflow.
+See the main [Accessibility Branch Review docs](/accessibility/core-concepts/compare-reports) for a video demo of this workflow.
 
 #### Compare reports during local development (without waiting for CI)
 

diff --git a/docs/accessibility/results-api.mdx b/docs/accessibility/results-api.mdx
@@ -322,7 +322,7 @@ run-cypress:
 pipeline {
   agent {
     docker {
-      image 'cypress/base:22.12.0'
+      image 'cypress/base:22.15.0'
     }
   }
 
@@ -393,7 +393,7 @@ version: 2.1
 jobs:
   linux-test:
     docker:
-      - image: cypress/base:22.12.0
+      - image: cypress/base:22.15.0
 
     working_directory: ~/repo
     steps:

diff --git a/docs/api/commands/focus.mdx b/docs/api/commands/focus.mdx
@@ -159,4 +159,5 @@ the following:
 - [`.blur()`](/api/commands/blur)
 - [`.click()`](/api/commands/click)
 - [`cy.focused()`](/api/commands/focused)
+- [`cy.press()`](/api/commands/press)
 - [`.type()`](/api/commands/type)
diff --git a/docs/api/commands/origin.mdx b/docs/api/commands/origin.mdx
@@ -40,9 +40,11 @@ doc.
 
 Cypress no longer injects `document.domain` by default, which means `cy.origin()`
 must now be used to navigate between any two origins in the same test, even if
-the two origins are in the same superdomain. This behavior can be disabled by setting
-the `injectDocumentDomain` configuration option to `true`, to allow a smooth transition
-of tests to the new behavior. This configuration option will be removed in a future version of Cypress.
+the two origins are in the same superdomain.
+This behavior can be disabled by setting the
+[injectDocumentDomain](/app/references/configuration#injectDocumentDomain) configuration option to `true`,
+to allow a smooth transition of tests to the new behavior.
+This configuration option will be removed in a future version of Cypress.
 
 :::
 
@@ -191,7 +193,7 @@ will not work:
 cy.origin('https://example.cypress.io', () => {
   cy.visit('/')
   cy.get('h1') // Yields an element, which can't be serialized...
-}).contains('CYPRESS') // ...so this will fail
+}).contains('Kitchen Sink') // ...so this will fail
 ```
 
 Instead, you must explicitly yield a serializable value:
@@ -201,8 +203,8 @@ Instead, you must explicitly yield a serializable value:
 ```js
 cy.origin('https://example.cypress.io', () => {
   cy.visit('/')
-  cy.get('h1').invoke('textContent') // Yields a string...
-}).should('equal', 'CYPRESS') // 👍
+  cy.get('h1').invoke('text') // Yields a string...
+}).should('equal', 'Kitchen Sink') // 👍
 ```
 
 ### Navigating to secondary origin with cy.visit
@@ -367,6 +369,9 @@ Cypress.Commands.add('login', (username, password) => {
 In this video we walk through how to test multiple origins in a single test. We
 also look at how to use the `cy.session()` command to cache session information
 and reuse it across tests.
+The configuration option `experimentalSessionAndOrigin`, mentioned in the video, is not used
+since [Cypress 12.0.0](https://docs.cypress.io/app/references/changelog#12-0-0)
+and the associated functionality is enabled by default.
 
 ## Notes
 

diff --git a/docs/api/commands/press.mdx b/docs/api/commands/press.mdx
@@ -0,0 +1,134 @@
+---
+title: 'cy.press() | Cypress Documentation'
+description: Trigger native key events in your application to simulate keyboard interactions.
+sidebar_label: press
+slug: /api/commands/press
+componentSpecific: false
+---
+
+<ProductHeading product="app" />
+
+# press
+
+Trigger native key events in your application to simulate keyboard interactions.
+
+A `keydown`, `press`, and `keyup` event will be dispatched directly to the browser window.
+
+Unlike `cy.type()`, which is best for typing character keys, `cy.press()` will dispatch real keyboard events rather than simulated ones. This command is especially useful when testing focus management and keyboard navigation patterns which are critical for [accessibility testing](/app/guides/accessibility-testing) and great keyboard UX.
+
+Currently, the only key supported is `Tab`.
+
+:::caution
+
+<strong>Supported Browsers:</strong>
+This command is supported in chromium browsers and Firefox versions >= v135. WebKit
+is not supported. This command will fail if executed in a browser that does not support
+it.
+
+:::
+
+## Syntax
+
+```javascript
+cy.press(key)
+cy.press(key, options)
+```
+
+## Signature
+
+```typescript
+interface PressCommand {
+  (
+    key: KeyPressSupportedKeys,
+    options?: Partial<Cypress.Loggable> & Partial<Cypress.Timeoutable>
+  ): void
+}
+```
+
+## Usage
+
+<Icon name="check-circle" color="green" /> **Correct Usage**
+
+```javascript
+cy.get('input.first').focus()
+cy.press(Cypress.Keyboard.Keys.TAB)
+cy.get('input.second').should('have.focus')
+```
+
+<Icon name="exclamation-triangle" color="red" /> **Incorrect Usage**
+
+```javascript
+cy.get('input.first').focus()
+cy.press(Cypress.Keyboard.Keys.TAB)
+  // Errors because press yields null
+  .should('have.focus')
+```
+
+### Arguments
+
+<Icon name="angle-right" /> **key _(String)_**
+
+The key to press. The supported values are available on [`Cypress.Keyboard.Keys`](/api/cypress-api/keyboard-api), and may change from time to time. It's recomended that you reference these values from `Cypress.Keyboard.Keys` rather than passing in a string.
+
+### Supported Keys
+
+| Reference                   | Value   |
+| --------------------------- | ------- |
+| `Cypress.Keyboard.Keys.TAB` | `"Tab"` |
+
+<Icon name="angle-right" /> **options _(Object)_**
+
+Pass in an options object to change the default behavior of `.press()`.
+
+| Option    | Default                                                           | Description                                                                         |
+| --------- | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
+| `log`     | `true`                                                            | Displays the command in the [Command log](/app/core-concepts/open-mode#Command-Log) |
+| `timeout` | [`defaultCommandTimeout`](/app/references/configuration#Timeouts) | Time to wait for `cy.press()` to resolve before timing out                          |
+
+<HeaderYields />
+
+- `cy.press()` yields `null`.
+
+## Examples
+
+### Test focus order of tab
+
+```js
+it('moves focus to the next form element when pressing Tab', () => {
+  cy.visit('/my-login')
+  cy.get('input.email').type('username')
+  cy.press(Cypress.Keyboard.Keys.TAB)
+  cy.get('input.password').should('have.focus')
+})
+```
+
+### Test autocomplete of search input with tab
+
+```js
+it('autocompletes search input when pressing Tab', () => {
+  cy.get('[data-cy="search"]').type('cy')
+  cy.press(Cypress.Keyboard.Keys.TAB)
+  cy.get('[data-cy="search"]').should('have.value', 'cypress')
+})
+```
+
+## Notes
+
+### Transient activation
+
+By dispatching native keyboard events to the browser, this command will cause the browser to enter [Transient activation](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation) state.
+
+If your application prevents the default behavior of the `beforeunload` event, this may cause issues when navigating away from the current page.
+
+## History
+
+| Version                             | Changes                      |
+| ----------------------------------- | ---------------------------- |
+| [14.3.0](/app/references/changelog) | Added the `.press()` command |
+
+## See also
+
+- [`Cypress.Keyboard`](/api/cypress-api/keyboard-api)
+- [`.focus()`](/api/commands/focus)
+- [`.focused()`](/api/commands/focused)
+- [`.type()`](/api/commands/type)
diff --git a/docs/api/commands/shadow.mdx b/docs/api/commands/shadow.mdx
@@ -96,13 +96,10 @@ When working with `cy.click()`, it sometimes won't click the right element in
 Chrome. It's happening because of
 [the ambiguity in spec](https://bugs.chromium.org/p/chromium/issues/detail?id=1188919&q=shadowRoot%20elementFromPoint&can=2).
 
-In this case, pass `{ position: 'top' }` to `cy.click()` like below:
+In this case, pass `'top'` to `cy.click()` like below:
 
 ```js
-cy.get('#element')
-  .shadow()
-  .find('[data-test-id="my-button"]')
-  .click({ position: 'top' })
+cy.get('#element').shadow().find('[data-test-id="my-button"]').click('top')
 ```
 
 ## Command Log

diff --git a/docs/api/commands/type.mdx b/docs/api/commands/type.mdx
@@ -664,5 +664,6 @@ following:
 - [`.clear()`](/api/commands/clear)
 - [`.click()`](/api/commands/click)
 - [`.focus()`](/api/commands/focus)
+- [`cy.press()`](/api/commands/press)
 - [`.submit()`](/api/commands/submit)
 - [`Cypress.Keyboard`](/api/cypress-api/keyboard-api)
diff --git a/docs/api/cypress-api/custom-commands.mdx b/docs/api/cypress-api/custom-commands.mdx
@@ -17,7 +17,7 @@ There are two API available for adding custom commands:
 
 - [`Cypress.Commands.add()`](#Syntax) - use to add a custom command to use when
   writing tests
-- [`Cypress.Command.overwrite()`](#Overwrite-Existing-Commands) - use to
+- [`Cypress.Commands.overwrite()`](#Overwrite-Existing-Commands) - use to
   override an existing built-in Cypress command or reserved internal function.
   **Caution:** this overrides it for Cypress as well and could impact how
   Cypress behaves.