=== Build with Accessibility ===
Tags: accessibility, axe-core, wcag, gutenberg, alt text
Requires at least: 6.6
Tested up to: 7.1
Requires PHP: 8.0
Stable tag: 0.7.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Free, local accessibility monitoring, axe-core scans, manual review records, and guided repairs. Manual testing is still required.

== Description ==

Build with Accessibility helps you monitor detectable accessibility barriers and review changes in WordPress. It does not make a website fully accessible or compliant, and a passing scan is not a certification.

If your website has already been evaluated and made accessible, repeat scans after changes can help catch detectable regressions. They cannot guarantee that it stays accessible. Establish a manual testing baseline and continue keyboard, screen-reader, zoom, content, and interaction testing, including after significant changes. Involve disabled users in evaluating real tasks where possible. The eight guided manual checks are a starting point, not a complete WCAG audit.

Open Accessibility in WordPress administration to scan rendered pages and manage findings. The workspace includes Overview, Pages, Pages to recheck, Issues, Manual checks, Repair history, Reports, and Settings.

The bundled axe-core 4.14.0 engine runs locally in your browser. Use all enabled axe rules or the WCAG 2.2 A/AA profile. Scan individual pages, selected pages, or the available content inventory. The browser queue supports pause and resume. Keep the admin tab open while scanning.

Inspect affected elements, severity, HTML snippets, rule tags, and guidance. Record review decisions with reasons. Use eight starter guides for manual testing. Save separate sessions for each page state, with step outcomes, observations, tester, browser/device, assistive technology, review dates and history. Repeat a review without overwriting earlier evidence. Export the complete retained manual history for a page as standalone HTML, JSON or CSV. Export findings to CSV, download stored JSON reports, and print or save a report as PDF using your browser.

Each finding includes a four-step repair guide: locate the element, identify its owning source, make a focused change, and save/recheck/test. A private read-only preview highlights a uniquely matched top-level element at the recorded scan viewport. Ambiguous, changed, hidden, missing or incomplete evidence is explained instead of highlighting a substitute. Findings inside embedded frames or shadow roots retain manual guidance. Preview controls stay in the admin panel; the preview cannot be used to submit a form or place an order.

Guides cover Gutenberg, Elementor, WooCommerce, Contact Form 7 and WPForms Lite. Detected form and Elementor document links require the owning tool's edit permission. Source context is a clue, not proof of ownership. Built-in repair/recheck/undo stays limited to supported native content; generated content is edited in its own tool. Inspections expire after five minutes and do not resolve findings, certify accessibility or replace a new scan and manual testing.

Content review prompts flag filename-like image alternatives and common generic English link wording in visible top-level content. They are separate from axe failures and baseline counts, and are not WCAG determinations. Review meaning and context before making changes; other languages, embedded frames and shadow roots still need manual review. Safely mapped native prompts can open the existing guarded repairs.

Issues can group matching rule, result type, impact, selector and recorded HTML across pages. Each page keeps its own freshness and review decision. Matching evidence suggests repetition, not proven shared ownership. Filter to 2,000 findings or fewer for grouping; individual findings and CSV exports remain available without a paid tier. Rescan every affected page after a shared change.

Choose a completed scan as a baseline in Reports, with a note describing the reference and known limitations. Later compatible scans show newly detected, changed, still detected, no-longer-detected, and unverified findings with before/after evidence. Keep separate references per page, rule profile, and viewport. A baseline is not an accessibility approval. Failed scans have no comparison counts; incomplete results and missing frame coverage cannot imply cleared findings.

Pages to recheck lists content changes, tracked site configuration changes, failed attempts, missing scan context, and unavailable frames. Search, filter, and queue listed or selected pages. Manual-review tasks also appear when recorded steps are untested, blocked, have an issue, become stale, or reach their review date. Automated scans cannot clear manual tasks. Dates use the current site timezone; no email or background reminders are sent. Scan-selected/listed actions queue only pages needing automated checks. The inbox reads saved records when opened or refreshed, in bounded inventory batches. Continue with Check more pages on larger sites. An empty inbox does not establish accessibility or compliance.

