❌

Reading view

Built an accessibility scanner in pure PHP using DOMDocument β€” no external APIs or JS dependencies

Sharing this because the implementation might be interesting to other PHP devs even if you don't use WordPress.

I needed to scan rendered HTML pages for common WCAG violations. Most tools do this client-side with JavaScript (axe-core, WAVE, etc). I wanted server-side scanning that runs automatically without anyone having to open a browser.

The core of it is PHP's DOMDocument parsing the final HTML output. I hook into WordPress's output buffer, grab the rendered page, load it into DOMDocument, and run checks against the DOM tree:

  • Images without alt attributes (trivial β€” just querySelector)
  • Heading hierarchy violations β€” walk all h1-h6 elements in order, flag any that skip levels (h2 straight to h5)
  • Color contrast β€” extract computed colors from inline styles and check against WCAG AA ratios (4.5:1 for normal text, 3:1 for large). This is the weakest part because it can't resolve CSS classes, only inline styles and common patterns
  • Form inputs without associated labels β€” check for matching for/id pairs or wrapping label elements
  • Generic link text β€” regex against common lazy patterns ("click here", "read more", "learn more")

The heading hierarchy check was more annoying than expected. You can't just check if h3 exists without h2 because h3 might be inside an aside or nav where it's semantically correct to restart the hierarchy. I ended up only checking the main content area.

The contrast checker is intentionally limited. Real contrast checking needs the full CSS cascade and computed styles, which you can't do server-side without a headless browser. So I catch the obvious cases (inline color/background-color, common utility classes) and skip anything that needs layout computation. Better to catch 60% of contrast issues reliably than to false-positive on everything.

The whole thing is about 800 lines of PHP. No composer dependencies, no external API calls. Results get cached in WordPress transients.

Free on WordPress.org as Cirv Guard: https://wordpress.org/plugins/cirv-guard/

Would be curious if anyone has done similar DOM-based analysis in PHP and found better approaches for the contrast checking problem.

submitted by /u/SearchFlashy9801 to r/PHP
[link] [comments]

I've been building a set of WordPress plugins that handle the stuff most site owners know they should deal with but never get around to configuring properly. All free on WordPress.org.

The two that are live right now:

Cirv Box handles schema markup. It auto-generates JSON-LD for articles, WooCommerce products, FAQs (detects question-style headings on its own), breadcrumbs, how-to content, and your organization info. You toggle on what you want and it generates everything in the background. Detects Yoast and Rank Math if you're running either, avoids duplicating their schema.

wordpress.org/plugins/cirv-box

Cirv Guard is an accessibility checker. Alt text, heading structure, color contrast, form labels, link accessibility. It runs a scan and gives you a report with what needs fixing. Just got approved on .org last week.

wordpress.org/plugins/cirv-guard

Two more are in the WordPress.org review queue. Cirv Pulse monitors Core Web Vitals (LCP, INP, CLS) using the PageSpeed API right from your dashboard. Cirv Comply handles cookie consent with auto-categorization, consent logging, and a privacy policy generator for GDPR/CCPA.

The reason they're all one brand: schema, accessibility, performance, and privacy are all things that fall under "compliance" in my head. Similar audience, similar workflow (scan site, find issues, fix them), and having them share a consistent admin UI makes sense to me.

I'd really like feedback on Guard specifically if anyone tries it. Accessibility testing has a million edge cases and I know I haven't caught them all. What WCAG checks matter most to you?

submitted by /u/SearchFlashy9801 to r/Wordpress
[link] [comments]

I've been building a set of WordPress plugins that handle the stuff most site owners know they should deal with but never get around to configuring properly. All free on WordPress.org.

The two that are live right now:

Cirv Box handles schema markup. It auto-generates JSON-LD for articles, WooCommerce products, FAQs (detects question-style headings on its own), breadcrumbs, how-to content, and your organization info. You toggle on what you want and it generates everything in the background. Detects Yoast and Rank Math if you're running either, avoids duplicating their schema.

wordpress.org/plugins/cirv-box

Cirv Guard is an accessibility checker. Alt text, heading structure, color contrast, form labels, link accessibility. It runs a scan and gives you a report with what needs fixing. Just got approved on .org last week.

wordpress.org/plugins/cirv-guard

