diff --git a/docs/accessibility/configuration/axe-core-configuration.mdx b/docs/accessibility/configuration/axe-core-configuration.mdx
index b37b9d2ffa..31b043ab24 100644
--- a/docs/accessibility/configuration/axe-core-configuration.mdx
+++ b/docs/accessibility/configuration/axe-core-configuration.mdx
@@ -4,18 +4,23 @@
 
 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.
 
-Generally configuration of these rules isn't needed because your implementation of any policies about what should "fail a build" is handled using the [results-api.md](/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.
+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.
 
-**Note.** Certain Axe Core rules are off by default. Here are the rules that are currently either ignored by configuration, or for which results cannot be detected.
+**Note.** Certain Axe Core® rules are off by default. Here are the rules that are currently either ignored by configuration, or for which results cannot be detected.
 
 - `Elements must meet minimum color contrast ratio thresholds`
-  - This is off by default. This is both the slowest rule in the Axe Core ruleset, and the one that can have the highest percentage of false positives or incomplete checks.
+  - This is off by default. This is both the slowest rule in the Axe Core® ruleset, and the one that can have the highest percentage of false positives or incomplete checks.
   - It does work perfectly in many projects, so we are happy to turn this on for you if requested, so that you can see the results.
 - `<video> or <audio> elements must not play automatically`
   - Ignored because Test Replay does not yet capture the metadata to check this
 - `Delayed refresh under 20 hours must not be used`
   - Ignored because Test Replay does not collect the metadata for this
 
