Title: Auditwright WCAG Accessibility Scanner Author: pragadees Published: August 5, 2026 Last modified: August 5, 2026 --- Search plugins ![](https://ps.w.org/auditwright-wcag-accessibility-scanner/assets/banner-772x250. png?rev=3635740) ![](https://ps.w.org/auditwright-wcag-accessibility-scanner/assets/icon-256x256. png?rev=3635740) # Auditwright WCAG Accessibility Scanner By [pragadees](https://profiles.wordpress.org/pragadees/) [Download](https://downloads.wordpress.org/plugin/auditwright-wcag-accessibility-scanner.0.6.0.zip) * [Details](https://wordpress.org/plugins/auditwright-wcag-accessibility-scanner/#description) * [Reviews](https://wordpress.org/plugins/auditwright-wcag-accessibility-scanner/#reviews) * [Installation](https://wordpress.org/plugins/auditwright-wcag-accessibility-scanner/#installation) * [Development](https://wordpress.org/plugins/auditwright-wcag-accessibility-scanner/#developers) [Support](https://wordpress.org/support/plugin/auditwright-wcag-accessibility-scanner/) ## Description Auditwright checks every published post and page against the Web Content Accessibility Guidelines (WCAG) 2.2, Level A and AA, and shows you the exact element that failed, the selector to find it, the success criteria it breaks, and a link to guidance on fixing it. **It is not an accessibility overlay.** It adds no widget, toolbar or button to your site and changes nothing for your visitors. It is a testing tool. #### It tests the page, not the source code Most WordPress accessibility scanners parse your page’s HTML on the server. That approach has no access to computed styles, so it cannot tell whether an element is actually visible. The result is a long list of “issues” inside hidden menus, closed accordions and inactive tabs that no visitor or screen reader will ever reach. Auditwright loads each page the way a visitor’s browser does and tests what actually rendered. Hidden content is excluded because it is genuinely hidden, so the issues you see are ones real people encounter. #### What it does * **Site-wide scan** of every published post and page * **WCAG 2.2 Level A and AA** using axe-core, the engine behind professional accessibility tooling * **Per-page detail** with the failing element, its selector, the criteria it breaks, and how to fix it * **Site-wide issues separated from content issues** — a rule failing on nearly every page comes from your theme, and is usually one fix rather than hundreds * **Needs manual review** — checks automated testing genuinely cannot decide, kept separate from failures * **Recommendations** — good practice such as heading order, kept separate from WCAG failures * **Effort estimates** — every issue tagged easy, medium or complex * **Copy prompt for AI** — one click copies a complete prompt describing the issue, ready to paste into an assistant * **Changed since the last scan** — what you fixed, what is new, what is still failing * **Set a finding aside**, either as not a real problem or as real but accepted for now, and it stays set aside through every future scan * **Accessibility statement**, written from your last scan rather than from a form, with the assessment method, the date, and the barriers still outstanding #### The accessibility statement Sites covered by the European Accessibility Act are expected to publish an accessibility statement. It has to name the standard, describe how the site was assessed, give the date of the most recent review, and list the barriers people will still run into. Every free generator for this is a form. You type the date, you type the method, you type the barriers, and the document is accurate for one day. Then the site changes and the statement quietly becomes a written claim nobody can support. Auditwright already knows the date, the method and the barriers, so it writes the statement from your scan instead, tells you when the scan behind the published statement has been superseded, and updates the page in one click. It will not print “fully conformant” off the back of an automated scan. That option only becomes available when nothing is outstanding **and** you have recorded what manual testing was actually done, because no automated tool can support that claim on its own. The statement is created as a draft. Auditwright never publishes a legal claim about your site for you. #### An honest note about automated testing No automated tool finds every accessibility problem. Automated testing catches a portion of WCAG failures; the rest need human judgement and testing with real assistive technology. This plugin will not make your site conformant on its own. It finds and documents what automated testing can detect. Treat it as the first and most repeatable step, not the last one. Any plugin promising guaranteed compliance from automated scanning alone is misleading you. #### Third-party libraries Auditwright bundles [axe-core](https://github.com/dequelabs/axe-core) by Deque Systems, under the Mozilla Public License 2.0. A copy of that licence is included in `assets/ vendor/axe-core-LICENSE.txt`. axe-core runs entirely in your own browser. No page content, scan result or site data is sent anywhere. #### Auditwright Pro A separate paid add-on adds a client-ready audit report organised by WCAG success criterion, report branding, scheduled scan reminders, and scanning of WooCommerce products and custom post types. It is not required, and everything described above stays free. ## Screenshots [⌊The dashboard. Severity counts cover content issues only, because one theme bug repeated on every page is one problem, not hundreds.⌉⌊The dashboard. Severity counts cover content issues only, because one theme bug repeated on every page is one problem, not hundreds.⌉[ The dashboard. Severity counts cover content issues only, because one theme bug repeated on every page is one problem, not hundreds. [⌊Findings automated testing could not decide, kept separate from failures, and good-practice recommendations kept out of the audit report.⌉⌊Findings automated testing could not decide, kept separate from failures, and good-practice recommendations kept out of the audit report.⌉[ Findings automated testing could not decide, kept separate from failures, and good- practice recommendations kept out of the audit report. [⌊Per-page detail: the failing element, its selector, the criteria it breaks, a paste-ready prompt for an AI assistant, and the two ways to set a finding aside.⌉⌊ Per-page detail: the failing element, its selector, the criteria it breaks, a paste- ready prompt for an AI assistant, and the two ways to set a finding aside.⌉[ Per-page detail: the failing element, its selector, the criteria it breaks, a paste- ready prompt for an AI assistant, and the two ways to set a finding aside. [⌊The accessibility statement, written from the last scan rather than from a form, with the assessment method, the date, and the barriers still outstanding.⌉⌊The accessibility statement, written from the last scan rather than from a form, with the assessment method, the date, and the barriers still outstanding.⌉[ The accessibility statement, written from the last scan rather than from a form, with the assessment method, the date, and the barriers still outstanding. ## Installation 1. Install through **Plugins Add New**, or upload the plugin to `/wp-content/plugins/`. 2. Activate it through the **Plugins** menu. 3. Go to **Accessibility** in the admin menu and click **Scan site**. ## FAQ ### Does the accessibility statement make my site compliant? No. It documents what was tested, when, and what is still wrong. That is a requirement in its own right, and it is honest, but writing a statement does not fix anything. The barriers listed in it are real and still need work. ### What happens when I set a finding aside? There are two ways to do it and they behave differently on purpose. “Not a real problem” removes the finding completely. It stops being counted, and it stays gone through future scans. “Real, accepted for now” also takes it out of your working list, but keeps it in the record as a known barrier, along with the reason you gave. An accessibility statement has to declare known barriers, and a document that quietly drops a real failure is worth nothing. Either way the decision is attached to the finding itself, not to one scan of it, so it survives every re-scan. You can put anything back at any time. ### Does this send my site’s content anywhere? No. Scanning runs entirely inside your own browser and results are stored in your own WordPress database. Nothing is transmitted to us or to any third party. ### Will this make my site compliant? No, and be sceptical of anything claiming it will. Auditwright finds and documents problems automated testing can detect. Fixing them is real work, and full conformance also needs manual testing with assistive technology. ### Is this an accessibility overlay? No. Overlays inject a script that tries to patch problems at page load. They are widely criticised by disabled users and accessibility practitioners, they do not fix the underlying code, and they produce no documentation. Auditwright changes nothing on your public site. ### Why does the scan open pages in the background? Because that is the only way to see a page as a visitor sees it, including styles from your theme and anything JavaScript added. It also means scanning works on ordinary shared hosting with no server-side browser required. ### Will it slow my site down? No. Nothing runs for your visitors. Scanning happens in the WordPress admin, when you ask for it. ### Do custom post types get scanned? Auditwright scans posts and pages. WooCommerce products and other custom post types are handled by the separate Pro add-on. ## Reviews There are no reviews for this plugin. ## Contributors & Developers “Auditwright WCAG Accessibility Scanner” is open source software. The following people have contributed to this plugin. Contributors * [ pragadees ](https://profiles.wordpress.org/pragadees/) [Translate “Auditwright WCAG Accessibility Scanner” into your language.](https://translate.wordpress.org/projects/wp-plugins/auditwright-wcag-accessibility-scanner) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/auditwright-wcag-accessibility-scanner/), check out the [SVN repository](https://plugins.svn.wordpress.org/auditwright-wcag-accessibility-scanner/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/auditwright-wcag-accessibility-scanner/) by [RSS](https://plugins.trac.wordpress.org/log/auditwright-wcag-accessibility-scanner/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 0.6.0 * Accessibility statement generated from the scan, not from a form * Warns when the published statement is behind the latest scan * Refuses to claim full conformance without manual testing recorded * Set a finding aside, as either “not a real problem” or “real, accepted for now” * Decisions are keyed to the finding, not the scan, so they survive every re-scan * Accepted failures stay in the record as known barriers rather than disappearing * Page counts, severity totals and effort estimates all follow what you set aside #### 0.5.0 * Recommendations: best-practice checks kept separate from WCAG failures * Needs manual review: findings automated testing cannot decide * Effort estimates on every issue * Copy prompt for AI * Changed since the last scan * Excluded logged-in-only admin chrome from scans, removing a class of false positive #### 0.4.0 * Site-wide issues separated from per-page content issues * Scan history #### 0.3.0 * Per-page issue detail view #### 0.2.0 * Site-wide scanning against WCAG 2.2 A and AA ## Meta * Version **0.6.0** * Last updated **11 hours ago** * Active installations **Fewer than 10** * WordPress version ** 6.5 or higher ** * Tested up to **7.0.2** * PHP version ** 7.4 or higher ** * Tags * [a11y](https://wordpress.org/plugins/tags/a11y/)[accessibility](https://wordpress.org/plugins/tags/accessibility/) [audit](https://wordpress.org/plugins/tags/audit/)[testing](https://wordpress.org/plugins/tags/testing/) [wcag](https://wordpress.org/plugins/tags/wcag/) * [Advanced View](https://wordpress.org/plugins/auditwright-wcag-accessibility-scanner/advanced/) ## Ratings No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/auditwright-wcag-accessibility-scanner/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/auditwright-wcag-accessibility-scanner/reviews/) ## Contributors * [ pragadees ](https://profiles.wordpress.org/pragadees/) ## Support Got something to say? Need help? [View support forum](https://wordpress.org/support/plugin/auditwright-wcag-accessibility-scanner/)