Skip to main content

Accessibility Fix (AccessLint)

Fleet adaptation (read first)​

Imported from AccessLint (owner directive 2026-10-07) as the markdown audit method only. The executable layer is declined by owner direction (2026-10-07): the @accesslint/cli and @accesslint/chrome packages, the AccessLint MCP server, any browser-MCP wiring, and the hosted connector will not be adopted — no fleet code goes out to a third party. The method on this page is in use; local-only execution is under evaluation by the research service. Where the source text drives its own engine, this page's method — the tiers, evidence standards, checkpoints, and reporting formats — applies unchanged with whatever scanning and browser tooling the fleet has sanctioned. The shared methodology is in this skill's supporting files (shared/methodology.md) and is the authority for severity, evidence basis, and honesty conventions across all five AccessLint pages.

This skill remediates accessibility violations: baseline, edit, verify. It only fixes. To find what's wrong, use accesslint:accessibility-scan (one page, automated), accesslint:accessibility-inspect (one page, manual), or accesslint:accessibility-audit (whole site, WCAG-EM); to check for regressions, use accesslint:accessibility-diff. The engine runs here are internal to the loop — a baseline before and a check after — not a report.

Shared conventions (grounding, never invent content): the shared methodology in this skill's supporting files (docs/15-skills/_support/accesslint/accessibility-fix/shared/methodology.md).

For large remediations, run via Task for context isolation; the steps are the same.

Input​

  • A findings worklist (from accessibility-scan, accessibility-inspect, or accessibility-audit, or pasted): apply it directly; the baseline is already done.
  • A target (URL, config target name, files, or a directory): audit it first for the baseline, then fix.

Given neither, ask what to fix. Don't sweep a whole codebase unprompted.

Picking a flow (for baseline and verify)​

  1. Live-DOM audit for any URL: audit the rendered page in a debuggable browser session. Scope with a selector and wait for async content where needed. The live DOM catches what source can't.
  2. Source audit for raw HTML strings, files (read them first), or JSX rendered to a string.

For an authenticated session, have the user start a headed browser they control, sign in, then run the live-DOM audit against that session.

Steps​

  1. Baseline. Audit with format: "compact" and record the violation set (rule ID and selector for each). Skip this if you were handed a worklist.
  2. Apply. For each violation:
    • If a Source: line is present, open that file at that line. If several are listed (separated by ←), the first is the JSX literal and the rest are enclosing components; use Symbol to disambiguate.
    • If not, grep stable hooks (data-testid, id, aria-label), then visible text, then tree position.
    • Use the Fixability: and Fix: fields: apply mechanical fixes as given; leave a TODO with the rule ID for contextual or visual. Don't invent content (alt text, labels, link text).
    • Group edits to the same file into one operation.
    • Confirm scope before editing files outside the obvious target, or before more than about 10 mechanical fixes.
  3. Verify. Re-run the same audit and compare to the baseline: every targeted violation gone, no new ones. For a precise new/fixed/pre-existing comparison on a URL, use accesslint:accessibility-diff rather than checking by eye.

Source: lines come from React DevTools fibers and appear only in live-DOM audits against React dev builds. Static audits won't have them; fall back to selectors. When unsure about a rule, look up the rule's rationale before acting on it.

When to stop​

  • A violation with no Fix: directive: leave a TODO, don't guess.
  • Verification fails (a new violation appeared, or a targeted one remains): report it and stop. Don't iterate silently.

Output​

Per cycle: the flow used, violations by impact, what was applied (file and rule), what was deferred (TODOs and why), and the before and after counts.

Supporting files: this skill's supporting files are held in the docsite at docs/15-skills/_support/accesslint/accessibility-fix/ — fetch them fresh from jknash/docsite main alongside this page.

Source: AccessLint/skills · plugins/accesslint/skills/accessibility-fix/ @ 2e9d73366783 · view source · Imported 2026-10-07 under the owner's directive (public-repo content approved for internal fleet use; upstream asserts MIT in its README and plugin manifests, no LICENSE file ships). Method only — CLI, MCP server, and hosted connector excluded pending security review.