A11yFix for WCAG

Why meet WCAG?

• WCAG is the widely accepted checklist for making websites usable by people with disabilities (screen‑reader users, people with low vision, those who navigate by keyboard, etc.).
• Meeting WCAG reduces the chance that people are blocked from using your site and improves overall user experience.

What's the legal risk if you don't?

• You can be sued. In many countries (notably the U.S.), courts and government agencies look to WCAG when deciding if a website unlawfully excludes people with disabilities.
• Lawsuits or government enforcement can lead to orders to fix the site, costly settlements, lawyers' fees, ongoing monitored remediation, and damage to your brand.
• Public bodies and government contractors often face stricter, mandatory rules; failing those can mean losing contracts or facing fines.

What authorities say (short)

• U.S.: ADA (Title II/III) and DOJ guidance point to WCAG as the practical standard; Section 508 applies to federal technology.
• EU/UK/Canada: public‑sector rules and regional standards reference WCAG or EN 301 549 as the technical benchmark.

Make accessibility a priority now. Adopt WCAG (aim for Level AA), run regular audits, document remediation plans, and fix issues promptly. Doing so lowers legal risk, broadens your audience, and avoids expensive, disruptive enforcement or litigation.

What this plugin is

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.

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.

What this plugin does

In simple words, the plugin does four main jobs:

1. It starts from your site home page and follows internal links.
2. It stores the pages it found in your browser so you can work with them again without starting from zero every time.
3. It runs accessibility rules against those pages.
4. It helps you inspect problem areas in a live page view and, when possible, in the WordPress block editor view.

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.

Important thing to know

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.

Main workflow

The normal workflow is usually this:

1. Open the A11yFix for WCAG page in WordPress admin.
2. Choose a depth limit.
3. Click Start crawl to collect internal pages.
4. Click Run test to move into testing.
5. Review the results in Test results.
6. Open a page in Rules view to see where the failed elements are.
7. Switch to the WordPress editor view when available to compare the live page with editor blocks.

What each tab is for

Crawled pages tab

This is the starting tab. It shows the pages the plugin found while crawling your site.

This tab is needed because the plugin first needs a list of pages before it can run accessibility checks in a structured way.

What you see here:

• A depth setting.
• Buttons for crawl and test actions.
• A table of stored pages.
• Common layout detection information.

What the common layout detection section means:

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.

Test tab

This tab is used to load pages into a preview iframe and run accessibility checks. Think of it as the active testing area.

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.

What you see here:

• A preview frame with the selected page.
• Buttons for running tests on one page or many pages.
• A button to stop a running test.

Test results tab

This tab shows the collected rule results for the stored pages.

This tab is needed because it gives you a page-by-page summary of which accessibility rules passed or failed.

What you see here:

• A table with one row per stored page.
• A separate status cell for each rule.
• An action button called View and Fix.
• A scope toggle button.

Rules view tab

This tab shows a page inside another preview area and can highlight the elements that failed a selected rule.

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.

What you see here:

• Rule filter buttons.
• A Retest page button.
• A button to switch between the live page and the WordPress editor view.
• In some cases, buttons for viewing or sending an anonymous sample.

What each button and control does

Depth limit

This number controls how far away from the home page the crawler is allowed to follow links.

Example:

• Depth 0 usually means only the starting page.
• Depth 1 means pages linked directly from the starting page.
• Depth 2 goes one level deeper.

This control is needed so you can keep the crawl small and focused, or make it broader when needed.

Start crawl

This button starts collecting internal pages from your site beginning at the home page.

What it does:

• Opens the crawl process.
• Follows allowed internal links.
• Ignores blocked WordPress paths that should not be tested like normal content pages.
• Saves the discovered pages locally in the browser.

This button is needed to build the page list before testing.

Run test

This button appears in the Crawled pages tab.

What it does:

• Starts running accessibility checks on the stored crawled pages.
• Uses the preview/testing flow instead of only showing the crawl list.

This button is needed to move from page discovery into accessibility checking.

Clear crawled pages

What it does:

• Removes the stored page list from the browser.
• Clears the crawl data so you can start fresh.

This button is needed when the crawl list is outdated, incorrect, or you want a clean new scan.

Run all

This button is in the Test tab.

What it does:

• Runs the accessibility test across the available stored pages.
• Continues page by page until it finishes or you stop it.

This button is needed for full-site or multi-page review.

Run

This button is also in the Test tab.

What it does:

• Runs the test only for the page currently loaded in the preview iframe.

This button is needed when you only want to retest one page instead of everything.

Stop test

What it does:

• Stops a running test session.