Mapped native Image block findings can open the Gutenberg repair flow. Review the image's purpose, save an alternative for that placement, recheck the saved output, and undo while the repaired source still matches. Heading, link-name, and form-label findings in supported static content open guided admin repairs. Preview, save, recheck the rendered element, and undo while the source still matches. Pages → Repair content also lets you review these elements before scanning.

Every shipped feature is free. No account, API key, scan credits, required paid service, or telemetry. The plugin is independent of the Accessibility.build website. Normal visitor pages load no scanner or overlay.

== Scope and privacy ==

The administration workspace requires manage_options. All repairs use per-post editing permissions. Findings, reports and guided manual sessions are stored in local database tables. Sessions include tester identity, scope, testing environment, observations, reference text, dates and guide snapshots. Earlier checklist notes and repairs use local options/private post metadata. References are text only; files are not uploaded or fetched. Queues are saved in this browser for this site and user. Only explicit, authenticated, expiring diagnostic URLs load axe-core.

Scans represent rendered signed-in pages or saved previews, at one viewport and state. Hidden interactions, anonymous caches, inaccessible frames, and human meaning need further review. Automated findings do not establish accessibility or legal conformance. Experimental and disabled-by-default axe rules are not force-enabled.

Repair receipts store the affected block before and after the change, including static values already in that source. Reports contain page snippets and selectors. Filled input/textarea values are removed from snippets. The initial report limit is 4 MiB and 6,000 finding occurrences; oversized results are rejected without a partial pass. Retention keeps 1–10 unpinned completed reports and the latest failed attempt per target, plus pinned baseline reports. Baseline snapshots and notes remain in a local database table until deliberately replaced/removed or their post is permanently deleted.

Manual history is retained separately from scan retention. Earlier checklist notes are read-only and can be explicitly followed up with a guided session. Only recorded reviews create manual tasks; an empty list does not mean every manual check was performed. A dedicated history cleanup interface is not included yet.

Deactivation and uninstall preserve local records and saved content repairs. Permanently deleting a post removes its audits, manual sessions and WordPress metadata. The plugin never changes shared Media Library alternative text through an image repair.

== Installation ==

1. Upload and activate the plugin ZIP. To update an earlier ZIP, use WordPress's replacement option.
2. Open Accessibility in WordPress administration.
3. Choose Pages and run a scan. Keep the tab open while the queue works.
4. Review Issues, Manual checks, and Reports.
5. Choose Pages → Repair content for headings, text links, and Custom HTML form labels.
6. For image repairs, open Build with Accessibility in the Gutenberg toolbar or Options menu.

== Compatibility and caching ==

Full-page axe scans inspect rendered pages, including theme and builder output. Native repairs support the documented static WordPress blocks. Elementor, Beaver Builder, SiteOrigin and Brizy pages must be edited in their own builder; the admin panel explains this and protects their content. Spectra, Kadence Blocks and GenerateBlocks can coexist with supported native blocks, but their own blocks are not automatically rewritten.

Builder metadata changes and supported shared templates make recorded checks stale. Tracking does not cover every custom field, external stylesheet, add-on or interactive state. Rescan after other changes and repeat the relevant manual checks.

Scans run as the signed-in administrator in a private, uncached diagnostic preview. A cache or CDN can serve visitors different or older HTML. After saving a repair, allow the cache to refresh or purge the affected page using your cache plugin, then check the signed-out page separately. W3 Total Cache's stale-cache grace period can briefly preserve old output after a save. The plugin does not certify cached anonymous output. LiteSpeed server page caching requires a supported LiteSpeed server; optimization on Apache is separate.

== Store and generated-form journeys ==

WooCommerce, Contact Form 7 and WPForms Lite output can be scanned. Edit their generated fields and store content in the owning plugin; native repairs do not rewrite generated checkout fields, form definitions or WooCommerce block trees. Pages, reports and repair/manual panels include journey guidance for recognized store pages and form embeds.

Shared Contact Form 7 and WPForms definition changes conservatively make recorded site evidence stale. Allowlisted product/variation, core checkout, shipping, tax, currency and payment-method settings invalidate recognized store-page evidence. Terms/privacy page changes also require a new store review. Unrelated static pages are not invalidated by catalog changes. Private orders, customers, submissions and payment tokens are not read for freshness tracking. Custom extensions, remote changes and every store setting are outside this tracking scope.