Two more are in the WordPress.org review queue. Cirv Pulse monitors Core Web Vitals (LCP, INP, CLS) using the PageSpeed API right from your dashboard. Cirv Comply handles cookie consent with auto-categorization, consent logging, and a privacy policy generator for GDPR/CCPA.

The reason they're all one brand: schema, accessibility, performance, and privacy are all things that fall under "compliance" in my head. Similar audience, similar workflow (scan site, find issues, fix them), and having them share a consistent admin UI makes sense to me.

I'd really like feedback on Guard specifically if anyone tries it. Accessibility testing has a million edge cases and I know I haven't caught them all. What WCAG checks matter most to you?

submitted by /u/SearchFlashy9801
[link] [comments]

What's your approach to structured data / schema markup on WordPress?

Curious how people are handling structured data on their WordPress sites. I've been down this rabbit hole for a while and the options are all over the place.

From what I can tell, most people fall into one of these camps:

1. Let your SEO plugin handle it β€” Yoast and Rank Math both output some schema automatically. Yoast does article and breadcrumb. Rank Math does more types but the settings are spread across multiple screens and it's easy to miss things. Both work, but you're limited to what they decide to support.

2. Manual JSON-LD in your theme β€” You write the schema yourself in header.php or a custom function. Full control, but it's tedious and you have to keep up with Google's spec changes. One wrong date format or missing required field and the whole thing gets silently ignored.

3. Dedicated schema plugin β€” There are a few on WordPress.org that focus specifically on structured data. I ended up building one (Cirv Box) after getting frustrated with options 1 and 2. It reads your actual page content and generates Article, Product, FAQ, HowTo, Breadcrumb, and Organization schema automatically. The main thing I wanted was conflict detection β€” it warns you if your SEO plugin is already outputting the same schema type so you don't end up with duplicates confusing Google.

4. Google Tag Manager β€” Some people inject schema through GTM. Works but feels hacky and you lose the ability to cache anything server-side.

The thing that surprised me most: Google is really strict about schema validation. Even minor issues like a missing dateModified field or a logo URL that returns a 404 will cause your structured data to get completely ignored. No error, no warning in Search Console, just silence. The Rich Results Test tool is the only reliable way to check.

For anyone who hasn't looked at their structured data recently β€” paste a few of your URLs into Google's Rich Results Test. You might be surprised at what's missing or broken. I found errors on pages I assumed were fine for months.

What's everyone else using? Especially curious if anyone's found a good solution for FAQ and HowTo schema that doesn't require manually tagging every question and step.

submitted by /u/SearchFlashy9801
[link] [comments]

How are you handling accessibility compliance on your WordPress sites?

I've been going down a rabbit hole on web accessibility lately and wanted to see where everyone else is at with this.

The EU Accessibility Act starts enforcement in June 2025, and ADA-related lawsuits in the US went up something like 300% over the past few years. If you run client sites or even your own business site on WordPress, this is starting to matter whether you care about compliance or not.

I spent a while looking at what options exist for WordPress specifically:

  1. Manual audits - Run your pages through WAVE or axe DevTools, fix issues by hand. Works fine for a small site but doesn't scale at all. And you have to remember to re-check after every content update.

  2. Overlay widgets (AccessiBe, UserWay, etc.) - These are the ones that add a toolbar to your site. There's been a lot of backlash from the accessibility community about these. The National Federation of the Blind actually put out a statement against overlay products. They don't fix the underlying code issues.

  3. Premium audit services - Companies that do full WCAG audits. Thorough, but you're looking at $5K-$25K depending on site size, and it's a point-in-time snapshot.

  4. Automated scanning plugins - These run checks against your actual content and flag specific violations. Things like missing alt text on images, broken heading hierarchy (h1 jumping to h4), insufficient color contrast ratios, form inputs without labels, generic link text like "click here." I found a few of these in the WP plugin directory, including one called Cirv Guard that checks those 5 WCAG 2.1 items server-side without any external API calls.

For my own sites I've been doing a combination of 1 and 4. Manual checks with axe for the initial build, then an automated scanner to catch stuff that slips through on ongoing content.

Curious what approach others are taking. Is anyone actually getting asked about WCAG compliance by clients? Or is this still something most people ignore until they get a demand letter?

submitted by /u/SearchFlashy9801
[link] [comments]
❌