Everything DigitalPlugs ADA Compliance checks, fixes, and reports on.

Install & Activate

Install DigitalPlugs ADA Compliance (the free plugin) the way you'd install any WordPress plugin — search for it under Plugins → Add New, or upload the zip, then activate it. It starts scanning immediately; no account or setup step required.

Pro is a separate plugin that extends the free one, so the free plugin has to be installed and active first. Once Pro is active, go to ADA Compliance → License and paste in the key from your purchase receipt or your account at digital-plugs.com. If you're testing on a local or staging domain (anything ending in .test, .local, or a staging. subdomain), activation is recognized automatically and doesn't use up one of your licensed sites.

Your First Scan

You don't have to start a scan manually. The moment you publish or update a post or page, it's checked automatically — that's what powers the panels described below. To see everything already on your site before you've touched it, go to ADA Compliance → Dashboard and click Start Scan. It works through your published posts and pages in the background and the Issue Summary fills in as it goes.

Real-time scanning on save can be turned off under Settings if you'd rather only scan on demand.

Your Score & WCAG Level

The ring on the Dashboard is the percentage of your scanned posts and pages that currently have zero open issues — not a percentage of individual checks passed. The WCAG level badge next to it (A, AA, or AAA, or "does not yet meet Level A") is the highest level where nothing site-wide is failing at that level or any level below it — WCAG conformance requires every lower level to be clean first, so a single Level A failure anywhere caps the whole site at "not yet Level A" even if everything else is spotless.

Inside the editor panels you'll see a different, smaller number: Checks Passed, the percentage of the 57 rules with no open issue on that one specific post. It's deliberately not called a "score" anywhere in the editor, so it's never confused with the Dashboard's site-wide one.

Scanning While You Edit

Wherever you write content, there's a live accessibility panel for that post specifically:

• Classic Editor — an "Accessibility" box appears below the content editor, with a Recheck button and a "View Accessibility Report" link back to the Dashboard.
• Block editor — an Accessibility panel lives in the document sidebar (the icon next to Preview/Publish); it fetches this post's issues over the REST API and can recheck without a full save.
• Elementor — see the next section; it works the same way but adds markers directly on the canvas.

All three show the same thing: how many Warnings and Alerts are open, a Checks Passed percentage, and each issue with its WCAG citation, level, and a plain-English "How to fix" explanation.

Editing With Elementor PRO

Open the Accessibility panel from the floating button in the Elementor editor and, alongside the same issue list described above, every issue that has a matching element gets a numbered marker placed directly on the live preview. Click a marker to jump to and highlight its row in the panel; click a row to scroll the preview to that element and flash a highlight box around it.

Markers work by scanning the preview iframe's actual current HTML each time you open the panel or hit Recheck — not a cached location from an earlier scan — so they stay accurate even though Elementor rebuilds its preview constantly. That also means markers reflect the page as of your last recheck, not edits you've made since; hit Recheck after a round of changes to bring them back in sync.

Rechecking a Page

Every editor panel has a Recheck button that rescans just that one post without a full page reload. On the Dashboard, each row in the Issues table has its own Recheck action for when the page might have changed since the last full scan.

Ignoring an Issue

If a flagged issue is a deliberate choice rather than a mistake, use the Ignore action on its row in the Dashboard's Issues table. Ignored issues move to the "Ignored" view (switch to it from the View dropdown above the table) and stop counting toward your score, but stay visible so the decision is never silently lost.

Choosing a Compliance Standard

Under ADA Compliance → Settings, pick which standard every scan, citation, and the Guidelines Reference page is framed around: WCAG 2.2 Level AA, Section 508, or the European Accessibility Act (EAA). Rules that only apply under a standard you're not using are skipped by scans and hidden from the reference list, so the plugin only ever shows you checks that are actually relevant to what you picked.

There's also an optional toggle for Focus Appearance (WCAG 2.4.13), a Level AAA criterion stricter than any of the three standards above requires — off by default, since it's a stricter bar than what you're being held to, not something every site needs.

Full-Site Scanning PRO

The free plugin scans posts and pages. Pro's full-site scan additionally covers widgets, menus, theme templates, taxonomy terms, shortcode output, and your active theme's own CSS — plus, where applicable, Elementor Floating Elements and saved templates, WooCommerce products, EDD downloads, and any custom listing post type your site registers. Start it from the Dashboard's Full Site Scan button, or on a schedule (see below).

The Front-End Checker PRO

An "Accessibility Checker" toggle appears in the admin bar (and as a floating button) on the live front end, visible only to logged-in staff with permission. Turn it on and every issue on that exact page gets a numbered marker, plus a panel with the page's score, WCAG level, and a Warnings/Alerts breakdown. Click a marker for its fix and citation, tab through every marker in reading order with the keyboard alone, or use Disable Styles to check your raw reading order without any CSS.

Visitor Accessibility Toolbar PRO

A separate, optional feature from the checker above: a small floating widget your site's actual visitors can use to adjust text size, contrast, link underlining, and focus visibility. Preferences are stored in their own browser only — nothing is sent to your server. Turn it on under Settings.

Screen Reader Simulator