-### Component Testing
+## 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.
+
+## Updates to the Axe Core® library
+
+Updates to the Axe Core® library are released several times each year. While Cypress does not commit to updating our internal Axe Core® version within a specific timeframe, we will always wait at least 30 days before making an update.
+Since some updates introduce new rules or address bugs that change how issues are detected, this buffer is intended to give you time to make changes in your use of our [Results API](/accessibility/results-api) if needed. Axe Core® releases can be tracked [in GitHub](https://github.com/dequelabs/axe-core/releases).
diff --git a/docs/accessibility/core-concepts/accessibility-score.mdx b/docs/accessibility/core-concepts/accessibility-score.mdx
index eb734ea63a..ec79e2421c 100644
--- a/docs/accessibility/core-concepts/accessibility-score.mdx
+++ b/docs/accessibility/core-concepts/accessibility-score.mdx
@@ -11,9 +11,9 @@ sidebar_position: 30
 
 Cypress produces a top-line percentage score that indicates a general sense of accessibility for a project. This overall score for a run is based on the **average score of** **all application snapshots** that were captured during the run, and is rooted in the ratio of passing and failing accessibility checks performed on each snapshot, weighted according to the severity of the issues.&#x20;
 
-The severity levels presented in Cypress Cloud match the Axe Core `impact` level for each rule. This impact classification was developed by the creators of Axe, Deque Systems, to aid in prioritization of accessibility results, by highlighting rules that are likely to reveal the most substantial barriers (such as missing label text) so they can be addressed first.
+The severity levels presented in Cypress Cloud match the Axe Core® `impact` level for each rule. This impact classification was developed by the creators of Axe, Deque Systems, to aid in prioritization of accessibility results, by highlighting rules that are likely to reveal the most substantial barriers (such as missing label text) so they can be addressed first.
 
-It's important to note that the Web Content Accessibility Guidelines (WCAG) standards do not have a concept of relative severity of the Success Criteria. For **compliance** purposes, all failures of the Success Criteria count and must be addressed. For **usability** purposes, however, the impact values provided by Axe Core provide excellent guidance about which issues to take up first to bring the most benefit to disabled users of your plaform as quickly as possible.
+It's important to note that the Web Content Accessibility Guidelines (WCAG) standards do not have a concept of relative severity of the Success Criteria. For **compliance** purposes, all failures of the Success Criteria count and must be addressed. For **usability** purposes, however, the impact values provided by Axe Core® provide excellent guidance about which issues to take up first to bring the most benefit to disabled users of your plaform as quickly as possible.
 
 ## Algorithm
 
diff --git a/docs/accessibility/core-concepts/how-it-works.mdx b/docs/accessibility/core-concepts/how-it-works.mdx
new file mode 100644
index 0000000000..c0ebd23746
--- /dev/null
+++ b/docs/accessibility/core-concepts/how-it-works.mdx
@@ -0,0 +1,34 @@
+---
+sidebar_label: 'How it works'
+title: 'How it works'
+description: Cypress Accessibility\'s checks are powered by Axe Core® from Deque Systems.
+sidebar_position: 40
+---
+
+# How it works
+
+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. 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.
+
+## About Axe Core®
+
+Axe Core® is an open source library for detecting accessibility violations. It is used widely in the industry and have over 1 billion total downloads on npm.
+The library may be familiar from other tools, such as Lighthouse, or tools used for code linting, mobile testing and more, and has also been used extensively in Cypress tests through open-source packages (discussed more our [accessibility testing guide](/app/guides/accessibility-testing)). This means that Cypress Accessibility's
+configuration can often be easily aligned with your existing accessibility standards across different teams and platforms.
+
+Axe Core® checks for accessibility violations in your website's user interface, based on common accessibility standards. A violation detected by Axe usually indicates that some users with disabilities would have a problem using or perceiving a feature. An example of a violation would be an image without alternative text provided in the markup, which means the content is not perceivable to visually-impaired users. [Learn more about Axe.](https://github.com/dequelabs/axe-core)
+
+While this process reaches a high standard for automated testing, it cannot test every possible aspect of compliance, especially for heavily custom interfaces or aspects requiring human judgment.
+
+This means that a 100% axe score does not mean all possible accessibility errors have been ruled out. Deque reports that [Axe Core® can detect up to 57% of the issues that would appear in a manual accessibility audit](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/).
+
+The value of this form of testing in Cypress Accessibility is to give you fast, reliable, easy-to-understand feedback about common accessibility mistakes that are found in most projects. Providing these results automatically as part of your test run means that you can find and fix these issues with minimal friction, shifting accessibility left in your software development lifecycle.
+
+## Test Replay limitations
+
+Because Cypress Accessibility uses data captured through the Test Replay protocol, it is subject to any [limitations of that protocol](https://docs.cypress.io/faq/questions/cloud-faq#Is-everything-captured-and-replayed-in-Test-Replay) related to data capture or browser support.
diff --git a/docs/accessibility/core-concepts/run-level-reports.mdx b/docs/accessibility/core-concepts/run-level-reports.mdx
index b5ddfef138..2a9b64dd9e 100644
--- a/docs/accessibility/core-concepts/run-level-reports.mdx
+++ b/docs/accessibility/core-concepts/run-level-reports.mdx
@@ -54,12 +54,12 @@ An overall score is calculated based on all the Snapshots for a given View. The
 The count of elements in a view that failed a Rule, had an inconclusive check for a Rule, or were explicitly ignored by configuration.
 
 - **Failed** elements had at least one accessibility Rule fail during the run. These are considered in your accessibility Score and must be fixed.&#x20;
-- **Inconclusive** elements had at least one check marked "incomplete" by Axe Core during the run. These represent checks that couldn't be completed for technical reasons, or items that need manual review to confirm if there is an accessibility issue. These do not affect your score.
+- **Inconclusive** elements had at least one check marked "incomplete" by Axe Core® during the run. These represent checks that couldn't be completed for technical reasons, or items that need manual review to confirm if there is an accessibility issue. These do not affect your score.
 - **Ignored** elements are those that had either failing or incomplete checks, but were ignored with [CSS selectors in your configuration](/accessibility/configuration/elementfilters). They do not affect your score. Cypress still processes these elements and makes the results available, so that you always know results were was ignored, since these elements are still present in your UI and users will encounter them.
 
 #### Failed rules
 
-Failed rules are broken down for each View with a mini chart displaying Axe Core severity levels, as well as a total count for failed rules. Both of these help you identify at a glance which pages or components have high numbers serious issues.
+Failed rules are broken down for each View with a mini chart displaying Axe Core® severity levels, as well as a total count for failed rules. Both of these help you identify at a glance which pages or components have high numbers serious issues.
 
 #### Severity
 
@@ -67,7 +67,7 @@ In Cypress Accessibility, severity levels are mapped to Axe Core's `impact` leve
 
 ## Rules
 
-This section lists the outcome of every Axe Core rule that was enabled at the time of this run.
+This section lists the outcome of every Axe Core® rule that was enabled at the time of this run.
 
 <DocsImage
   src="/img/accessibility/core-concepts/cypress-accessibility-rules-list.png"
@@ -81,11 +81,11 @@ Each Rule in the table has the following attributes:
 - An icon representing the overall status for the rule, which can be any one of these:
   - **Passed** -- every time this rule applied to an element, the element either passed that rule's checks or was intentionally ignored
   - **Failed** -- at least one failing element was detected in the run
-  - **Inconclusive** -- no elements failed this rule, but at least one element was labelled "incomplete" by Axe Core and requires manual review
+  - **Inconclusive** -- no elements failed this rule, but at least one element was labelled "incomplete" by Axe Core® and requires manual review
   - **Inapplicable** -- this rule was enabled during the run, but there were no elements detected that required the rule to run
   - **Ignored by config** -- this rule was ignored at the config level for the project and did not run
 - The description for the rule
-- The Axe Core severity level for the rule
+- The Axe Core® severity level for the rule
 - The counts of failed, inconclusive, and ignored elements for each rule
 
 ## Filtering
diff --git a/docs/accessibility/get-started/introduction.mdx b/docs/accessibility/get-started/introduction.mdx
index 780657ad58..36b600350c 100644
--- a/docs/accessibility/get-started/introduction.mdx
+++ b/docs/accessibility/get-started/introduction.mdx
@@ -1,7 +1,7 @@
 ---
 sidebar_label: Introduction
 title: 'Introduction'
-description: 'Cypress Accessibility provides organized, visual, and actionable accessibility reports, based completely on the tests you record to Cypress Cloud, and powered by Axe Core by Deque Systems.'
+description: 'Cypress Accessibility provides organized, visual, and actionable accessibility reports, based completely on the tests you record to Cypress Cloud, and powered by Axe Core® by Deque Systems.'
 sidebar_position: 10
 sidebar_custom_props: { 'new_label': true }
 ---
@@ -10,27 +10,35 @@ sidebar_custom_props: { 'new_label': true }
 
 <AccessibilityAddon />
 
-Cypress Accessibility provides organized, visual, and actionable accessibility reports, based completely on the tests you record to Cypress Cloud, and powered by Axe Core by Deque Systems.
+## What is Cypress Accessibility?
+
+Cypress Accessibility provides organized, visual, and actionable accessibility reports, based completely on the tests you record to Cypress Cloud, and powered by Axe Core® by Deque Systems. This is the documentation page for that product. To learn about the general topic of accessibility testing using the Cypress App, see [our guide on this topic](/app/guides/accessibility-testing).
+
+Cypress Accessibility generates a sortable, filterable report, to see scores and violation counts by page/component, or a combined rule-based report for the entire run. It also includes a drill-in view with live DOM snapshots highlighting each issue detected.
 
 <DocsImage
   src="/img/accessibility/get-started/cypress-accessibility-overview.png"
   alt="A graphic showing the Cypress Accessibility dashboard including list of rules, views, and the user interface showing how devtools can be used"
 />
 
-## How it works
+## How are reports created?
 
 Cypress Cloud generates an accessibility report for each unique state reached during your tests on a given Cypress run. This includes pages visited in end-to-end tests, as well as individual components rendered in component tests, and any states or pages that were encountered as a result of interactions performed during test execution.
 
-These individual accessibility "snapshots" are grouped into page- or component-level reports (called "Views"), and also form the bases of a unified report covering the entire run. This gives you multiple ways to examine your report - by focusing on the most important parts of your application, or by
+All of these page or component states are detected using the same protocol that powers [Test Replay](/cloud/features/test-replay), meaning no additional code or setup is needed anywhere in your tests.
 
-Reports are generated using the industry-standard open source [Axe Core](https://github.com/dequelabs/axe-core)® library created by Deque Systems, with a default configuration focused on the [Web Content Accessibility Guidelines (WCAG) 2.1](https://www.w3.org/WAI/standards-guidelines/wcag/).&#x20;
-
-## Understanding what is tested
+These individual accessibility "snapshots" are grouped into page- or component-level reports (called "Views"), and also form the bases of a unified report covering the entire run. This gives you multiple ways to examine your report - by focusing on the most important parts of your application, or by
 
-Axe Core checks for accessibility violations in your website's user interface, based on common accessibility standards. A violation detected by Axe usually indicates that some users with disabilities would have a problem using or perceiving a feature. An example of a violation would be an image without alternative text provided in the markup, which means the content is not perceivable to visually-impaired users. [Learn more about Axe.](https://github.com/dequelabs/axe-core)
+Reports are generated using the industry-standard open source [Axe Core®](https://github.com/dequelabs/axe-core) library created by Deque Systems, with a default configuration focused on the [Web Content Accessibility Guidelines (WCAG) 2.1](https://www.w3.org/WAI/standards-guidelines/wcag/).
 
-Axe reaches a high standard for automated testing, but cannot test every possible aspect of compliance, especially for heavily custom interfaces or aspects requiring human judgment. Please note that a 100% axe score does not mean all possible accessibility errors have been ruled out. [Axe typically detects up to 57% of the issues that would appear in a manual accessibility audit.](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/)
+## Highlights
 
-##### Trademark notice
+- All steps of all user flows tested in Cypress are captured automatically
+- Server-side execution means no disruption to existing test code or practices, and no performance impact from accessibility checks
+- Reports are generated at the page or component level, as well as a combined report showing the outcome of all accessibility rules checked in the run
+- Debuggable full-page DOM snapshots with highlights are provided for every violation
+- Most iframe and Shadow DOM uses cases are supported out-of-the-box
+- The [Results API](/accessibility/results-api) allows you to own how your CI pipeline reacts to the accessibility results of the run to implement a policy
+- "Ignored" elements are isolated and don't affect your score, but can still be reviewed
 
-_Note: DEQUE, DEQUELABS, AXE®, and AXE-CORE® are trademarks of Deque Systems, Inc. in the US and other countries._
+_Note: DEQUE, DEQUELABS, AXE®, and AXE-CORE® are trademarks of Deque Systems, Inc. in the US and other countries. These terms are used throughout our documentation to refer to the accessibility testing library used by Cypress Accessibility._
diff --git a/docs/app/core-concepts/best-practices.mdx b/docs/app/core-concepts/best-practices.mdx
index 2ccec5f88f..27bfbb082f 100644
--- a/docs/app/core-concepts/best-practices.mdx
+++ b/docs/app/core-concepts/best-practices.mdx
@@ -220,16 +220,24 @@ If the answer is **no** because the text could be changed - then use
 
 Cypress loves the Testing Library project. We use Testing Library internally,
 and our philosophy aligns closely with Testing Library's ethos and approach to
-writing tests. We strongly endorse their best practices.
+writing tests. We strongly endorse their best practices for situations where,
+as with `cy.contains()`, you want to fail a test if a specific piece of content or
+accessible role is not present.
 
 You can use the
 [Cypress Testing Library](https://testing-library.com/docs/cypress-testing-library/intro/)
 package to use the familiar testing library methods (like `findByRole`,
 `findByLabelText`, etc...) to select elements in Cypress specs.
 
-In particular, if you're looking for more resources to understand how we
+If you are coming from a React Testing Library background and looking for more resources to understand how we
 recommend you approach testing your components, look to: [Cypress Component Testing](/app/component-testing/get-started).
 
+### Accessibility Testing
+
+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.
+
 ## <Icon name="angle-right" /> Assigning Return Values
 
 :::danger
diff --git a/docs/app/get-started/why-cypress.mdx b/docs/app/get-started/why-cypress.mdx
index 8df4cc7877..56ff2826ae 100644
--- a/docs/app/get-started/why-cypress.mdx
+++ b/docs/app/get-started/why-cypress.mdx
@@ -38,10 +38,10 @@ of your test suite and the quality of your application.
 
 - [Cypress App](/app/core-concepts/open-mode), a free,
   [open source](https://github.com/cypress-io/cypress),
-  locally installed app.
+  locally installed app for writing and running tests.
 - [Cypress Cloud](/cloud/get-started/introduction), a paid service for recording tests, surfacing test results, and providing test analytics.
 - [UI Coverage](/ui-coverage/get-started/introduction), a paid add-on providing a visual overview of test coverage across every page and component of your app, offering clear insights into uncovered areas that everyone can understand.
-- [Cypress Accessibility](/accessibility/get-started/introduction), a paid add-on providing accessibility checks to ensure your application is accessible to all users.
+- [Cypress Accessibility](/accessibility/get-started/introduction), a paid add-on providing accessibility checks, which helps detect barriers for people with disabilities using your application.
 
 Cypress is a robust solution that can improve the quality of your application.
 
@@ -52,8 +52,7 @@ Cypress is a robust solution that can improve the quality of your application.
   CI Provider, [Cypress Cloud](/cloud/get-started/introduction) can record your test
   runs surfacing exactly what happened during the test in [Test Replay](/cloud/features/test-replay).
   You'll never have to wonder: _Why did this fail?_
-- **Finally:** Add on [Cypress Accessibility](/accessibility/get-started/introduction) to ensure your application is
-  accessible to all users and [UI Coverage](/ui-coverage/get-started/introduction) to ensure you've tested
+- **Finally:** Add on [Cypress Accessibility](/accessibility/get-started/introduction) to get continuous feedback on accessibility issues and regressions, and [UI Coverage](/ui-coverage/get-started/introduction) to ensure you've tested
   every part of your application.
 
 ## Features
@@ -207,9 +206,9 @@ it('uses custom text for the button label', () => {
 
 ### Accessibility Testing
 
-You can write Cypress tests to check the accessibility of your application.
-When combined with [Cypress Accessibility](/accessibility/get-started/introduction), insights can be surfaced when
-accessibility standards are not met through your testing - with no configuration required.
+You can write Cypress tests to check the accessibility of your application, and use plugins to run broad accessibility scans.
+When combined with [Cypress Accessibility](/accessibility/get-started/introduction) in Cypress Cloud, insights can be surfaced when specific
+accessibility standards are not met through your testing - with no configuration required. See our [Accessibility Testing guide](/app/guides/accessibility-testing) for more details.
 
 ```js
 it('adds todos', () => {
diff --git a/docs/app/guides/accessibility-testing.mdx b/docs/app/guides/accessibility-testing.mdx
new file mode 100644
index 0000000000..4da153b8f9
--- /dev/null
+++ b/docs/app/guides/accessibility-testing.mdx
@@ -0,0 +1,173 @@
+---
+title: Accessibility Testing
+---
+
+Accessibility testing helps to confirm that an application works correctly for people with disabilities.
+
+To set a good foundation for an accessible user experience, web sites and apps must conform to certain guidelines, known as the [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) (WCAG). Meeting or exceeding these guidelines will help ensure your disabled users can independently perceive the content of your application, navigate through your pages and sections, and complete the available actions.
+
+Cypress supports many kinds of accessibility testing, through standard test practices, a rich plugin ecosystem, as well as [Cypress Accessibility](/accessibility/get-started/introduction), a commercial, enterprise-ready solution in Cypress Cloud.
+
+## Including accessibility in your Cypress tests
+
+Here are the main ways to account for accessibility when testing with Cypress:
+
+### Accessibility scans
+
+- [In-test plugins](#In-test-plugins)
+- [Cypress Accessibility](#Cypress-Accessibility)
+
+### Explicit, application-specific tests
+
+- Accessibility-focused assertions and locators
+- Tests for specific functionality relevant to assistive technology
+
+We will discuss each of these below.
+
+## Accessibility Scans
+
+:::info
+Automated scans are effective because many accessibility issues are caused by incorrect HTML structure or missing data that would be required by assistive technologies like screen readers, voice control systems, Braille displays, and more. Browsers transform the current HTML on the page into a standardized format that other technologies can hook into. Automated scans in your tests will alert you if specific items needed for this process are missing.
+:::
+
+:::warning
+Note that while automated scans do a good job at detecting violations of a known list of rules, no automated scan can prove that the interface is **fully** accessible and works well for users with disabilities. It is always necessary to understand the limitations and expected coverage provided by the library you choose, and then make a plan to cover the gaps with manual testing and/or traditional Cypress assertions about additional expected behavior, based on your knowledge of what is needed by your users.
+:::
+
+### In-test plugins
+
+The [`cypress-axe`](https://www.npmjs.com/package/cypress-axe) plugin is a community plugin that integrates the popular [Axe Core® library by Deque Systems](https://github.com/dequelabs/axe-core/) into your Cypress tests.
+
+After setting up the plugin, commands are added to your project to inject the library and use it to run an accessibility check. Running the included `checkA11y()` command performs a scan of the current state of the page or component that you are testing, and you can choose to fail the test in response to accessibility issues detected. Detailed configuration is available to scope this to the specific WCAG Success Criteria and related rules that you want to test.
+
+There are also some newer community plugins that are themselves built on top of `cypress-axe` and extend it in various ways, such as [`wick-a11y`](https://www.npmjs.com/package/wick-a11y) and [`cypress-a11y-report`](https://www.npmjs.com/package/cypress-a11y-report), as well as other accessibility testing libraries like the [IBM Equal Access Checker](https://www.npmjs.com/package/cypress-accessibility-checker). All of these tools have their own dedicated documentation for installation, setup, and executing the checks, which we won't repeat here.
+
+The general "add a command to trigger a scan" approach helps detect and prevent all-too-common issues like poor color contrast, missing labels for icons and buttons, images without alt text, and other errors in the implementation of a user interface that can be detected with generic checks.
+
+#### Managing test performance
+
+In-test automated accessibility checks are so valuable because they bundle a large amount of assertions about all kinds of rules and criteria into one simple command. But this also means they come with some overhead: for example, each call to `cy.checkA11y()` evaluates DOM elements to see which accessibility rules apply to each element in the page, and then runs specific DOM checks for those elements for each of the rules, and computes the results, all of which takes time to complete. If other assets like screenshots are generated at the same time, the performance of this should also be considered, and assets should be generated only when needed.
+
+Generally this is not a problem if you have a small number of accessibility checks, but it can become a big contributor to your pipeline's overall execution time as you scale up your accessibility testing and want to run checks against hundreds or even thousands of unique states of complex applications and workflows. Since accessibility checks tend to be added gradually over time, the time taken is often not obvious, but it is definitely worth paying attention to.
+
+To avoid performance bloat, you will want to actively manage the tradeoff between test performance and how often tests are executed. This is sometimes solved by testing only the initial pageload, or the state at the end of a test, but this approach misses many important states like modals, multistep workflows, error states in forms, open states of menus, and more. And since many tests may begin or end at the same page state as other tests, there can be a lot of redundant scans, so it pays to be more precise and intentional in what you test.
+
+Performance can also be managed by targeting the accessibility checks to only certain rules or certain parts of the page, or confining them to component tests. Testers should be trained on how and when to run accessibility checks to get the best feedback possible while eliminating redundant checks that don't add value, and minimizing the disruption to the test pipeline.
+
+It is best to proactively manage this, because unnecessary flake, failures, or timeouts related to accessibility checks can cause frustration and lead to resistance in adopting this form of testing, which in turn makes it harder to gain momentum towards meeting your accessibility goals.
+
+### Cypress Accessibility
+
+<DocsImage
+  src="/img/accessibility/cy-a11y-detail.png"
+  width="60%"
+  alt="Cypress Accessibility UI displaying a 'Buttons must have discernible text' violation example"
+/>
+
+In-test accessibility checks are the only kind available in typical testing scenarios. They come with some limitations and tradeoffs that [Cypress Accessibility](/accessibility/get-started/introduction), available in Cypress Cloud, is designed to solve. By moving the checks outside of the test context and running them in Cypress Cloud as tests are recorded, Cypress Accessibility removes adoption, training, and test performance hurdles that can hinder the effective implementation of in-test checks. Cypress automatically detects all the steps within user flows, requiring no test code to be written.
+
+To learn more, you can read our [dedicated docs](/accessibility/get-started/introduction), or review a [public live example of an automatically-generated accessibility report](http://on.cypress.io/rwa-accessibility-views) in our Cypress Realworld App demo project.
+
+## Accessibility-specific tests
+
+While automation like Axe Core® can detect missing attributes and other aspects of code quality that impact the experience of people with disabilities using the web, this kind of automation doesn't know anything about your specific application and the expectations you have for your users. That's where including accessibility in your specs comes in.
+
+### Asserting alt text of images
+
+To assert that the correct alternative text is present on your logo image, an explicit test can be written:
+
+```js
+it('adds todos', () => {
+  cy.visit('https://example.cypress.io/')
+  // explicitly check the alt text of an image
+  cy.get('img[data-cy="logo"]').should('have.attr', 'alt', 'Cypress Logo')
+})
+```
+
+It's also possible to use an accessibility-aware locator approach to find the element while performing some other assertion. Here instead of using the element's test ID, we locate the image by its `alt` text. This is more concise, and the decision of which format to prefer is up to your team's preferences:
+
+```js
+// use the `alt` content to target the image
+cy.get('img[alt="Cypress Logo"]').should('be.visible')
+```
+
+This kind of accessibility-friendly locator approach is also possible with the [Cypress Testing Library](https://testing-library.com/docs/cypress-testing-library/intro) plugin, which provides some helpers for this purpose:
+
+```js
+// use the recommended ByRole Testing Library locator
+cy.findByRole('img', { name: 'Cypress Logo' }).should('be.visible')
+```
+
+### Asserting the accessible name of a button
+
+A similar accessibility-minded locator technique can be used with interactive elements like buttons:
+
+```js
+// click the "Submit" button located by `cy.contains()`
+cy.contains('button', 'Submit').click()
+```
+
+And using the Testing Library `ByRole` locator:
+
+```js
+// click any element with role `button` and an accessible name of `Submit`
+cy.findByRole('button', { name: 'Submit' }).click()
+```
+
+There are some important differences to consider between locating specific HTML elements themselves and locating those same elements only by their `role`, which is the main Testing Library recommendation. We'll discuss these in the next section.
+
+### Test IDs, Testing Library, and Accessibility
+
+The use of `data-cy`-style test ID attributes to help with test stability has been a longstanding [best practice recommendation](/app/core-concepts/best-practices#Selecting-Elements) by Cypress. Test IDs are resilient to non-functional UI changes because they don't specify anything about the nature of the code or content itself, only that some element with that data attribute is present. When code changes, as long as the `data-cy` attributes are preserved in the right places, all the tests using them should continue to pass.
+
+This approach explicitly avoids testing accessibility - which is all about the nature and structure of the content being tested, and how well the implementation in code matches that content, to provide a functional experience in a range of assistive technologies and browser setups.
+
+Testing Library (introduced in 2018 and now widely popular) is sometimes seen as a solution to the fact that explicit Test IDs do not provide any accessibility testing benefit. While Testing Library's helpers can be convenient and useful in their own right, and they keep accessibility top-of-mind for testers, it's important to note that Testing Library locators do **not** guarantee the accessibility of the elements being tested.
+
+:::warning
+Whether you primarily use Testing Library element locators, test IDs, or a different approach, testing for accessibility requires making specific assertions about the **implementation and behavior** of your application.
+:::
+
+There is much more to this topic than we can cover here, but we will provide a small example, and a recommendation for what to do.
+
+### Asserting about roles vs elements - button example
+
+The native HTML `button` element has a complex accessibility contract implemented by the browser for keyboard and screen reader users. Here is a partial list of ways a button element is automatically managed by the browser:
+
+- It has the implicit `role` of `button` so that users know what it is - a screen reader, for example, would announce it as a button
+- It has a default browser button style to visually distinguish it from surrounding content
+- It has default browser styles for hover and "pressed" states
+- It is placed in the tab order of the document and can be focused with the keyboard
+- When focused it receives a focus outline style
+- It can be activated with a mouse click, or the enter key, or the space bar
+- If placed inside a `form` element, activating the button by any of these methods will submit the form (because its default type is `submit`)
+- It will receive specific styling, customizable by the user, in Windows High Contrast Mode (used by people with certain visual disabilities)
+
+On the other hand, a `div` with `role` of `button` does not get any default browser accessibility behavior, and is **not accessible** without custom JavaScript and CSS replacing the browser contract.
+
+This means that, without some assertions about either the `button` element itself, or a full test of the accessibility "contract" of that element, it is not safe for a developer to refactor from a `button` to a `<div role="button">`, even though Testing Library will treat each as the same if located using the `ByRole` locator. This is because, much like test IDs, the `ByRole` approach is intended to _avoid_ testing the implementation directly, to keep tests resilient when code is refactored.
+
+Developers who are unfamiliar with accessibility may assume that if a Testing Library `ByRole` locator can be made to pass before and after a code change, there has been no functional or accessibility-related change in the underlying element. As we've seen, this is not actually the case, because of the extra behavior browsers only implement for native HTML elements. For more about this difference and why semantic HTML elements are preferred, see the [first rule of Accessible Rich Internet Applications (ARIA)](https://www.w3.org/TR/using-aria/#rule1).
+
+## Where to test accessibility
+
+So what should you do in your test automation to help confirm the UI is accessible? First of all, for known critical areas like forms or checkout flows, ensure that the accessibility behavior is tested explicitly in at least one place. The means verifying that form fields and buttons have the correct labels and use the expected HTML elements, and other aspects of the DOM that communicate necessary information.
+
+Component tests are a fantastic place to do this centralized accessibility spec work, whether using [Cypress Component testing](/app/component-testing/get-started) or something else. Component tests are run locally during development, written by developers as they build the UI, and can easily specify the specific HTML that is intended to be rendered, without being a distraction in an end-to-end test of a specific user flow.
+
+Accessibility should be tested at least once for a given component, area of the application, or workflow. Once that is achieved, there is no additional accessibility benefit to repeatedly asserting subsets of the same things in other tests, unless those tests introduce new combinations of components that have not been tested for accessibility anywhere else.
+
+### Choosing a locator approach
+
+Test IDs are the most resilient locator option and are a good choice for maximizing the stability of your pipeline, especially if end-to-end tests are written by people who are not familiar with accessibility, and don't already know the correct roles, elements, and behavior that should be expected. You do not lose any accessibility "coverage", as long as accessibility is explicitly tested with assertions, and a library like Axe Core® is in place to catch mistakes.
+
+Testing Library locators are convenient and familiar to many React developers (due to its origins as "React Testing Library"), and they don't require any code changes, but may cause _many_ tests to fail when a label is missing, instead of just your explicit accessibility assertions, because they are a step closer to the implementation details.
+
+Additionally, Testing Library locators can provide a false sense of confidence that something is accessible simply because it can be located by its role. Still, when understood correctly, teams can write effective tests using this approach, and some locators like [`findByLabelText`](https://testing-library.com/docs/queries/bylabeltext) stand out as being particularly useful.
+
+What is most important in all accessibility automation discussions is an this: how can your testing strategy best support your users with disabilities to independently understand and use your application? Cypress enables you to place the user at the center of your testing process. With a mix of automated scans and some specific intentional assertions, you can reach high levels of confidence that your application is free of known accessibility errors and let your test pipeline warn you if things are going off track.
+
+## See also
+
+- [Cypress Accessibility](/accessibility/get-started/introduction)
+- [Plugins](/app/plugins/plugins-list)
diff --git a/docs/partials/_accessibility-addon.mdx b/docs/partials/_accessibility-addon.mdx
index ba4efec1b1..29c2fc262d 100644
--- a/docs/partials/_accessibility-addon.mdx
+++ b/docs/partials/_accessibility-addon.mdx
@@ -1,5 +1,5 @@
 :::tip
 
-**Cypress Accessibility** is a paid add-on. [Schedule a demo](https://www.cypress.io/ui-coverage?utm_medium=website&utm_source=docs.cypress.io&utm_content=addon-tip) today and see how easy it is to enhance your accessibility testing while speeding up your development process.
+**Cypress Accessibility** is a paid add-on. [Schedule a demo](https://www.cypress.io/accessibility?utm_medium=website&utm_source=docs.cypress.io&utm_content=addon-tip) today and see how easy it is to enhance your accessibility testing while speeding up your development process.
 
 :::
diff --git a/src/theme/BackToTopButton/DarkModeSwitch.js b/src/theme/BackToTopButton/DarkModeSwitch.js
index d332094f0e..3f4c20297f 100644
--- a/src/theme/BackToTopButton/DarkModeSwitch.js
+++ b/src/theme/BackToTopButton/DarkModeSwitch.js
@@ -24,6 +24,7 @@ export default function DarkModeSwitch() {
             isDark,
         }
       )}
+      aria-label={isDark ? 'Switch to light mode' : 'Switch to dark mode'}
       onClick={() => setColorMode(isDark ? 'light' : 'dark')}
     >
       <span
diff --git a/static/img/accessibility/core-concepts/cypress-accessibility-issue-detail-view.png b/static/img/accessibility/core-concepts/cypress-accessibility-issue-detail-view.png
index d5fb4416c8..26573c1f4f 100644
Binary files a/static/img/accessibility/core-concepts/cypress-accessibility-issue-detail-view.png and b/static/img/accessibility/core-concepts/cypress-accessibility-issue-detail-view.png differ
diff --git a/static/img/accessibility/core-concepts/cypress-accessibility-rules-list.png b/static/img/accessibility/core-concepts/cypress-accessibility-rules-list.png
index 61318ff09a..8001e3476b 100644
Binary files a/static/img/accessibility/core-concepts/cypress-accessibility-rules-list.png and b/static/img/accessibility/core-concepts/cypress-accessibility-rules-list.png differ
diff --git a/static/img/accessibility/core-concepts/cypress-accessibility-views-dashboard.png b/static/img/accessibility/core-concepts/cypress-accessibility-views-dashboard.png
index 3fbb91fcb3..b1b4d7678c 100644
Binary files a/static/img/accessibility/core-concepts/cypress-accessibility-views-dashboard.png and b/static/img/accessibility/core-concepts/cypress-accessibility-views-dashboard.png differ
diff --git a/static/img/accessibility/cy-a11y-detail.png b/static/img/accessibility/cy-a11y-detail.png
new file mode 100644
index 0000000000..886fa15a3c
Binary files /dev/null and b/static/img/accessibility/cy-a11y-detail.png differ