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 …

Shiek Md Anwar Hussain Mizan (Sheikh MiZan)

<p>The <strong>Bulk Delete Users by Keyword</strong> plugin provides administrators with a powerful tool for cleaning up user databases by allowing bulk deletion based on specific keywords. Perfect for removing spam accounts, inactive users, or performing database maintenance.</p>
<p><strong>Key Features:</strong><br />
– Advanced keyword filtering across multiple user fields (username, email, display name)<br />
– Batch processing for handling large user databases efficiently<br />
– Real-time progress tracking during deletion operations<br />
– Comprehensive safety warnings and confirmations<br />
– Customizable batch sizes for optimal performance</p>
<p><strong>Enhanced Functionality in Version 2.0:</strong><br />
– AJAX-powered processing for smooth operation<br />
– Detailed progress reporting<br />
– Support for multiple search fields<br />
– Improved user interface<br />
– Better error handling and notifications</p>
<h3>Features</h3>
<h4>Core Functionality</h4>
<ul>
<li>Keyword-based user filtering and deletion</li>
<li>Batch processing for large datasets</li>
<li>Multi-field search (username, email, display name, nickname)</li>
<li>Progress tracking during operations</li>
</ul>
<h4>Safety Features</h4>
<ul>
<li>Explicit warning messages</li>
<li>Confirmation dialogs</li>
<li>Nonce verification for all operations</li>
<li>Capability checks</li>
</ul>
<h4>Performance</h4>
<ul>
<li>Optimized database queries</li>
<li>Configurable batch sizes</li>
<li>Memory-efficient processing</li>
</ul>
<h3>License</h3>
<p>GNU General Public License v2.0 or later</p>
<h3>Privacy Notice</h3>
<p>This plugin does not collect any user data or transmit information to external servers. All operations occur entirely within your WordPress installation.</p>


Bulk Delete Users by Keyword

Efficiently manage your WordPress users with keyword-based bulk deletion capabilities.

A11yFix for WCAG vs Bulk Delete Users by Keyword