Inside the front-end checker's issue popup, a speaker button reads that element's accessible name and description aloud using your browser's own built-in text-to-speech. It's a fast way to hear what assistive technology would announce without switching to a dedicated screen reader — nothing is recorded or sent anywhere.

Scheduled Scans & Email Digests PRO

Under Settings, set a scan frequency (off by default) to run the full-site scan automatically in the background on a schedule. Add one or more digest recipients — the site admin email always receives it too — and you'll get an email only when a scan finds a new warning-severity issue, not a notification for every routine scan.

Free vs. Pro Site Counts

The free plugin has no site limit at all. Pro is licensed by how many sites one key covers — Professional (1 site), Small Business (5 sites), and Agency (25 sites) — and every tier unlocks the exact same set of features. The only thing that changes between them is how many sites your license activates on, so pick based on how many sites you manage, not which features you think you need.

If Scanning Isn't Working

• Check Settings → Post types to scan actually includes the content type you're editing.
• Check real-time scanning is switched on, if you're expecting it to fire on save.
• For the front-end checker or visitor toolbar not appearing: confirm your Pro license shows Active, and that your user role has the relevant permission under Settings → Permissions.
• For Elementor markers that seem stale: they reflect your last recheck, not unsaved edits — click Recheck after making changes.

Adding a Custom Rule

Every check is a small class extending DPWPADAC_Rule, registered through the dpwpadac_register_rules filter. This is exactly how every one of the 57 built-in checks is registered — there's no separate "custom rule" API, just the same one the plugin uses for itself.

class My_Custom_Rule extends DPWPADAC_Rule {

	public function get_id() {
		return 'my-custom-rule';
	}

	public function get_severity() {
		return 'warning'; // or 'alert'
	}

	public function get_wcag_ref() {
		return '1.1.1';
	}

	public function get_help_text() {
		return __( 'Plain-English fix instructions.', 'my-textdomain' );
	}

	public function check( DOMXPath $xpath ) {
		$issues = [];
		foreach ( $xpath->query( '//div[@data-broken]' ) as $node ) {
			$issues[] = new DPWPADAC_Issue(
				$this->get_id(),
				$this->get_severity(),
				$node->getNodePath(),
				__( 'Description of what is wrong.', 'my-textdomain' ),
				$this->get_wcag_ref()
			);
		}
		return $issues;
	}
}

add_filter( 'dpwpadac_register_rules', function ( $rules ) {
	$rules[] = 'My_Custom_Rule';
	return $rules;
} );

Overriding fix( DOMNode $node ) as well makes your rule eligible for the auto-fix engine automatically — the plugin discovers auto-fixable rules by checking which ones override that method, not from a separate list you'd have to keep in sync.

Filters & Actions

REST API

Everything lives under the dpwpadac/v1 namespace. The routes below are split by what they're for — the first group is what the editor panels themselves call, scoped to a capability check on that one post; the second is Pro's headless/CI-facing group, authenticated separately.

The first group authenticates like any other WordPress REST route (a logged-in session with edit rights on that specific post). Pro's headless group additionally accepts a bearer token equal to your site's own activated license key — the same credential a CI pipeline would already hold to run the WP-CLI commands below, so it doesn't need a separate application password just to poll a status.

curl -H "Authorization: Bearer YOUR_LICENSE_KEY" \
  https://yoursite.com/wp-json/dpwpadac/v1/site-summary

WP-CLI

All three commands run synchronously in the CLI process itself — no waiting on a WP-Cron batch chain — so they're safe to call from a CI pipeline with a normal exit code.

# Posts and pages only
wp ada-compliance scan --format=json

# Posts, pages, widgets, menus, templates, terms, shortcodes and theme CSS (Pro)
wp ada-compliance scan --full

wp ada-compliance report --format=vpat --file=/tmp/vpat.pdf
wp ada-compliance report --format=excel --file=/tmp/issues.xlsx

wp ada-compliance list-issues --status=open --severity=warning --format=json

Does passing every check mean my site is legally compliant?

No, and we won't tell you otherwise. Automated scanning — ours or anyone else's — can only catch what's mechanically detectable. Things like whether alt text is actually accurate, whether a keyboard flow genuinely makes sense, or whether a PDF is readable, still need a human to check. Treat a clean scan as a strong, evidenced starting point, not a certificate. The VPAT/ACR report says this explicitly, in writing, on the report itself.

Does the visitor accessibility toolbar make my site compliant on its own?

No. It can genuinely help some visitors adjust the page to their needs, but it doesn't change your site's actual markup, and toolbar-only "solutions" are explicitly not considered sufficient by most accessibility guidance. Use it as a nice-to-have on top of actually fixing issues, never instead of it.

What happens if my Pro license expires?

Every check the free plugin runs keeps running — scanning never stops. You lose access to auto-fix, exports, scheduled scans, the front-end checker and visitor toolbar, and updates/support, until it's renewed.

Will testing on a staging copy of my site use up an activation?

No. Local and staging domains (localhost, .test, .local, any staging. subdomain) are recognized automatically and skip the remote activation call entirely, so cloning your site for testing never costs you a licensed site slot.