Accessibility Test

Automated checks for single URLs or batch runs across many pages.

On the Free plan, the Dashboard shows test coverage without batch status. Automatic redirects, background tests, and schedules are available from Basic. The test sections are named “Test one page” and “Test multiple pages”.

Built-in banner suppression includes integrations for Borlabs Cookie 2.x and 3.x; see the cookie banner versions section for tested versions and required EZZE fixes. It applies only to test requests with a valid test key; banner settings for ordinary visitors remain unchanged. Previously saved screenshots are not modified: run a new test after a fix. Result dates and times follow the relevant display formatting; the time format comes from WordPress under Settings → General (for example, H:i for a 24-hour clock).

Before the first test: activate cloud features

The Accessibility Test runs through the EZZE cloud service. Until the free cloud connection is active, the test page therefore shows a complete activation card instead of a startable test form. The page title and Help remain available; the Help sheet distinguishes Free and paid plans and explains the relevant scope and limits, available test types, result interpretation, common start problems, cloud processing, and the URL allowance. Test navigation and settings appear only after activation and cannot be opened first through a direct tab link. Open Cloud Features activation opens the Cloud Features panel in the Dashboard, where you start the free Freemius activation. No license key or payment details are required. During first-time activation, the sidebar and empty result list are hidden so activation remains the clear next step. Existing saved test results remain visible. If email confirmation is still pending, you can continue activation or resend the email.

What it does

The Accessibility Test runs a browser-based accessibility analysis (including axe-style rules) similar to common developer tools. Results are broken down with severity and remediation hints.

Why use it

• Automation: Catches a subset of issues (often cited as ~30–40% of WCAG failures that are machine-detectable)
• Monitoring: Re-testing shows trends
• Triage: Surfaces frequent or severe findings first
• Record-keeping: History supports documentation of effort
• Release QA: Run before or after publishing

Limits

• Re-tests per URL: Unlimited on all plans (same URL can be re-run freely)
• Distinct URLs per month:

Important: Each normalized URL counts once per month toward that cap, even if you test it many times. Desktop and mobile produce separate test results but do not consume a second URL allowance for the same URL. Differences limited to protocol, host casing, default ports, a trailing slash, or tracking-only parameters do not create another entry; semantically relevant query parameters remain distinct.

Cookie banners, bots, and the viewport screenshot

Viewport screenshots are enabled by default for new settings, including the Free plan. You can turn them off at any time; a previously saved opt-out is preserved during updates. This does not replace the required cloud activation or automatically start a test.

If you enable the optional viewport screenshot in Accessibility Test settings, its capture path depends on the plan. On Free, the compact preview comes from the same PageSpeed run as the score and checks; the run also completes the extra performance work required for the image and may therefore take a little longer. From Basic upward, the plugin submits a separate high-resolution screenshot job to the EZZE proxy immediately after saving the result. The result does not wait for it: the image position shows a loading state while the separate queue works, and the finished capture is then stored with the result.

The Free preview belongs to the exact evaluated run. The high-resolution capture from Basic upward is technically a separate page load immediately afterwards, so it can differ if the page changes during that short interval. The queue retries transient failures a bounded number of times and terminates every job within 15 minutes. If capture still fails, the image area shows Screenshot could not be created. The action below changes to Retest content and starts a new Accessibility Test. A finished or expired screenshot job is not resumed at an arbitrary later time.

The plugin cannot accept a consent dialog or pre-set cookies — only your site configuration and consent stack control what the automated run sees.

• Screenshot: A consent overlay may still appear in the thumbnail even when your CMP enables options such as cookies for bots/crawlers. Common causes: user-agent handling does not classify the automated cloud measurement client the way you expect, another layer shows a banner (theme, tag manager, extra scripts, CMP version), or capture timing still intersects the overlay.
• Audits / score: A cookie or consent overlay can materially change results: while banners or modals block or cover content, large parts of the page may be unreachable for automated checks, so not every element is actually tested. Individual audits and the accessibility score can therefore differ a lot from what you would see after a visitor accepts cookies—and not only in the thumbnail.
• Practical next steps: Review your consent vendor docs (bots/crawlers, measurement tools, documented preview/query URLs). Developers may use the ezzewcag_accessibility_test_cloud_url WordPress filter to append vendor-documented query parameters for the cloud test URL only.

Note: Technical mitigations are not a substitute for your own privacy/compliance review. If you rely on bot/crawler exceptions, confirm with the vendor whether cloud Accessibility Test measurement traffic is included.