A scan does not add products, submit forms, place orders or test payment/delivery. An empty-cart checkout diagnostic explains how to prepare the signed-in browser's cart. Use a staging store and an offline/test payment method, and record the exact cart, customer, shipping, validation and confirmation states in Manual checks. Compare scans in the same state: cart/session contents are not fingerprinted. Test signed-out and customer journeys, errors and recovery, consent, confirmation and delivery separately. A successful functional test does not mean those journeys are accessible.

== Frequently Asked Questions ==

= Is any feature paid or connected to a cloud service? =
No. All implemented features are free and local. WordPress, your browser, and this site's database do the work.

= Does full axe-core coverage mean full accessibility conformance? =
No. The engine runs its enabled automated checks. Zero automated findings does not mean an accessible or compliant website. Manual keyboard, screen-reader, zoom, content, and interaction testing remain necessary, including when every automated check passes.

= Can this keep an already accessible website accessible? =
It can support maintenance by helping you recheck pages after changes, identify detectable barriers, and keep repair and manual review evidence. It cannot guarantee continued accessibility. Scans are started by a person and run while the admin tab stays open; this release has no unattended background monitor. Schedule your own repeat testing and review the complete user journeys affected by a change.

= Can it repair every finding automatically? =
This release repairs native Image and Heading blocks, plain-text links in supported static blocks, and explicit labels for controls in Custom HTML forms. Shared or bound content, rich links, wrapping labels, duplicate IDs, and plugin-generated forms need their owning editor. Other rule families include findings and guidance. A repair is a reviewed content change, not an accessibility certification.

= Can scanning run after I close the browser? =
No. The pending queue is saved locally and can be resumed. There is no hosted browser farm or unattended WordPress-cron scanner.

= What can a baseline comparison tell me? =
It compares matching rules and element selectors in two saved scans, using compatible engine, rule coverage, browser, user, scope, viewport, and wait settings. No longer detected does not mean a verified fix. Renamed or moved elements can appear as new and absent findings, so review their evidence. Older reports without comparison context remain readable but need a new scan before selecting a baseline. This release does not infer recurring issue history across removed reports.

= Does the changed-pages inbox detect every change? =
No. It tracks saved content, publishing details, and selected site configuration, and uses the current scan settings. It cannot observe every remote stylesheet, cache, arbitrary plugin setting, or interactive state. Refresh after changes, keep manual testing, and rescan when changes occur outside that boundary.

= How do manual sessions and review dates work? =
Choose a guide and page state in Manual checks. Record step outcomes and observations, then save a session. Repeat this review adds another entry without copying earlier results. Review dates become due on that calendar day in the current site timezone and are evaluated on open or refresh. Passing an automated scan cannot complete a manual review. Sessions cover only the recorded steps and context; these guides are not a complete WCAG audit.

= What happens to earlier manual notes? =
They remain readable and are included in exports. Follow up this earlier note explicitly connects a new guided review. The older manual-note POST API returns 410 with guidance to use sessions; read access is preserved.

== Third-party software ==

axe-core 4.14.0 by Deque Systems is bundled under MPL-2.0. Its readable source, license, and third-party notices are included in assets/vendor/. Our source and build instructions are included in development/.

== Changelog ==

= 0.7.0 =
* Adds a private read-only element preview with inline highlighting, unique-selector and recorded-evidence checks, and explicit missing/changed/hidden/unsupported-state messages.
* Adds four-step repair guidance for Gutenberg, Elementor, WooCommerce, Contact Form 7 and WPForms Lite, with checked source-editor links, rescan and manual-testing actions.
* Highlighting does not change content, resolve findings or replace manual testing. Embedded frame/shadow-root findings retain manual guidance.


= 0.6.0 =
* Added local filename-alternative and generic English link review prompts, kept separate from axe failures and baseline counts. Human judgment remains required.
* Added filtered grouping of identical rule, selector and HTML evidence across pages, with each page's freshness and decisions preserved.
* Benchmarked official free plugin releases on shared Gutenberg, Elementor, WooCommerce and form fixtures. See the source project's BENCHMARK.md for measured scope and limitations.


