sungraizfaryad

<p>Curator AI is a free plugin that helps you take care of your WordPress site without turning it into a second job. It writes the small bits of SEO text that matter, points out posts that have gone stale, and runs quality checks so you can fix problems before your visitors (or Google) notice them.</p>
<p>It is built for the person who runs the site, not just the developer who set it up. If you have ever looked at a post and wondered whether the headline Google shows is any good, whether your older articles are quietly aging, or whether any of your images are missing their descriptions, this plugin does that looking for you and tells you plainly what it found.</p>
<p>You work with it in two places. Right inside the post editor there is a “Curator AI” sidebar where you can generate a meta title or meta description, score a post’s readability, refresh a stale post, or scan it for broken links. And there is a dashboard under “Curator AI” in your admin area with five simple screens: Overview, Automation, Audit Reports, Bulk Operations, and Settings.</p>
<p>Here is what it can do, in three groups.</p>
<p><strong>SEO writing help</strong></p>
<ul>
<li>Write a meta title, the clickable headline that shows up in Google search results.</li>
<li>Write a meta description, the short summary that sits under that title in Google.</li>
<li>Write alt text for an image, the description that helps screen readers and search engines understand the picture.</li>
<li>If you use Yoast SEO or Rank Math (two popular SEO plugins), it writes these straight into them. If you use neither, it just stores them for you.</li>
</ul>
<p><strong>Keeping content fresh</strong></p>
<ul>
<li>Find stale posts, the ones you have not touched in a long time.</li>
<li>Refresh a post by simply updating its date, or by rewriting the parts that have gone out of date.</li>
</ul>
<p><strong>Site health checks</strong> (these run on your own server, no outside help needed)</p>
<ul>
<li>Give a post a readability score so you know how easy it is to read.</li>
<li>Find posts that are missing a meta title or meta description.</li>
<li>Find images that have no alt text.</li>
<li>Find thin content, meaning posts that are too short to be useful.</li>
<li>Check a post for broken links.</li>
<li>Measure page speed and Core Web Vitals, which are Google’s measures of how fast and steady a page feels, using Google PageSpeed Insights. This one is optional and sends the page address to Google to run the test.</li>
</ul>
<p>A quick, honest note on what needs help from elsewhere. The four AI writing jobs (the three SEO text features plus rewriting a stale post) need the free official “AI” plugin from WordPress.org. That separate plugin is where you connect your provider, such as OpenAI, Anthropic, or Google, and where your API key lives. Curator AI never holds or touches your API key. Everything else, including all the audits and the simple date refresh, works fine without the AI plugin.</p>
<p>On privacy, plainly: Curator AI holds no API keys. The AI writing features send your post content to whatever provider you set up in the AI plugin, and that only happens when you click a button to ask for it. The optional page speed check sends the page address to Google. Every other audit runs on your own server and sends nothing out.</p>
<p>One more thing worth knowing. The automation rules, which can run tasks when you save a post or on a schedule, are all turned off when you install. Nothing runs on its own until you decide to switch it on.</p>
<p>This plugin needs WordPress 7.0 or newer and PHP 8.1 or newer.</p>
<h3>External services</h3>
<p>This plugin can connect to two outside services, and only when you choose to use the features that need them.</p>
<ul>
<li>WordPress AI Client. The AI writing features pass your prompt and the relevant post content to the AI provider you set up in the official “AI” plugin (for example OpenAI, Anthropic, or Google). This happens only when you trigger an AI feature. Curator AI does not store or send any API key of its own.</li>
<li>Google PageSpeed Insights. The optional page speed audit sends the address of the page you are testing to Google so Google can measure how fast it loads. No post content is sent.</li>
</ul>


Curator AI — SEO & Site Care

Keep your WordPress site healthy with SEO writing help, content freshness checks, and quality audits, all in one place.

kija3

