This guide outlines known issues that can interfere with a scan, and how to troubleshoot Accessibility Checker scan failures.
How to Tell if Accessibility Checker is not Scanning
Typically, if Accessibility Checker fails to scan one or multiple pages, an error will show up in the WordPress admin dashboard that reads something like:
Whoops! It looks like your website is currently password protected.
If a website’s front end is password protected, be sure that a username and password have been accurately entered into the appropriate area of the General Settings in Accessibility Checker Pro. Please note that only the paid version of Accessibility Checker can scan a password-protected area.
If scans are failing and you are confident that either (a) no part of the website is password protected, or (b) that the site is password protected and you have entered the username and password accurately in General Settings, please keep reading.
“Edge Case” Issues for Accessibility Checker not Scanning
A small number of edge cases can cause Accessibility Checker scans to run partially, or to fail outright. Each section below summarizes a different edge case, how to detect it, and steps that must be taken to resolve it. Please note that some may require intermediate to advanced technical skills to detect and resolve.
WordPress Minimum System Requirements Not Met
WordPress CMS has minimum requirements to run. Failure to meet these requirements in one or multiple areas can interfere with a scan. Review the full System Info under Site Health and compare to WP minimum requirements. If you don’t have sufficient access privileges in order to view the Site Health information, ask your system administrator or web developer to share that information with you.
How to Resolve: The minimum system requirements to run modern versions of WordPress typically require a current and actively supported version of PHP, MySQL or MariaDB, and HTTPS support. You will need to contact your web host and ask them to upgrade these to a more current version. We strongly recommend setting up a test environment first before making any changes to your live site. This will allow you to confirm that updating this software will not create any stability issues or bugs.
WordPress REST API Has Been Disabled
Accessibility Checker utilizes the REST API in its scanning functionality. If the API is disabled, scanning will not function at all. Review the full System Info under Site Health and see if there is a 403 error present due to the API being disabled. Alternatively, try going to [WEBSITE URL]/wp-json/ and see if you get a response indicating the API is disabled.
How to Resolve: There are several different ways in which the REST API can be disabled. In order to restore the REST API, any custom code, plugins, or other configurations that are causing it to be disabled must be eliminated. This issue requires a significant level of technical knowledge to isolate and reverse. We recommend consulting with a skilled developer.
WP-Cron Has Been Disabled Without Any Alternate Cron Function
Accessibility Checker utilizes WP-Cron in its scanning functionality. If the WP-Cron is disabled without an alternative cron function put in place, scanning will not function. Detecting this issue requires administrator-level access to the website and generally, developer-level knowledge is necessary. To help track down issues related to WP-Cron, we highly recommend the WP Crontrol plugin.
How to Resolve: There are numerous things that can interfere with WP-Cron, from being manually disabled to server-related or DNS-related problems. A skilled developer will need to test and isolate the specific cause of the problem and recommend a solution.
SSL Configuration Issues on Local Environments
Some local development environments will use self-signed SSL certificates that ultimately block Accessibility Checker from scanning. There will likely be an error message in the web browser’s console when attempting to run a scan that points to an SSL issue. In most Chromium-based browsers, you can access the console by right-clicking in any “blank” area on the web page and clicking “Inspect” and then “Console” in the dialog that appears.
How to Resolve: You can bypass SSL validation by adding a filter to the website’s functions.php file. Here is the filter:
add_filter( 'edac_no_verify_ssl', '__return_true' );⚠️ Only add this filter in a local environment and never on a live website.
Plugin or Theme Conflicts That Cause JavaScript Errors
If there are conflicts on the website producing JavaScript errors, these can often interfere with Accessibility Checker’s JavaScript scanning (pass 2) because they cause a build-up of unnecessary junk while the scan runs. This build-up happens because the JavaScript scan utilizes the browser session of the user that initiated the scan. PHP scanning will be unaffected (pass 1).
Review the front-end of the website with the browser console open. In most Chromium-based browsers, you can access the console by right-clicking in any “blank” area on the web page and clicking “Inspect” and then “Console” in the dialog that appears. Look for any JavaScript errors being reported. Try to isolate which specific components of the website (plugins, themes, embeds or extensions) are causing the errors.
We also have a list of known conflicts here.
How to Resolve: Resolve the conflicts that are generating the JavaScript errors. Ensuring an error-free front end is good practice for overall site stability. Because there are millions of possible theme and plugin combinations in WordPress, these issues and their solutions will be somewhat unique for each site. If specific themes and plugins on your site produce these errors, it is a good idea to reach out to those developers for support in resolving them.
PHP Configuration Blocking ‘file_get_contents’
Certain configurations of PHP may block Accessibility Checker’s ability to scan with PHP (pass 1). Investigating this issue requires developer-level expertise and potential modification of various configuration files, which is highly technical in nature. Here are the area(s) we recommend checking to see if this is an issue:
- Ensure that ‘allow_url_fopen’ is enabled in the php.ini configuration file.
- Check for configuration issues with SSL/TLS. See the related section in this document.
- Check PHP execution time and memory limits. If ‘max_execution_time’ and ‘memory_limit’ thresholds are lower than expected, they may need to be adjusted up. This is particularly true if the website has unusually large or lengthy web pages.
How to Resolve: Depending on the issue, configuration changes may be necessary to PHP or SSL/TLS in order to get the scan working. A developer will need to test and isolate the specific cause of the problem and implement a solution.
Sites Blocking iframes with X-Frame-Options
If a website has the X-Frame-Options header set to DENY, Accessibility Checker’s JavaScript scanner cannot render the page in an iframe. This will block the JavaScript scanning (pass 2) from running successfully.
How to Resolve: Modify the X-Frame-Options header value to allow iframes during scans. For example, set it to SAMEORIGIN or remove the header altogether. This change requires a developer’s assistance.