= 0.5.4 =
* Keep repair-history freshness consistent with rendered rechecks after store context changes.
* Track shared Contact Form 7 and WPForms definition changes, plus supported WooCommerce product, catalog, checkout, shipping and tax changes, so earlier scan and manual evidence needs review.
* Add form and store journey guidance to Pages, content repairs and Manual checks. Generated fields stay in their owning plugin; validation, consent, checkout, confirmation and delivery require separate testing.
* Explain an empty-cart checkout scan immediately without changing the normal visitor redirect or submitting an order.
* Exclude WooCommerce-generated block trees from native image repair and scan mappings.
* Add repeatable local checkout and form journeys using official free products, offline test orders and an intercepted email sink. All features remain free and local.

= 0.5.3 =
* Track published Elementor, Beaver Builder, SiteOrigin and Brizy content changes, page-template changes and supported shared builder templates in scan freshness and manual-review tasks.
* Invalidate repair rechecks when tracked page-template, builder-source or theme settings change, including image repairs. Older evidence without this context needs a new recheck.
* Protect builder-owned content from native repairs, stale save operations, rechecks and undo; explain the owning editor in the admin repair panel.
* Keep authenticated scan and recheck previews out of supported cache and script optimizers, including Autoptimize's early buffering.
* Explain expired or changed scan previews immediately so users can retry.
* Add a reproducible compatibility lab with official free themes, builders and caching plugins. See compatibility guidance below; this is not a claim about every configuration.



= 0.5.2 =
* Preserve keyboard focus after scanning, pausing, rechecking repairs, and changing results or manual-history pages.
* Keep image-review focus inside Gutenberg's repair sidebar across browser rendering differences.
* Make overflowing admin tables named, keyboard-scrollable regions with visible focus.
* Add repeatable Firefox and WebKit browser coverage and keyboard workflow checks. All features remain free and local.

= 0.5.1 =
* Added bounded request-local caching without reusing freshness-sensitive evidence across requests.
* Preserved live conflict checks and invalidated cached views after evidence/receipt changes.
* Corrected prepared-query argument handling and checked failed review-decision writes.
* Documented necessary direct database operations individually for directory review.

= 0.5.0 =
* Added eight versioned manual testing guides with step outcomes, observations and testing context.
* Added preserved session history, independent page-state reviews and guarded repeat sessions.
* Added review dates and manual-review tasks that automated scans cannot clear.
* Added full page-scoped manual history exports in HTML, JSON and CSV.
* Preserved earlier checklist notes, with explicit guided follow-up and read-only legacy access.
* Added site-local session storage with permission, source-change, concurrent-save and duplicate-save guards.

= 0.4.0 =
* Added pinned baseline snapshots per page, rule profile, and viewport, protected from normal history cleanup.
* Added conservative scan comparisons with before/after evidence and explicit incompatible or uncertain states.
* Added a searchable Pages to recheck inbox with reasons, bounded inventory batches, and selected/listed scan queues.
* Added guarded baseline replacement/removal and explicit monitoring, matching, storage, and manual-testing limits.

= 0.3.1 =
* Clarified monitoring scope and the requirement for continued manual testing.
* Added assessment limitations to the dashboard, repair guidance, printed reports, JSON, and CSV exports.
* Improved WordPress directory preparation and documented remaining release checks.

= 0.3.0 =
* Added guided heading, link, and Custom HTML form-label repairs in the admin panel.
* Added before/after previews, native guarded saves, rendered axe rechecks, and source-aware undo.
* Connected supported scan findings to matching repair forms and unified repair history.
* Added explicit source boundaries, label association guards, and stale recheck handling.

= 0.2.0 =
* Added the complete admin workspace and local axe-core rendered-page scanner.
* Added page inventory, resumable queues, issue filters, review decisions, and source freshness checks.
* Added manual reviews, scan history, CSV/JSON exports, printable reports, and settings.
* Connected native image/image-link findings to the guarded Gutenberg repair workflow.

= 0.1.0 =
* Native Image block review, guarded save, authorized browser recheck, and source-aware undo.