Cookie banner bypass (Accessibility Test settings)

In Accessibility Test settings you can turn on Cookie banners in tests. The plugin then adds a hidden key to the URL used for the cloud run only. Your site can recognize that single request and hide the cookie banner for automated testing. Normal page views remain unchanged, but the cookie banner itself is not tested while the bypass is enabled.

Supported services and troubleshooting can be expanded directly in the setting. Under Technical settings, you can view the current key. Generate a new key only if the current one may have become known.

For valid test requests, the plugin automatically sends no-cache headers and sets the WordPress DONOTCACHEPAGE signal. This protects page caches that allow the request to reach WordPress. Only when an upstream cache or CDN completely ignores URL parameters do you need to exclude requests containing ezzewcag_cmp from that cache. Regular visitors do not need to open the test link for this edge case to matter.

Cookie banner versions and support boundaries

Evidence date: 11 September 2026. This covers suppression during the Accessibility Test, not general compatibility or the vendor’s maintenance policy. Suppression is available in the Free plan too; a paid plan does not resolve an incompatible banner version.

Cookie banner / version	Integration and evidence
Borlabs Cookie 2.x	Dedicated integration for the older frontend structure; 2.2.34 successfully verified on a real installation with the EZZE fix and a new result screenshot. This does not establish testing of every 2.x version.
Borlabs Cookie 3.x	Separate integration using the 3.x interfaces. The 2.2.34 verification does not establish verification of a particular 3.x minor version.
Borlabs Cookie 1.x	No documented integration or confirmed support. Check the vendor-supported target version and migration procedure before switching.
Complianz, Cookiebot, Real Cookie Banner, iubenda	Built-in integrations using the respective plugin interfaces. No exhaustive tested-version list or confirmed numeric minimum version is available. Verify the particular installation.
CookieYes / older GDPR Cookie Consent	Integration using the legacy plugin hook. No confirmed numeric version boundary between this and the web-app integration.
CookieYes connected to its web app	A different suppression path removes the external loader from cdn-cookieyes.com. Locally hosted, modified, or differently injected scripts are not automatically covered.

Other external loaders from OneTrust, Osano, Termly, Quantcast Choice, Didomi, TrustArc, Usercentrics, CookieScript, and CookieFirst are removed using known script domains. This is not a guarantee for every product version or installation method. Custom banners and different integrations may require the developer integration described below.

Banner still visible: version checks and support guidance

1. Collect the banner name and exact version, the EZZE version including its patch/build status, the affected URL, and the test timestamp. A “detected” label confirms plugin detection, not successful suppression in that configuration.
2. Check that cloud activation is complete and banner suppression is enabled. Then check caches/CDNs and additional banners from the theme, tag manager, or other plugins.
3. For Borlabs 2.x, EZZE must contain the legacy integration fix. The originally generated Free 1.0.0 package does not contain this later fix; an individually patched installation can still display 1.0.0. Check the package/build and changelog. The 1.0.0 package newly generated through Freemius on 11 September 2026 contains the fix (build record: 34634511889). Older downloads with the same version number do not automatically contain it. Switching to Borlabs 3.x is not required for the solution verified with 2.2.34.
4. Recommend updates specifically: an EZZE update only helps if the available package contains the relevant fix. A banner update may be appropriate for an unintegrated version or a vendor-confirmed fix; verify the target version and migration guidance first. Do not invent minimum versions for vendors without confirmed boundaries or promise that an update will resolve the issue.
5. Run a new test afterwards. Saved screenshots do not change retrospectively. If the banner remains, send the details above and the new screenshot to support, but never the secret test key or a URL containing its value.

Example support response: “Borlabs Cookie 2.x needs the corresponding EZZE integration. Suppression was verified with Borlabs 2.2.34 and the EZZE fix. First check whether your EZZE installation contains that fix, enable banner suppression, and run a new test. Switching to Borlabs 3.x is not generally required for this.”

For developers: CMP not built into the plugin