This button is needed when testing takes too long, the selected page is wrong, or you want to interrupt the current run.

Clear test results

This button is in the Test results tab.

What it does:

• Removes saved rule results from the browser.
• Keeps you from mixing old test results with new ones.

This button is needed when you want to retest from a clean state.

Scope toggle button

The label changes between Scope: page only and Scope: all.

What it does:

• Changes how rule failures are displayed in the results table.
• In page-only mode, the plugin focuses on problems that belong to the current page.
• In all mode, the plugin can show the broader failure state without limiting the view so strictly to the page-level scope.

This button is needed because sometimes you want a narrow page-specific view, and sometimes you want the wider rule result picture.

Rule buttons in Rules view

These are the buttons such as:

• Images alt
• Links
• Heading order
• Form labels
• ARIA and accessible names
• Keyboard focusable
• Low contrast

What they do:

• Turn highlighting on or off for a specific rule.
• Show the elements on the page that failed that rule.

These buttons are needed so you can focus on one type of problem at a time instead of looking at all failures mixed together.

What each rule button is for

Images alt

Used to inspect images with missing, empty, or otherwise problematic alternative text.

Links

Used to inspect links that do not have a clear accessible name or meaningful text.

Heading order

Used to inspect heading structure problems, such as skipped heading levels or confusing page outline order.

Form labels

Used to inspect form controls that are missing labels or have labeling problems.

ARIA and accessible names

Used to inspect problems where ARIA attributes and the visible or computed accessible name do not work well together.

This area groups checks related to how controls are named for assistive technology.

Keyboard focusable

Used to inspect interactive-looking elements that are not properly keyboard accessible, or similar focus and keyboard behavior problems.

Low contrast

Used to inspect text or UI parts that may not have enough color contrast.

Additional Actions and Features

Retest page

This button is in Rules view.

What it does:

• Runs the checks again for the page currently open in Rules view.

This button is needed after you make a content or code change and want to verify that one page again.

View in WP editor

This button appears in Rules view when an editor view is available for the current page.

What it does:

• Switches the Rules view iframe from the live page to the WordPress block editor view.

Why this is useful:

• The live page shows the real output visitors see.
• The editor view helps you compare those failing areas with editable blocks.

When the plugin is already showing the editor, this button changes to View live so you can switch back.

View live

What it does:

• Switches back from the editor view to the live frontend page.

This button is needed so you can compare frontend output and backend editor structure.

View before send

This button is normally hidden and only appears in special cases.

What it does:

• Opens a preview of the anonymous sample data the plugin is preparing.

This button is needed so a user can review what would be shared before sending anything.

Send data

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.

What it does:

• Sends an anonymous diagnostic sample to the configured sample endpoint.

This button is needed for debugging difficult mapping or inspection problems without sending the full site content in a normal manual report.

Status line

At the top of the plugin there is a status message area that shows messages like Ready, running states, switching states, or errors.

This is needed so the user can see what the plugin is doing right now.

What the tables and clickable items do

Links in the Crawled pages table

The URL in each Crawled pages row is clickable.

What it does:

• Opens that stored page in the Test tab preview area.

This is needed for quick page selection.

Information in the Crawled pages table

Each row shows:

• URL
• Depth
• ID
• Crawled date and time

This information helps you understand where the page was found, what content record it belongs to, and when it was last crawled.

Rule status cells in Test results

Each rule column shows a result for that page.

Typical meanings:

• Pass means the rule did not find a problem for that page.
• Fail means the rule found one or more issues.
• Some cells can act like detail triggers so you can inspect the failed items for that rule.

These cells are needed so you can scan many pages quickly and open details only where needed.

View and Fix

This button is in the Test results table.

What it does:

• Opens the selected page in Rules view.
• Prepares the plugin for visual inspection and highlighting.

This button is needed because it connects the summary table to the detailed inspection view.

What kinds of accessibility checks this plugin covers

Based on the current interface, the plugin checks areas such as:

• Image alternative text
• Link naming and empty links
• Heading structure
• Form labels
• Accessible name source problems
• aria-labelledby integrity problems
• aria-hidden on interactive elements
• Keyboard focusability and keyboard interaction issues
• Low color contrast

What this plugin is especially good for

This plugin is useful when you want to:

• Crawl many internal pages quickly.
• Keep a browser-local testing history.
• Re-run checks after making fixes.
• See exactly where problem elements are located.
• Compare live content with WordPress editor blocks.

What this plugin does not mainly do

This plugin is not mainly a one-click auto-fixer. Its main strength is guided inspection, review, and retesting.

Short summary

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.