Accessibility Fix Queue

The problem

Most accessibility problems on a WordPress site come from the content people write: an image with no alt text, a link that says click here, a heading that jumps from level 2 to level 4, a button with no label. Checkers list them, and then someone has to open every post and fix them by hand. Overlays and render-time rewriting leave the stored content as it was and add a layer between your site and your visitors.

How it works

Accessibility Fix Queue works on the saved content itself, and nothing changes until a person approves it.

• Find. A background scan reads posts, pages, synced patterns, templates, template parts, navigation and WooCommerce product descriptions, and re-checks a post when it is saved. Issues are grouped by post, rule and WCAG 2.2 success criterion.
• Propose. Each fixable issue gets a concrete change at the source. Some are deterministic, such as copying the Media Library alt text, setting the next heading level, removing autoplay or picking the nearest palette colour with enough contrast. Text that needs judgement can be written by you or drafted by your own AI provider through the WordPress AI Client.
• Approve. The Queue shows the exact before-and-after diff of the block markup. Approve, edit and approve, or reject, one by one or per rule group.
• Apply and roll back. An approved fix is saved through the normal WordPress save, so revisions run. A byte-exact snapshot is stored first, and one click restores it.
• Report. A white-label progress report and CSV exports record what was checked, what changed, who approved it and what remains.

Built for safe changes

• If a post was edited after a fix was proposed, the fix is marked stale and nothing is written.
• Each proposed change is checked with the block editor’s own parser before it can be approved.
• After saving, the stored content is compared with what was intended; a mismatch restores the snapshot.
• Every proposal, decision, apply and rollback goes into an append-only audit log.

What it is not

No widget, no overlay, no front-end script. Fixes live in your content and stay if you remove the plugin. It supports your WCAG 2.2 AA work and does not replace manual testing: automated checks find only part of the accessibility issues on a site, and the report never states that a site conforms to a standard or law.

Your AI, your key

AI proposals are optional. They use the provider you connect under Settings > Connectors, with per-run and per-day caps. The plugin stores no key, sells no credits and sends no telemetry. Outside agents can read issues and queue proposals through the MCP Adapter, but only a person can approve, apply or roll back.