<p>A11yFix for WCAG is a WordPress admin tool for checking the accessibility of pages on your site. It is meant for site owners, developers, testers, and content editors who want to find common accessibility problems and inspect where those problems appear on real pages.</p>
<p>The plugin opens inside the WordPress admin area under Tools. It can crawl pages from your site, remember the pages it found, run accessibility checks on those pages, and show the results in a way that is easier to review.</p>
<h3>What This Plugin Does</h3>
<p>In simple words, the plugin does four main jobs:</p>
<ol>
<li>It starts from your site home page and follows internal links.</li>
<li>It stores the pages it found in your browser so you can work with them again without starting from zero every time.</li>
<li>It runs accessibility rules against those pages.</li>
<li>It helps you inspect problem areas in a live page view and, when possible, in the WordPress block editor view.</li>
</ol>
<p>The plugin is focused on practical accessibility review. It does not automatically rewrite your site. Instead, it helps you discover issues, understand where they are, and review the affected content faster.</p>
<h3>Important Thing To Know</h3>
<p>The plugin stores crawl and test data locally in your browser. That means the saved list of pages and test results are mainly for the browser you used during testing. If you switch browser or clear browser storage, you may need to crawl and test again. This design keeps the data private and under your control, but it also means the plugin is not a centralized site-wide report tool. It is more of a personal review assistant that helps you work through accessibility issues in a structured way.</p>
<h3>Main Workflow</h3>
<p>The normal workflow is usually this:</p>
<ol>
<li>Open the A11yFix for WCAG page in WordPress admin.</li>
<li>Choose a depth limit.</li>
<li>Click Start crawl to collect internal pages.</li>
<li>Click Run test to move into testing.</li>
<li>Review the results in Test results.</li>
<li>Open a page in Rules view to see where the failed elements are.</li>
<li>Switch to the WordPress editor view when available to compare the live page with editor blocks.</li>
</ol>
<h3>What Each Tab Is For</h3>
<h3>Crawled Pages Tab</h3>
<p>This is the starting tab. It shows the pages the plugin found while crawling your site.</p>
<p>This tab is needed because the plugin first needs a list of pages before it can run accessibility checks in a structured way.</p>
<p>What you see here:</p>
<ul>
<li>A depth setting.</li>
<li>Buttons for crawl and test actions.</li>
<li>A table of stored pages.</li>
<li>Common layout detection information.</li>
</ul>
<p>What the common layout detection section means:</p>
<p>The plugin tries to detect parts that are probably shared across many pages, such as the site header and footer. This is useful because repeated layout parts often create repeated accessibility problems across the whole site.</p>
<h3>Test Tab</h3>
<p>This tab is used to load pages into a preview iframe and run accessibility checks. Think of it as the active testing area.</p>
<p>This tab is needed because the plugin needs a controlled page preview area where it can open one stored page at a time and evaluate it.</p>
<p>What you see here:</p>
<ul>
<li>A preview frame with the selected page.</li>
<li>Buttons for running tests on one page or many pages.</li>
<li>A button to stop a running test.</li>
</ul>
<h3>Test Results Tab</h3>
<p>This tab shows the collected rule results for the stored pages.</p>
<p>This tab is needed because it gives you a page-by-page summary of which accessibility rules passed or failed.</p>
<p>What you see here:</p>
<ul>
<li>A table with one row per stored page.</li>
<li>A separate status cell for each rule.</li>
<li>An action button called View and Fix.</li>
<li>A scope toggle button.</li>
</ul>
<h3>Rules View Tab</h3>
<p>This tab shows a page inside another preview area and can highlight the elements that failed a selected rule.</p>
<p>This tab is needed because summary tables alone do not show exactly where the problem is on the page. Rules view helps you visually inspect the failing elements.</p>
<p>What you see here:</p>
<ul>
<li>Rule filter buttons.</li>
<li>A Retest page button.</li>
<li>A button to switch between the live page and the WordPress editor view.</li>
<li>In some cases, buttons for viewing or sending an anonymous sample.</li>
</ul>
<h3>What Each Button And Control Does</h3>
<h3>Depth Limit</h3>
<p>This number controls how far away from the home page the crawler is allowed to follow links.</p>
<p>Example:</p>
<ul>
<li>Depth 0 usually means only the starting page.</li>
<li>Depth 1 means pages linked directly from the starting page.</li>
<li>Depth 2 goes one level deeper.</li>
</ul>
<p>This control is needed so you can keep the crawl small and focused, or make it broader when needed.</p>
<h3>Start Crawl</h3>
<p>This button starts collecting internal pages from your site beginning at the home page.</p>
<p>What it does:</p>
<ul>
<li>Opens the crawl process.</li>
<li>Follows allowed internal links.</li>
<li>Ignores blocked WordPress paths that should not be tested like normal content pages.</li>
<li>Saves the discovered pages locally in the browser.</li>
</ul>
<p>This button is needed to build the page list before testing.</p>
<h3>Run Test</h3>
<p>This button appears in the Crawled pages tab.</p>
<p>What it does:</p>
<ul>
<li>Starts running accessibility checks on the stored crawled pages.</li>
<li>Uses the preview/testing flow instead of only showing the crawl list.</li>
</ul>
<p>This button is needed to move from page discovery into accessibility checking.</p>
<h3>Clear Crawled Pages</h3>
<p>What it does:</p>
<ul>
<li>Removes the stored page list from the browser.</li>
<li>Clears the crawl data so you can start fresh.</li>
</ul>
<p>This button is needed when the crawl list is outdated, incorrect, or you want a clean new scan.</p>
<h3>Run All</h3>
<p>This button is in the Test tab.</p>
<p>What it does:</p>
<ul>
<li>Runs the accessibility test across the available stored pages.</li>
<li>Continues page by page until it finishes or you stop it.</li>
</ul>
<p>This button is needed for full-site or multi-page review.</p>
<h3>Run</h3>
<p>This button is also in the Test tab.</p>
<p>What it does:</p>
<ul>
<li>Runs the test only for the page currently loaded in the preview iframe.</li>
</ul>
<p>This button is needed when you only want to retest one page instead of everything.</p>
<h3>Stop Test</h3>
<p>What it does:</p>
<ul>
<li>Stops a running test session.</li>
</ul>
<p>This button is needed when testing takes too long, the selected page is wrong, or you want to interrupt the current run.</p>
<h3>Clear Test Results</h3>
<p>This button is in the Test results tab.</p>
<p>What it does:</p>
<ul>
<li>Removes saved rule results from the browser.</li>
<li>Keeps you from mixing old test results with new ones.</li>
</ul>
<p>This button is needed when you want to retest from a clean state.</p>
<h3>Scope Toggle Button</h3>
<p>The label changes between Scope: page only and Scope: all.</p>
<p>What it does:</p>
<ul>
<li>Changes how rule failures are displayed in the results table.</li>
<li>In page-only mode, the plugin focuses on problems that belong to the current page.</li>
<li>In all mode, the plugin can show the broader failure state without limiting the view so strictly to the page-level scope.</li>
</ul>
<p>This button is needed because sometimes you want a narrow page-specific view, and sometimes you want the wider rule result picture.</p>
<h3>Rule Buttons In Rules View</h3>
<p>These are the buttons such as:</p>
<ul>
<li>Images alt</li>
<li>Links</li>
<li>Heading order</li>
<li>Form labels</li>
<li>ARIA and accessible names</li>
<li>Keyboard focusable</li>
<li>Low contrast</li>
</ul>
<p>What they do:</p>
<ul>
<li>Turn highlighting on or off for a specific rule.</li>
<li>Show the elements on the page that failed that rule.</li>
</ul>
<p>These buttons are needed so you can focus on one type of problem at a time instead of looking at all failures mixed together.</p>
<h3>What Each Rule Button Is For</h3>
<h3>Images Alt</h3>
<p>Used to inspect images with missing, empty, or otherwise problematic alternative text.</p>
<h3>Links</h3>
<p>Used to inspect links that do not have a clear accessible name or meaningful text.</p>
<h3>Heading Order</h3>
<p>Used to inspect heading structure problems, such as skipped heading levels or confusing page outline order.</p>
<h3>Form Labels</h3>
<p>Used to inspect form controls that are missing labels or have labeling problems.</p>
<h3>ARIA And Accessible Names</h3>
<p>Used to inspect problems where ARIA attributes and the visible or computed accessible name do not work well together.</p>
<p>This area groups checks related to how controls are named for assistive technology.</p>
<h3>Keyboard Focusable</h3>
<p>Used to inspect interactive-looking elements that are not properly keyboard accessible, or similar focus and keyboard behavior problems.</p>
<h3>Low Contrast</h3>
<p>Used to inspect text or UI parts that may not have enough color contrast.</p>
<h3>Retest Page</h3>
<p>This button is in Rules view.</p>
<p>What it does:</p>
<ul>
<li>Runs the checks again for the page currently open in Rules view.</li>
</ul>
<p>This button is needed after you make a content or code change and want to verify that one page again.</p>
<h3>View In WP Editor</h3>
<p>This button appears in Rules view when an editor view is available for the current page.</p>
<p>What it does:</p>
<ul>
<li>Switches the Rules view iframe from the live page to the WordPress block editor view.</li>
</ul>
<p>Why this is useful:</p>
<ul>
<li>The live page shows the real output visitors see.</li>
<li>The editor view helps you compare those failing areas with editable blocks.</li>
</ul>
<p>When the plugin is already showing the editor, this button changes to View live so you can switch back.</p>
<h3>View Live</h3>
<p>What it does:</p>
<ul>
<li>Switches back from the editor view to the live frontend page.</li>
</ul>
<p>This button is needed so you can compare frontend output and backend editor structure.</p>
<h3>View Before Send</h3>
<p>This button is normally hidden and only appears in special cases.</p>
<p>What it does:</p>
<ul>
<li>Opens a preview of the anonymous sample data the plugin is preparing.</li>
</ul>
<p>This button is needed so a user can review what would be shared before sending anything.</p>
<h3>Send Data</h3>
<p>This button is also normally hidden and appears only in special situations, for example when the plugin detects a problem that the developers may want a sample for.</p>
<p>What it does:</p>
<ul>
<li>Sends an anonymous diagnostic sample to the configured sample endpoint.</li>
</ul>
<p>This button is needed for debugging difficult mapping or inspection problems without sending the full site content in a normal manual report.</p>
<h3>Status Line</h3>
<p>At the top of the plugin there is a status message area that shows messages like Ready, running states, switching states, or errors.</p>
<p>This is needed so the user can see what the plugin is doing right now.</p>
<h3>What The Tables And Clickable Items Do</h3>
<h3>Links In The Crawled Pages Table</h3>
<p>The URL in each Crawled pages row is clickable.</p>
<p>What it does:</p>
<ul>
<li>Opens that stored page in the Test tab preview area.</li>
</ul>
<p>This is needed for quick page selection.</p>
<h3>Information In The Crawled Pages Table</h3>
<p>Each row shows:</p>
<ul>
<li>URL</li>
<li>Depth</li>
<li>ID</li>
<li>Crawled date and time</li>
</ul>
<p>This information helps you understand where the page was found, what content record it belongs to, and when it was last crawled.</p>
<h3>Rule Status Cells In Test Results</h3>
<p>Each rule column shows a result for that page.</p>
<p>Typical meanings:</p>
<ul>
<li>Pass means the rule did not find a problem for that page.</li>
<li>Fail means the rule found one or more issues.</li>
<li>Some cells can act like detail triggers so you can inspect the failed items for that rule.</li>
</ul>
<p>These cells are needed so you can scan many pages quickly and open details only where needed.</p>
<h3>View And Fix</h3>
<p>This button is in the Test results table.</p>
<p>What it does:</p>
<ul>
<li>Opens the selected page in Rules view.</li>
<li>Prepares the plugin for visual inspection and highlighting.</li>
</ul>
<p>This button is needed because it connects the summary table to the detailed inspection view.</p>
<h3>What Kinds Of Accessibility Checks This Plugin Covers</h3>
<p>Based on the current interface, the plugin checks areas such as:</p>
<ul>
<li>Image alternative text</li>
<li>Link naming and empty links</li>
<li>Heading structure</li>
<li>Form labels</li>
<li>Accessible name source problems</li>
<li>aria-labelledby integrity problems</li>
<li>aria-hidden on interactive elements</li>
<li>Keyboard focusability and keyboard interaction issues</li>
<li>Low color contrast</li>
</ul>
<h3>What This Plugin Is Especially Good For</h3>
<p>This plugin is useful when you want to:</p>
<ul>
<li>Crawl many internal pages quickly.</li>
<li>Keep a browser-local testing history.</li>
<li>Re-run checks after making fixes.</li>
<li>See exactly where problem elements are located.</li>
<li>Compare live content with WordPress editor blocks.</li>
</ul>
<h3>What This Plugin Does Not Mainly Do</h3>
<p>This plugin is not mainly a one-click auto-fixer. Its main strength is guided inspection, review, and retesting.</p>
<h3>Short Summary</h3>
<p>A11yFix is a WordPress accessibility review tool. It finds internal pages, runs accessibility rules, shows a results summary, and lets you inspect failing elements directly on the page. The tabs split the work into four stages: collecting pages, testing pages, reviewing results, and visually locating issues.</p>


A11yFix for WCAG

A11yFix for WCAG is a WordPress admin tool for checking the accessibility of pages on your site. It is meant for site owners, developers, testers, and …

Curator AI — SEO & Site Care vs A11yFix for WCAG