--- id: accessibility/guides/improve-accessibility title: Improve Accessibility | Cypress Accessibility Documentation description: >- Discover how to break down accessibility reports, prioritize fixes, and make impactful progress toward accessible software with Cypress Accessibility. section: accessibility source_path: docs/accessibility/guides/improve-accessibility.mdx version: 524ff5211e60b5d53e55d6ad976d83966f66e7cd updated_at: '2026-04-30T14:20:05.396Z' --- # Improve accessibility This guide explains how to break down accessibility reports and create a focused plan for remediation using Cypress Accessibility. ## Starting from Scratch If you're beginning with a legacy application that has many accessibility issues, Cypress Accessibility provides actionable insights to help you prioritize fixes. Use the [Accessibility tab for a run](/llm/markdown/accessibility/core-concepts/run-level-reports.md) to identify violations across pages and components. Although the volume of issues might seem overwhelming, focusing on key factors can guide your approach: * **Goals**: Define your accessibility objectives. * **Timeline**: Establish a realistic timeline for improvements. * **Resources**: Assess the resources available for remediation. * **Future Code Changes**: Focus on areas of the codebase likely to evolve. * **Risk Assessment**: Consider the risks and costs of remaining inaccessible. Effective remediation often requires collaboration across departments, emphasizing the importance of an organization-wide commitment to accessibility, so understanding your organization's stance on accessibility and who needs to be in the conversation is also helpful. If your organization or team is newer to accessibility, you're likely to find plenty of issues reported by Axe Core® in Cypress Accessibility. Many of the issues in your first report may relate to concepts that are new, such as [ARIA attributes](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA) or [invalid nesting of interactive controls](https://dequeuniversity.com/rules/axe/4.2/nested-interactive). Since it will be impossible to fix all issues overnight, we recommend finding some low-hanging fruit as a starting point. This can help your team build confidence by getting some wins on the board, and teach them the overall idea of how accessibility problems get fixed. If you are use Claude, Cursor, or other AI agents in your development process, this is a good time to consider using the [Cypress Cloud MCP's accessibility tools](#Fixing-violations-with-your-AI-agent) to help triage your accessibility findings and develop action plans based on the source of each issue. ## Good low-hanging fruit Some accessibility issues are easier to address but have a significant impact. Consider issues related to [WCAG SC 4.2.1 - Name, role, value](https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html), which ensures interactive controls are appropriately labeled. Violations in this category often: * Appear frequently in applications. * Are flagged as Critical or Serious by Axe Core®. * Directly impact usability for screen reader users. ### Example: "Buttons Must Have Discernible Text" A common issue in modern interfaces is unlabeled icons used as buttons. The [button-name rule](https://dequeuniversity.com/rules/axe/4.7/button-name), which ensures buttons have descriptive text, is an ideal starting point because: * Adding a label is a simple code update. * Proper labels improve usability for all users. * Fixes typically don't require cross-team involvement. * Straightforward to validate with a screen reader. Existing code failing the button-name rule can usually be remediated pretty quickly, as long as it is clear what the correct text label is for a given control. And when it comes to new code, this text label content is also easy to add to discussions in the design and requirements stages of the development cycle, shifting the accessibility conversation left. Since every violation in Cypress is linked to a Deque University page with details about the nature of the problem and how to fix it, all the needed context is available, even to engineers who may be new to the topic of accessibility. Even if your first rule is not "Buttons must have discernible text", we suggest finding one with a similarly small amount of coordination or understanding needed to fix, so the team can experience success as quickly as possible. ## Check your changes in Branch Review One of the most frustrating experiences in accessibility is fixing one issue, only to discover you introduced some other issue in the process. Especially if the feedback cycles are long, it can reduce everybody's confidence in the remediation process. Wen making changes to improve accessibility, you can use [Branch Review](/llm/markdown/cloud/features/branch-review.md#Getting-Started) to see the effect of your solutions - including seeing any increase in issues that might be related to your code changes. ## Setting achievable goals Define a clear objective for each effort, such as fixing all violations of a specific rule within a defined scope. For example: * **View Focused**: Address all rule violations on a single page or component. * **Rule Focused**: Resolve a single rule violation across multiple pages or the entire application. Achieving these milestones provides a clear finish line for you and your team. It also provides time to assess the impact of the changes. Often, fixing one issue can cascade changes across your application, especially in componentized architectures: it's fine for these first goals to be small at first. In fact, it's preferable. ## Iterating towards success Incremental progress is key to long-term accessibility improvements. By focusing on manageable goals, your team can: * Gain expertise in specific accessibility rules. * Build workflows for preventing future regressions. * Gradually raise the accessibility standard across your projects. With support from Deque University's "Learn More" links in the reports, even teams new to accessibility can learn the related context and confidently address violations. For guidance on preventing regressions and enforcing accessibility policies, explore our [Blocking Pull Requests Section](/llm/markdown/accessibility/block-pull-requests.md). ## Fixing violations with your AI agent If you have [Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) configured, you can ask your agent to pull violation details from Cypress Cloud and work through fixes. Here's an example prompt that focuses on a specific rule and asks the agent to create a plan: > "Pull all `button-name` failures from the latest Cypress Cloud run. For each failing element: verify whether it's actually a problem given how the code is constructed. If it's valid, summarize the fix in markdown for my code review and propose a plan — wait for my approval before making any changes. If it's not a real issue, note it and move on. If you need more context to solve it, tell me what's missing — and if it's something only Cypress Cloud would have, submit feedback to the Cypress team." This works especially well for rules that appear across many elements, where the pattern of the fix is consistent once you've seen the first example.