--- title: Improve your app’s accessibility description: Find and fix reproducible accessibility barriers in a key user journey, combining automated checks with keyboard and focus testing. url: "https://vercel.com/kb/prompts/improve-app-accessibility" last_updated: 2026-11-07 related_resources: "[Evaluate web accessibility](https://www.w3.org/WAI/test-evaluate/)": "Combine evaluation tools with knowledgeable human review." "[Develop keyboard interactions](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/)": "Apply predictable keyboard navigation and focus behavior to interactive components." "[Accessible form validation](https://www.w3.org/WAI/tutorials/forms/validation/)": "Associate useful validation feedback with the fields that need attention." --- # Improve your app’s accessibility Find and fix reproducible accessibility barriers in a key user journey, combining automated checks with keyboard and focus testing. Improve a working app by fixing accessibility barriers in a representative user journey. This prompt focuses on reproducible issues and shared components that affect navigation, forms, and interactive controls. Open or import your project in your coding agent and provide a route or flow to review. You need a local development environment and synthetic test data. The handoff supplies the prompt, without repository access or an authenticated browser session. Expect focused fixes, evidence for the interactions tested, and remaining manual review steps. Automated checks and a limited keyboard review cannot establish WCAG conformance or replace evaluation with assistive technology and users. ## Agent prompt ```text Review this application's accessibility and fix reproducible barriers in one representative user journey. If the intended project is unavailable, ask me to open or import it first. Read repository instructions and inspect the framework, package manager, shared layouts, component library, and available tests. Use the route or flow I name; otherwise start with the main navigation and one representative form or interactive page. Preserve the design and behavior while making focused fixes. Reuse accessible components and existing test tools before adding dependencies. Run the app locally with synthetic data or test accounts. If setup or browser access is unavailable, make only changes supported by source evidence and clearly separate them from unverified interaction findings. Record the affected route, starting state, reproduction steps, expected behavior, and observed barrier before fixing it. Prioritize issues that prevent completing the journey, then address related shared-component causes without redesigning unrelated screens. Check heading structure and landmarks, accessible names, image alternatives, form labels, instructions, and associated validation messages. Exercise the flow with a keyboard, including visible focus, logical order, menus, dialogs, submission, and error recovery. Follow the interaction pattern appropriate to each widget. Prefer native HTML semantics; ARIA attributes do not supply missing keyboard behavior. Keep modal focus contained when appropriate, restore it sensibly on close, and avoid trapping users in non-modal controls. Check text and control contrast, zoom and narrow-screen reflow, and whether information depends only on color. Preserve visible focus and access to controls when content changes. Make useful status and error messages available to assistive technology without excessive announcements. Check reduced-motion behavior when the affected component animates. Use existing automated accessibility checks where available, then manually repeat the affected keyboard journey. Add focused regression coverage for observable behavior, such as a dialog returning focus or a validation error associated with its field. Exercise both successful completion and recovery from an error. Check another consumer of any shared component you change. Run relevant lint and type checks. Do not treat a clean automated scan as proof of accessibility or WCAG conformance. Avoid real purchases, messages, or changes to live accounts while testing. Ask before external actions or deployment. Finish with fixes and their evidence, actual commands and results, local reproduction steps, blocked checks, and remaining screen-reader or human-review needs. State exactly which routes, states, and input methods were tested. ``` ## Related resources - [Evaluate web accessibility](https://www.w3.org/WAI/test-evaluate/): Combine evaluation tools with knowledgeable human review. - [Develop keyboard interactions](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/): Apply predictable keyboard navigation and focus behavior to interactive components. - [Accessible form validation](https://www.w3.org/WAI/tutorials/forms/validation/): Associate useful validation feedback with the fields that need attention. ## Try other prompts - [Add regression tests for a critical user flow](/kb/prompts/add-critical-flow-regression-tests): Protect a key Next.js user journey with isolated tests for visible outcomes, failure recovery, and relevant access boundaries. - [Reduce the JavaScript your app sends to browsers](/kb/prompts/reduce-client-javascript): Trim client JavaScript on one Next.js route, measure the difference, and preserve the interactions your users need. ## Reference Architecture Choose a stack and work through the decisions behind it, with curated documentation, guides, templates, and courses to help you build. - [Agent stack](/kb/architecture/agents): Build and operate agents with models, tools, and durable workflows. - [Web applications](/kb/architecture/web): Choose rendering, data, authentication, and caching approaches. - [Backends](/kb/architecture/backends): Choose a runtime, connect services, and run background work. [Browse all stacks](/kb/architecture) ## Build with prompts Build an app, extend an agent, or improve your project with ready-to-use prompts for your coding agent. [Browse the prompt library](/kb/prompts) · [Read the Markdown index](/kb/prompts.md)