1. Vendor-documented URL flag: If the provider documents a query parameter that disables or skips the banner (preview, measurement, bot mode, etc.), append it with the ezzewcag_accessibility_test_cloud_url filter (see the example below). The plugin registers its secret parameter at priority 15. Use a lower priority (e.g. 10) so both parameters end up on the URL, or a higher priority (e.g. 20) if your callback must see the URL after the key is attached.
2. Vendor-documented PHP hooks: Hook ezzewcag_accessibility_test_register_cmp_bypass. It runs only when a valid bypass request is detected (correct secret in the query string and the setting enabled). In your callback, register the CMP’s own filters or actions so the banner does not load for this request only. The plugin fires this action from early plugins_loaded and init.
3. Custom bypass detection: If the query string is stripped by a cache or proxy but you can still identify the cloud run (e.g. User-Agent), extend detection with the filter ezzewcag_accessibility_test_cmp_bypass_active. It receives the default boolean and the configured query parameter name.
4. Rename the query parameter: Only if required for your stack: filter ezzewcag_accessibility_test_cmp_bypass_query_arg. The same name must be used wherever you read the parameter on the server.

In custom code you can call WCAG_Accessibility_Test_CMP_Bypass::is_bypass_request_active() to check whether the bypass context applies on the current HTTP request.

Example: custom CMP hooks via the plugin action

Replace the commented line with filters or calls described in your CMP’s developer documentation. This snippet is not shipped with the plugin. Child theme functions.php is enough for most sites. Use an MU plugin or a small custom plugin only if you need the code to stay active when the theme changes (or you do not use a child theme).

<?php
/**
* Runs only during a valid cloud-test bypass request (secret in URL + setting on).
* Register your CMP’s hooks to suppress the banner for this load only.
*/
add_action(
'ezzewcag_accessibility_test_register_cmp_bypass',
static function () {
if ( ! class_exists( 'WCAG_Accessibility_Test_CMP_Bypass' ) ||
! WCAG_Accessibility_Test_CMP_Bypass::is_bypass_request_active() ) {
return;
}
// Example: add_filter( 'your_cmp_show_banner', '__return_false' );
}
);

Example code (developers): query parameters for the cloud test

This code is not shipped with the plugin. Place it in an MU plugin (recommended: e.g. wp-content/mu-plugins/wcag-cloud-test-consent-tweaks.php) or your child theme functions.php. Take a backup first; only deploy if you understand the impact.

Query parameters for cloud tests only (plugin filter)

Use when your CMP documents a supported URL flag for preview/consent flows. Replace YOUR_QUERY_KEY and YOUR_QUERY_VALUE with the vendor’s exact names; if none exists, do not use this approach. The filter applies to every Accessibility Test cloud run, unless you add your own conditions inside the callback.

<?php
/**
* Only for EZZE WCAG Pro cloud runs: adjust URL before the proxy request.
*
* Customize: YOUR_QUERY_KEY / YOUR_QUERY_VALUE per CMP documentation.
*/
add_filter(
'ezzewcag_accessibility_test_cloud_url',
static function ( $url, $strategy, $post_id, $page_type ) {
return add_query_arg(
'YOUR_QUERY_KEY',
'YOUR_QUERY_VALUE',
$url
);
},
10,
4
);

Manual batch runs: daily cap

Per site and calendar day (timezone from WordPress Settings → General), up to 10 manual batch starts protect infrastructure. Scheduled or publish-triggered runs follow separate rules.

Modes

Single test (Free):

• Test one URL
• Under Select content, you can search the grouped list. Categories and entries scroll together. Press Escape to close the list and return focus to the selection field.
• The content selector shows the title and URL path in one compact row, omitting the current site’s domain. Search also matches the full URL. Hovering over the information button or focusing an entry displays its full title and permalink beside the information button. Narrow views hide the path; use the information button to inspect the full address before selecting the content.
• Results inline
• If the server response is interrupted in the test view while the test continues, the view uses short status requests to wait for that exact test. Its completed result appears automatically in the list without refreshing the page or restarting the test. Recovery waits up to ten minutes; if it cannot complete, you can refresh the result list. An actual competing test is still blocked.
• Detailed issue list
• Available from the admin bar, editor, or plugin UI
• If a transient transport, rate-limit, or service failure prevents the cloud testing service from starting a test, the plugin waits briefly and retries the start exactly once. Only if that attempt also fails does the message explain that the cloud testing service is temporarily unavailable. Usage-limit, permission, and URL errors are not retried automatically.
• With mobile testing enabled, the single test runs as two separate steps. If only the mobile step encounters a transient loading or service failure, the plugin retries it exactly once. If it still fails, the successful desktop result remains available and is shown with a clear mobile error.

Batch tests (from Basic):

