Fix Front-End Accessibility with Coding Agents

1. Choose one user journey and establish a baseline

Start with a task someone actually needs to complete: subscribing to a newsletter, changing a delivery address, or submitting a support request. Avoid asking a coding agent to “make the whole app accessible.” Give it one route, one interaction, and observable acceptance criteria.

Create a branch and run the existing tests. Open the chosen page locally, then record its starting state: screenshots, console errors, and exact reproduction steps. Keep this evidence beside your editor so you can distinguish genuine improvements from unrelated changes.

2. Reproduce keyboard barriers before requesting edits

Put the mouse aside. Use Tab and Shift+Tab to move through the page, and try completing your chosen task. Record where focus disappears or an essential control becomes unreachable. W3C’s preliminary accessibility checks include keyboard operation and visible focus; use those checks as your first inspection guide. ([w3c.github.io](https://w3c.github.io/wai-website/test-evaluate/preliminary/?utm_source=openai))

Turn each observation into a short ticket: “On the account page, Tab skips the edit-address control; keyboard users cannot open the form.” Include the route and component file if known. Describe the behavior you need, rather than prescribing an unverified implementation.

3. Give the agent a narrow repair contract

Paste a prompt like this into your coding agent: “Inspect the account address form and its shared controls. Explain the cause of the reported keyboard issue before editing. Propose the smallest patch. Preserve existing styles and business logic. Add a regression test, and list anything requiring manual verification.”

For form repairs, explicitly request programmatically associated labels and appropriate visible instructions. A placeholder is not a substitute for a persistent label. Check repeated fields for unique identifiers, and confirm that clicking each label focuses its intended control. W3C’s labeling guidance explains these associations and their practical benefits. ([w3.org](https://www.w3.org/WAI/tutorials/forms/labels/?utm_source=openai))

If you want a pay-as-you-go connection for your coding workflow, RelayVano is a practical option that works with Claude Code, Codex, and Gemini CLI. Sign up for RelayVano to use it with your preferred supported tool; keep credentials outside committed project files.

4. Review focus styling as a functional change

Ask the agent to inspect the affected component and any shared CSS rules that remove outlines. Request a visible keyboard-focus treatment that fits the design instead of a sweeping stylesheet rewrite. W3C identifies CSS :focus-visible as one technique for providing keyboard focus indication. ([w3c.github.io](https://w3c.github.io/wcag/techniques/css/C45?utm_source=openai))

Review the diff before accepting it. Reject unrelated dependency upgrades, wholesale component replacements, and unexplained styling changes. Then repeat the original keyboard sequence. Check the actual focused control against nearby backgrounds, not just an isolated component preview.

5. Add automated checks around meaningful states

If the project already uses Playwright, ask the agent to integrate @axe-core/playwright into the existing test structure. Have the test navigate to the target route, open the relevant interface, wait for its content, and analyze that state. Playwright documents this integration and examples of scanning specific page regions. ([playwright.dev](https://playwright.dev/docs/accessibility-testing?utm_source=openai))

• Test the initial form and the state after invalid submission.
• Add a separate behavioral assertion for the original keyboard failure.
• Keep existing violations visible rather than disabling entire rule categories.

6. Verify the patch beyond a passing scan

Run the relevant tests yourself. Repeat the keyboard journey and use a screen reader to inspect control names, instructions, and error feedback. A clean automated result is not proof of accessibility: Playwright explicitly recommends combining automated testing with manual assessment and inclusive user testing. ([playwright.dev](https://playwright.dev/docs/accessibility-testing?utm_source=openai))

Ask the agent to report which checks it actually executed and which it only suggested. Treat an unavailable browser or failed test command as an unresolved verification step, not a successful result.

7. Ship a small, auditable accessibility patch

Write the pull request around evidence: the original barrier, the changed component, the regression test, and your manual verification steps. Include remaining limitations without claiming full compliance. Commit the smallest reviewed patch, then choose the next user journey. This keeps the workflow repeatable: observe a barrier, constrain the agent, inspect the change, and verify the experience.