# Review Accessibility in Angular Pull Requests

An agent runs your Angular app, checks changed screens with axe and a keyboard, and returns accessibility findings tied to the pull request diff.

[Run this on Rush](https://cloud.getrush.ai/run/review-accessibility/angular/), in a Project that has your repository.

## What the agent does

The review starts by reading the pull request and mapping its changed templates to routes. In realworld-apps/angular-realworld-example-app, package.json:29–36 pins the Angular packages to "21.2.12", while package.json:8–14 defines "start": "ng serve", "test": "vitest" and Playwright scripts. The repository uses bun.lock, and README.md:17–24 tells contributors to run bun run setup before bun run start. That setup initializes the realworld submodule and installs dependencies; angular.json:35 imports its shared theme. A failed stylesheet load would make a contrast review misleading.

The agent follows src/app/app.routes.ts to identify the affected screens and any authentication requirements. Both /login and /register load src/app/core/auth/auth.component.ts, while settings and editor routes use requireAuth. The authentication component switches its title and adds a username control for registration; its HTML binds a formGroup, displays errors and disables controls during submission. A review of this shared template therefore exercises both modes, invalid submissions and the busy state, rather than assuming a screenshot of the sign-in page covers registration.

It starts the app with bun run start and uses the browser to inspect the changed screens. playwright.config.ts:14 names "http://localhost:4200" as the base URL. The agent runs axe against the rendered DOM and records the rule, target element and output, then follows the same user flow with Tab, Shift+Tab and keyboard activation. It checks focus visibility, accessible names, error handling and route transitions. It compares the base and head revisions in equivalent states so an existing placeholder-only field is not blamed on a new change.

The agent runs relevant existing checks, such as bun run build, bun run test --run and the appropriate Playwright flow, and keeps their actual output. Axe is an additional browser audit, not a dependency claimed to exist in package.json. If the app cannot start, a backend is unavailable or an authenticated page cannot be reached, the review states what was not tested. It comments on changed lines only when the new accessibility problem can be tied to the diff, and it does not rewrite templates during a review-only assignment.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Review the identified open pull request for accessibility; if the target PR is ambiguous, ask for its URL before reviewing. Inspect package.json, the lockfile, route definitions and changed Angular templates. Follow repository setup instructions, start the app, and exercise each changed screen in its relevant authentication, validation and loading states. Run axe in the browser and test keyboard focus and activation. Compare base and head so only newly introduced problems become findings. Comment on changed lines with the affected element, reproduction steps, applicable accessibility requirement, axe output where relevant and a concrete fix. Return accessibility.md and audit evidence with actual check output and untested paths. Do not edit source files or open another PR.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The result is a review on the existing pull request, accompanied by accessibility.md and the saved browser audit evidence. A finding names the Angular template and changed line, the route and UI state, what keyboard or assistive-technology behavior fails, and the smallest correction to investigate. Automated findings include their axe rule and target. Manual focus problems include reproduction steps rather than a fabricated automated violation.

Before merging, the author reproduces each finding and checks the proposed fix in both uses of any shared component. The report lists which commands ran and which screens remained inaccessible; a green unit suite does not substitute for a browser review. The session's answer and transcript provide the review record. This page specifies what the agent is asked to deliver and does not claim that an Angular accessibility audit has already passed.

## Run it on every Angular pull request update

Have your GitHub webhook handler send one session request for a new PR revision. Replace the example repository resource with the exact GitHub pull-request URL so Rush clones its branch, and include the base and head context in input. Use an Idempotency-Key tied to the review revision for retries. Your handler can read the finished session after its completion webhook and attach the report to the same review workflow.

## Why run it on Rush?

Angular accessibility review needs a running router, loaded styles and the right form state, not just a template search. Rush gives the agent its own sandbox to initialize the submodule, install dependencies and run the app without disturbing your local branch. A reviewer can inspect real browser evidence while continuing other work, rather than borrowing an author's development server and hoping its checkout matches the PR.

The captured commands show whether a report came from a running application or stopped at setup. Independent PRs can be reviewed in separate runs within your concurrency limits, each with its own audit files. The result stays tied to the changed line and rendered behavior, which is more useful for a merge decision than a general checklist of accessibility advice.

## Frequently asked questions

### Will this report accessibility problems that already existed?

The request asks for a base-versus-head comparison and new violations only. Existing problems can be mentioned as context, but they should not become regression comments on unrelated changed lines. The report must explain when a new route or state makes an existing component behave differently.

### Does passing Vitest prove the forms are accessible?

No. The fixture's test script runs Vitest, while the accessibility assignment also inspects the rendered application. Keyboard focus, visible errors and route transitions need browser evidence beyond a passing unit command.

### Can the agent test authenticated Angular routes?

It needs an approved test account and a reachable test backend for those flows. The fixture protects settings and editor routes with requireAuth. If access is unavailable, the report names the untested routes rather than claiming full coverage.

### Will it submit a fix pull request?

This task reviews the existing PR and leaves source files unchanged. It returns concrete fixes as review suggestions. A code change requires a separate explicit instruction after you have reviewed the findings.