• Queue many URLs from Basic
• Background processing (WP-Cron or Action Scheduler)
• Every next step is persisted; if a running queue is left without an active worker, the plugin automatically resumes the same run without retesting completed pages
• Select post types, archives, taxonomies, or special pages (e.g. front page)
• Table of results with filters/sorts
• Re-runs overwrite stored results for the same URL
• Before estimation and start, the batch queue is deduplicated by that same normalized URL; an item linked to published WordPress content takes precedence over a URL-only item
• If some items fail (e.g. timeouts or transient errors), retest all still-failing items from that run together with one click, from the error list shown after the run
• If only the mobile view of a saved result failed, retest just that mobile viewport directly from the result detail view
• Live activity keeps one content item visible throughout its viewport sequence: after the desktop test, its title stays in place, the desktop chip shows the completed result, and the mobile chip advances from Preparing to the running test. The content moves to the finished list only after every enabled viewport has completed. Desktop-only runs omit the mobile chip; between two contents, the next known content is already shown as preparing. Reloading restores the same state from the persisted worker, queue, and completion data. If you re-enable Auto-refresh after a pause, the plugin first synchronizes the complete current results view and then resumes incremental updates.
• The recent finished-tests list in live activity starts empty for each new batch and shows only results from that run. New results are added without rebuilding existing rows on every status poll; unchanged result chips retain keyboard focus. Reloading restores the saved activity for the same run.
• While a cloud test is pending, its content stays visible between status checks. Waiting for the next status check does not temporarily display the following content.
• Preparing appears only before the cloud confirms that the selected viewport is running. During execution, its Desktop or Mobile indicator is active without the preparation label. Completed viewports show their result; the next viewport can briefly show Preparing before it starts.
• Before a content item starts, only Preparing is shown. The Desktop and Mobile badges appear when testing begins. During the later mobile preparation, the completed desktop result stays visible and Mobile · Preparing forms one group beside it.
• If your admin session expires, background updates pause while you log in again. The WordPress login window is not covered by additional session notices. If no login window is open, at most one notice appears. After a confirmed login, the views update again; start, delete and cancel actions are not repeated automatically. The batch continues on the server.

After publish / update:

• Optional automatic test when posts/pages are first published (default off)
• Optional automatic test when already published posts/pages are saved again from Basic (default off)
• Configurable roles for both (default: Administrator, Editor, Author)
• Optional email after update tests (default off; publish email default on when publish auto-test is enabled)

Scheduled batches (from Basic):

• Recurring runs (weekly, monthly, custom interval) from Basic
• Configurable cadence
• Choose post types, archives, taxonomies
• Runs via WP-Cron or Action Scheduler

Integrations & permissions

Entry points:

• Admin Bar: Quick test action on the front end
• Editor panel: In the Block Editor, the Accessibility sidebar shows the latest Desktop and Mobile results, a link to plugin results, and an action to start a test for the edited URL. The Classic Editor exposes the same panel in the Publish box when enabled. It appears only for supported content types and users allowed to run tests. Published content can be tested; drafts follow the documented guardrails.

Capabilities:

• Who may run single tests: Configurable (default: Administrator, Editor)
• Who may test others’ content: Configurable (default: Administrator only)
• Who may start batches: Configurable (default: Administrator only)
• Who may delete results: Configurable (default: Administrator only)

Auto test on publish:

• Toggle on/off (default off)
• Optional email after test (default on when auto-test on publish is enabled)
• Choose which roles trigger runs (default: Administrator, Editor, Author)

Auto test on update (Basic+):

• Toggle on/off (default off)
• Runs when an already published post or page is saved again
• Optional email after test (default off)
• Uses the same role list as auto test on publish
• The result email summarizes the status, tested content, desktop/mobile scores, timestamp, and direct links in a responsive layout. Metrics, details, and actions stack on phones, and a plain-text alternative is included.

Scheduled batches (from Basic):

• Interval: Weekly, monthly, custom (days)
• Post types: e.g. post, page
• Archives / taxonomies / special pages: as offered in settings
• Optional email after every manual or scheduled batch run: Clearly distinguishes completed, failed, and cancelled runs and shows only relevant information such as processed pages, problems, duration, test type, viewport, initiator, and timestamps. Retries and sample errors appear only when available. Limit notices state the reason, planned scope, and next steps.

Support ID for batch run problems

If a batch run takes unusually long, stops making progress, fails, or ends unexpectedly, include its full support ID in your support request. This lets support identify the exact run. Briefly describe what happened and the progress or error message you saw.

