Review Pull Requests for Accessibility in a React App

The agent starts from the pull request, not from a generic React checklist. In an app shaped like cypress-io/cypress-realworld-app, package.json pins react and react-dom 18.2.0, react-router-dom 5.3.4, @mui/material 5.15, formik 2.4.6 and xstate 4.38.3, with Vite 8, TypeScript 5.8.3, Cypress 16 and Vitest 3 in development; engines asks for Node 22 or 24 and .nvmrc says 22.20.0, with a yarn.lock. yarn start:ci runs Vite on port 3000 and the Express backend in backend/app.ts on 3001, as .env sets through PORT and VITE_BACKEND_PORT, and cypress.config.ts points baseUrl at 3000, seeds the database through a db:seed task that POSTs to /testData/seed on 3001, and runs component tests from src/**/*.cy.tsx. .env also sets SEED_DEFAULT_USER_PASSWORD=s3cret, and the list:dev:users script prints the seeded usernames from data/database.json, which is how the agent signs in.

It reads what the repository already does for accessibility, so the review adds rather than repeats. eslint.config.mjs loads eslint-plugin-cypress only; there is no jsx-a11y plugin and no axe dependency in package.json. index.html sets lang="en". Across src/components the explicit ARIA is sparse: NavBar.tsx labels the drawer button open drawer, NotificationListItem.tsx labels its button mark as read, and TransactionListAmountRangeFilter.tsx ties its slider to range-slider with aria-labelledby. Forms such as SignInForm.tsx use MUI TextField with label props and data-test attributes, which gives inputs their names. TransactionItem.tsx renders MUI Avatar components with a src and no alt for the sender and receiver, and the whole list item carries an onClick on a ListItem, both of which the agent checks against the rendered DOM rather than the source alone.

For the pull request under review the agent clones the repository at the pull request's branch, runs yarn install --frozen-lockfile on the Node version from .nvmrc, starts the app with yarn start:ci, waits for both ports the way the cypress-io/github-action step in .github/workflows/main.yml does, and seeds the database. It reads the diff to list the components and routes the change touches, signs in with a seeded user and the default password, and opens each affected screen in its own browser in the states the change can produce: empty, loading, with validation errors, signed in and signed out. On each it runs axe-core from the browser, with no dependency added to the repository, and walks the screen with Tab, Shift+Tab, Enter, Space and Escape, recording focus order, visible focus, and whether dialogs and drawers trap and return focus. It then checks out the base branch and repeats the same screens, so every finding is a regression or a pre-existing problem, labelled as such.

The review is posted on the pull request as one review with a comment per finding, on the changed line in the component that renders the element. Each comment names the element and component, the route and state, the rule or keyboard step that failed, how to reproduce it, and a fix in MUI terms, such as an alt on the Avatar, an aria-label on an icon button, or a role and key handler on a clickable ListItem. Pre-existing problems the change did not cause go in the summary, not on lines. The agent writes accessibility.md with the full axe output per screen and the keyboard log, and pushes nothing.

What comes back is a review on the pull request and accessibility.md as an artifact on the session. The review has one comment per regression, each anchored to the changed line in the component, with the route and state in which it appears, the axe rule id or the keyboard step that failed, the steps to see it, and a fix written against the MUI components the app uses. The summary lists pre-existing problems found on the same screens with the base branch so they can become their own issues, and names the screens and states that were checked and passed. No commit is pushed; the agent's branch checkout is read-only work in its sandbox.

A reviewer reads the regressions first and reproduces one with the steps given, then decides whether the pre-existing list deserves a follow-up. accessibility.md holds the full axe output per screen and the keyboard log, so a disputed comment can be traced to the rule and the DOM node that raised it. The session's transcript shows the install, the two servers starting, the seeding call and every page visit, so a reader can see which states were reached.

An automation in the Project with a github trigger on pull_request.opened and pull_request.synchronize starts one run per push with this prompt; the trigger adds the pull request to the run after the prompt, so nothing in input needs filling in. Only pushes by an owner, member or collaborator fire it, never pull requests from forks. Each run works in its own sandbox and posts its own review.

To review only pull requests that touch src/components, a handler on your server receives GitHub's pull request webhook, reads the changed files, and sends POST /o/{org}/sessions with the pull request URL in resources for the ones that qualify, with a request_id, one UUID kept per head SHA, so a redelivered webhook returns the same run.

An accessibility review needs the app running at the right commit, a browser, axe, a keyboard and the patience to visit every state twice, once on the branch and once on the base. The agent has all of that in its own sandbox and does the comparison for every pull request, so the review distinguishes what this change broke from what was already broken, which a static lint rule cannot do.

The review lands on the pull request where the discussion already is, with reproductions a developer can follow in a minute, and the full axe output stays in accessibility.md for anyone who wants the raw rule results. Several pull requests can be reviewed at once, each in its own sandbox.

Does it add axe or an ESLint plugin to my repository?

How does it tell a regression from an existing problem?

Which states does it check?

What does it need to sign in?