On the Accessibility Test page, open Batch run history beside Help. It opens a side panel on desktop and a bottom sheet on phones. The newest run is expanded; older runs can be expanded individually. Each run contains its own summary with status, page count, start, end, duration, retries, test scope and test errors, plus the saved test type, viewport and starter. Older runs may lack information that was not yet saved. The small copy icon directly beside the support ID copies only that ID. Use Download diagnostics to save the diagnostic data. Completion emails also contain the ID. Always copy the complete string beginning with EW-B-.

The support ID stays the same when the same run resumes. A newly started batch run receives a new ID. Copying the ID or downloading diagnostics does not create a support request.

Report problems promptly: run summaries and diagnostic events are retained for 90 days and then automatically deleted. Runs from before support IDs were introduced do not receive an ID retroactively; in that case, provide your website and the affected run’s date and start time.

Results

Each run includes:

• Overall score: 0–100 accessibility score
• Result-list score traffic light: 90–100 is green, 50–89 is yellow, and 0–49 is red. The numeric score always remains visible, so the rating is not communicated through color alone.
• Categories: Grouped by audit areas
• Redirects: The plugin checks the redirect path before starting a cloud test. A single test first shows the requested URL and presents a resolvable destination with its WordPress title, localized content type, and linked URL without creating a score. For an internal destination, Test redirect destination starts a separate confirmed test; external destinations are never tested. A completed destination result belongs to the destination, while the requested URL remains visible as provenance and is used by Retest.
• Result filters: Combine content type, page type, content status, issue status, score, test age, and test source. “Orphaned results” shows saved tests whose associated WordPress content is no longer published, for example because it is in Trash, saved as a draft, or permanently deleted. These rows carry a visible “Orphaned” badge and can be deleted individually or together. URL-only, archive, and taxonomy results with post_id = 0 remain valid. The notice and filter count the same deduplicated entries, so older saved tests for the same content do not inflate the number. “Without issues” only shows entries whose desktop and mobile results are both issue-free. Active filters appear as individually removable chips and persist for the browser session. On phones, the combined filter opens as a bottom sheet; Apply commits the draft, while Cancel, Close, Escape, the backdrop, or a downward swipe leaves the applied filters unchanged.
• Responsive details: On phones, the result opens as a focused bottom sheet that sits flush with the left, right, and bottom viewport edges and keeps rounded corners only at the top. The header and close action remain fixed. The top handle can be dragged downward with a thumb to close it; the sheet slides down while the background dimming fades and the page remains visible. On larger screens, it remains embedded in the result list.
• Current score and dashboard: Only results for published WordPress content and valid URL-only results contribute to current metrics, analytics, AI Insights, and reports. Trashed, draft, and deleted content does not affect the current score. Its run history remains available for historical traceability and cannot re-enter the current scope during reaggregation.
• Cleanup: Deleting current or orphaned results also removes their findings, explanations, and stored audit/WCAG outcomes. Historical run records remain intact; unrelated current viewports or user results are not removed accidentally.
• Desktop/mobile switch: Score, screenshot, issue count, and check details always apply only to the currently selected viewport.
• Check groups: Failed, manual, passed, and not-applicable checks are each shown with counts and can be expanded separately. For new test results, the manual, passed, and not-applicable groups also contain the individual localized check names and descriptions. Not-applicable checks explain why two pages can have different numbers of automatically evaluated checks.
• Accessibility Inspector: The result-wide Open Inspector action opens all affected elements on the tested page; the hat-and-glasses action opens the same Inspector at the exact selected finding. Previous, next, and overview controls let you navigate every affected element, while several findings for the same DOM target remain individually selectable. The non-modal Inspector distinguishes a visible match, an element that exists in the DOM but is hidden, a structural element with no visible box of its own, a missing selector, and an ambiguous selector with several matches. It reports the element/role, measured size, visibility cause, and a best-effort accessibility-tree status. A visible element is framed in red; a no-box element uses an amber visible-child context without pretending that a child is the tested node. On desktop the Inspector starts flush with the top, right, and bottom edges of the available viewport and stays below a visible WordPress admin bar. One compact icon button opens the right, left, top, or bottom docking choices, while a separate eye-off button hides the Inspector; the preference is stored only in the browser. Side docks add a numbered rail for every affected element, and top or bottom docks arrange navigation, element context, and remediation side by side. Phones retain the fixed bottom dock without position choices. Hiding reduces the dock to a labelled viewport-edge button while preserving the active target, highlight, and browser preview; the edge button restores it. There is no permanent Close action, and Escape leaves the result-scoped Inspector open. Every plan can open the AI Element Fix or generate it within its allowance. A browser preview is available only for allowlisted accessible-name attributes, tightly bounded text/background colors for contrast findings, and a persistent underline for link-in-text-block. The link preview may additionally contain exactly one six-digit text color; color alone is not accepted. A color preview shows the before/after colors and contrast ratios, calculates the applicable threshold, and reports the result in text as passing, failing, or not reliably verifiable. Complex backgrounds remain manual guidance. When no safe patch can be derived, the Inspector explicitly identifies the suggestion as manual guidance. Every preview is explicitly temporary and is undone on request or navigation; hiding, restoring, and redocking preserve it. It never saves content or styles. Arbitrary AI HTML, JavaScript, or CSS is never applied. Free Explanation & Solution help beside the finding needs no AI request. Reduced motion disables animation and smooth scrolling.
• Inspector rail and severity: In a side dock, Overview is the first rail action above the numbered affected elements. The colored severity dot on each number is repeated as localized text in the action’s accessible name, the Overview entry, and the active finding, so severity never depends on color alone.
• Inspector preview actions: Initially, only Apply preview is available. After successful application it is replaced by Undo preview without resetting the Inspector region’s scroll position.
• Inspector presentation: When an Inspector region needs scrolling, native wheel, touch, and keyboard operation remains available while a slim overlay scrollbar is shown. When docked at the top or bottom, element context and remediation scroll independently and each receives its own scrollbar when it overflows. On phones, the handle zone and header form one continuously tinted surface; a deliberate downward swipe from the handle or non-interactive header space hides the Inspector without ending the inspection session. For links and other inline elements that wrap across lines, the Inspector highlights each visible line fragment separately instead of enclosing unrelated text between the fragments in one large rectangle. If a selected element is hidden only by a recognized entrance animation, the Inspector scrolls specifically to that element, waits for a bounded reveal, and evaluates it again. Intentionally closed menus, dialogs, details, or tabs are not opened. If a lazily created target node does not exist yet, its nearest existing selector ancestor is scrolled first; only then can a bounded fallback sweep run, stopping on a match and restoring the original position after failure.
• AI Element Fix quota: In the Inspector, all users see the remaining AI Element Fix allowance; previously consumed AI explanations remain counted. The counter refreshes automatically after a new generation and exposes explicit loading and error states.
• Metadata: Tested URL, test runner, and trigger type (for example Manual, Batch, or Scheduled) remain compact and visible. On narrow screens, long URLs are initially shortened and can be expanded in full on demand; the separate link button opens the page in a new tab.

Redirect handling

• Single test: No test credit is used when the redirect notice is shown. An internal destination is tested only after explicit confirmation. The server resolves the destination again when the action is used, so a changed or external target cannot be smuggled in by the browser.
• Batch, scheduled, publish, and update tests: Test internal redirect destinations automatically is off by default in Accessibility Test settings. When off, redirected items are reported as skipped without a score or findings. When on, only destinations on the same domain are tested automatically.
• Attribution: A completed destination test is stored only for the final destination URL and its WordPress content identity. The source URL is metadata, not a second result.
• Safety and duplicates: External targets are never requested after their redirect response. Loops, invalid destinations, missing locations, unreachable URLs, and excessive redirect chains are errors. If several source URLs lead to the same destination in one batch, that destination is tested once.

Examples

Example 1: Site-wide baseline

Run a batch across key templates, fix top recurring issues, then re-test.

Example 2: After publish

Enable auto tests so new posts get a score without manual clicks.

Example 3: Monitoring

Schedule monthly batches and watch Analytics for regressions.

Example 4: Editorial workflow

Let editors run single tests on their own posts while batches stay admin-only.

Tips

• Reality check: Automated tests cannot find every WCAG issue—manual QA and expert review remain essential.
• Use history to track progress
• Fix critical/serious items first
• If you hit URL limits, upgrade or prioritize high-traffic templates
• Background runs should not block normal browsing
• Combine spot checks (changed pages) with scheduled sweeps

Note: No automated checker proves full WCAG conformance. Use this as part of a broader accessibility program.

Available for: Configurable roles (default: Administrator) Free

Batch tests: from Basic

Scheduled tests: from Basic

For a step-by-step guide to the element card, accessibility tree and preview, see: Accessibility Inspector: controls and field explanations.