Security — SmartQCompliance

❓

"I don't want to upload my source code to OptioGit or share my Git repo keys."

The Reframe

Your public code is already being uploaded — by everyone.

Google crawls it. Every scanner crawls it. Underground markets sell your vulnerabilities to red teams. Nation states catalog your attack surface. There's an entire industry built on crawling public sites — many of them underground, selling your weaknesses to hacking frameworks that actively attack your site.

The question isn't "should I share my code?"
It's "who do I want analyzing it?"

The Bottom Line

OptioGit is encrypted at rest, runs through a SOC 2 pipeline, and follows the same security gates as GitHub and GitLab. The difference is we're fixing your vulnerabilities, not selling them.

❓

"What makes SmartQCompliance different from other accessibility tools?"

The Difference

OV signing over HSM. TPM attestations. SHA256 hash on every build, every scan, every workflow.

SBOM for every software dependency. AIBOM for every AI component.

We're not just a scanner — we're a supply chain provider. The moment we deliver code to your site, we become part of your supply chain. So we deliver with the same security and privacy standards required of any third-party vendor: OpenSSF, SLSA v1.0, NIST SSDF, NIST SP 800-161, AIBOM, SBOM.

Every delivery. Every tier. No exceptions.

The Question to Ask Your Current Vendor

Does your ADA/WCAG solution provide an independent daily audit with these standards? Can they show you the SBOM? The AIBOM? The SLSA provenance? The OV-signed chain of evidence?

If not — you're trusting code from a vendor who can't prove what they're deploying to your site.

❓

"Other tools integrate with GitHub, GitLab, Azure. Why is SmartQCompliance different?"

The Blind Spot

Every CI/CD tool advertises "Integrates with GitHub, GitLab, Azure!" without hesitation. But none of them say: "We're now part of your supply chain. Here's our SBOM. Here's our SLSA provenance. Here's our attestation."

The moment a tool deploys code to your site, they become a supply chain vendor.

Most don't act like it. Most can't prove what they deployed. They can't show you the chain of custody. They can't attest to the integrity of what landed on your production server.

This is especially critical for e-commerce. Your checkout flow touches payment data, PII, and legal compliance. If a third-party tool modifies that flow, you need to know exactly what changed, when, by whom, and with what authorization.

The SmartQCompliance Standard

Every deployment through SmartQCompliance — whether via console, desktop, mobile, CI/CD, or continuous agent — carries full supply chain attestation. SBOM. AIBOM. SLSA provenance. OV-signed. RFC 3161 timestamped. FRE 901(b)(9) compliant.

We don't just "integrate" with your CI/CD. We become an auditable, verifiable, court-ready part of your software supply chain.

❓

"But we don't auto-deploy. Our team manually copies the fix code. That's not really supply chain, right?"

The Reality

Automated pipeline: Tool → deploys code → production

Manual workflow: Tool → generates code → human copy-pastes → production

Same result. The artifact came from the tool. The tool is in your supply chain.

Most SaaS tools hide behind: "We just generate suggestions. You deploy them." That's a liability dodge, not a security posture.

If you trust a tool's output, put that output in production, and that output causes harm — the tool was in your supply chain. The manual step doesn't break the chain. It just adds a human relay.

The SmartQCompliance Position

Whether you deploy via CI/CD, click a button in our console, or copy-paste from a report — the code came from us. We sign it. We attest it. We prove what we generated, when, and why.

The delivery method doesn't change our responsibility. That's a standard no one else is claiming — because no one else can claim it.

⚖️

"If I use a third-party tool for accessibility, doesn't that transfer my liability to them?"

The DOJ Is Clear: No.

Under Department of Justice digital accessibility rules (Title II), outsourcing a digital service does not outsource legal responsibility. The entity providing the website remains fully accountable for ensuring third-party content and integrations meet WCAG 2.1 Level AA standards.

Core Principles:
• Ultimate Liability: The public entity or business deploying the tool is liable for non-compliance — not the vendor.
• Contractual Obligations: If a vendor supplies a feature (payment portals, booking forms, plugins), the host entity is responsible for making sure it's compliant.
• No Exceptions: Only purely independent third-party content posted without any contractual arrangement is exempt.

You can hire a vendor to fix your accessibility issues. You cannot hire a vendor to take your liability.

What This Means for Vendor Selection

Procurement Leverage: Require WCAG 2.1 Level AA compliance as a mandatory, weighted requirement in vendor contracts.

Remediation Terms: Build explicit clauses requiring vendors to fix accessibility barriers at their own expense.

Independent Testing: Verify vendor claims through independent audits — not vendor documentation alone.

SmartQCompliance provides the independent audit. Daily. With cryptographic proof. Court-ready evidence that you acted in good faith, managed your vendor risk, and maintained continuous compliance — not because it transfers your liability, but because it demonstrates you took it seriously.

🔮

"Why should I trust SmartQCompliance over the established accessibility vendors?"

We Built What They Kept Missing

Watch the pattern:

They said: "Lawsuits are rising — you need to know your compliance landscape."
We built: POAM tracking and ARA scoring.

They said: "Scanners only detect 40-55% of WCAG issues."
We built: Multi-engine scanning with AI analysis — 90-95% of compliance findings.

They said: "Compliance has shifted left — but we have no solution."
We built: Compliance Platform Management. A universal compiler framework for every tech stack. Auto-deploy to every platform.

They still miss: Chain of custody. Proof of compliance. Supply chain attestation. SBOM. AIBOM. AI security gates.
We built those too. From the core. Not bolted on.

The Difference

The "experts" identify problems. We solve them — before they finish writing the whitepaper.

There are those that lead and those that follow. SmartQCompliance leads.

📊

"Experts say automated scanning only catches 40% of accessibility issues. How is SmartQCompliance different?"

We Cover 95% of WCAG 2.2 Success Criteria

The industry repeats: "Automated tools only catch 40-55% of findings."

Our engine coverage report:
• 83 of 87 WCAG 2.2 Success Criteria covered = 95%
• Level A: 32/32 = 100%
• Level AA: 24/24 = 100%
• Level AAA: 27/31 = 87%

Four engines working together:
• RBO — Rule Browser Optimization Engine: deterministic DOM rule matching (47 SCs)
• VBO — Vector Browser Optimization Engine: AI semantic evaluation for what rules can't express (54 SCs)
• IBO — Intelligent Browser Optimization Engine: live browser keyboard/pointer testing (18 SCs)
• DBO — Deep Browser Optimization Engine: ARIA state machine assertion chains (14 SCs)

Multi-engine coverage means findings are cross-validated. 35 Success Criteria are covered by 2+ engines.

Scanning vs Auditing: Different Jobs

A qualified auditor using a screen reader is invaluable — for determining importance and risk. But they find what they know and have experienced. That's subjective. That's not repeatable.

Our methodology is quantifiable, documented, and repeatable. Every scan. Every day. Same criteria.

For scoring and findings: Better to have a false positive than a false negative. Catch everything. Flag uncertain findings with confidence scores.

For remediation: Different standard. A false positive would introduce unnecessary code. That's why AI reviews all findings before generating fix code — reducing false positives and flagging "Needs Further Review."

We don't replace human auditors. We give them a 95% head start — with proof.

⚠️

"What about accessiBe, AudioEye, UserWay, or EqualWeb? They seem similar."

The FTC Already Answered This

In April 2025, the FTC finalized a $1 million order against accessiBe for deceptively claiming its AI-powered tool could make any website WCAG compliant.

The FTC found that accessWidget failed to make basic website components — menus, headings, tables, images — WCAG compliant. The components that matter most in enforcement contexts are precisely what the product failed to fix.

The FTC also found accessiBe paid for third-party reviews formatted to appear as independent opinions without disclosing the commercial relationship. The order bars accessiBe from making compliance claims for 20 years.

Over 800 businesses using overlay solutions faced accessibility lawsuits in 2023-2024. The presence of an overlay did not protect them. Courts evaluated the underlying digital environment — not the widget — and found that the overlay did nothing to remedy the barriers.

What DOJ Actually Requests — And What Overlays Can't Provide

When an ADA Title II enforcement inquiry opens, the DOJ requests:

• Dated baseline audit report
• Risk-based prioritization framework
• Timestamped remediation log
• Monitoring records
• Training documentation
• Vendor VPAT review records
• Executive reporting history

An overlay subscription produces none of these documents.

SmartQCompliance produces all of them. Daily. With cryptographic proof. That's not similar. That's the opposite.

🔬

"You scan and report. How is that different from what everyone else does?"

Due Diligence vs Due Care

Due Diligence is identifying and documenting risks. Every scanner does this. Scan → report → hand you a PDF.

Due Care is actively implementing controls and verifying they work. Almost no one does this.

SmartQCompliance doesn't just scan your production site. We import your source into our OptioLabs Tech-Stack Test Bed — a backend environment running Next.js, Nuxt, Angular, Svelte, Shopify, Laravel, Jekyll, WordPress, and Drupal. We deploy the fix into the appropriate stack, then crawl it with our next-gen crawler that captures runtime console errors.

That's not functional testing. That's physical QA testing. We verify the fix doesn't break your site before we deliver it.

What the Console Capture Reveals

Every accessibility scanner runs after the page loads. If JavaScript errors prevent a widget from initializing, the scanner reports "widget missing" — not "widget broken." The root cause is invisible.

Our crawler captures what others throw away:
• JavaScript runtime errors (broken functionality)
• Uncaught exceptions (crash-level bugs)
• Network failures (missing resources)
• CSP violations (security conflicts)
• Deprecation warnings (future breakage)

Due Diligence tells you what's wrong. Due Care proves you fixed it — and didn't break anything else.

That's SmartQ Deploy.

🛡️

"My site already has issues I don't know about. Can you help with those too?"

We Establish a Quantified Baseline — Then Fix What We Find

Before we deploy a single accessibility fix, our crawler captures every console error on your site — JavaScript failures, network errors, uncaught exceptions, CSP violations. One customer site had 2,926 pre-existing errors they didn't know about.

We analyze every error with AI and classify accessibility impact:
• BLOCKS_AT: Prevents assistive technology from functioning — goes into your remediation plan
• DEGRADES_AT: Reduces AT experience — secondary priority
• COSMETIC: No accessibility impact — your tech debt, documented

Then we identify which fixes are template-level (fix once, resolve everywhere) vs page-specific.

Auto-Resolve at Scale

2,926 errors. 2 unique patterns. 2 template fixes.

One fix in your shared header or layout file resolves errors across every page that uses it. We generate the fix code, test it in our Tech-Stack Test Bed, and deliver it alongside your accessibility remediation.

BLOCKS_AT errors flow directly into your POAM — they're accessibility barriers discovered through a method no rule engine can replicate.

You came for accessibility compliance. You leave with a healthier site. That's the baseline.

🎨

"All AI accessibility tools check contrast. What makes yours different?"

APCA vs Legacy Contrast

Most tools use the WCAG 2.x contrast ratio — a formula from 2008 designed for projected light, not self-illuminated displays. It fails predictably: flags perfectly readable text, passes unreadable combinations.

SmartQCompliance uses the Accessible Perceptual Contrast Algorithm (APCA) — the contrast model being developed for WCAG 3.0. APCA accounts for:
• Spatial frequency: Font size + weight interaction
• Polarity: Light-on-dark vs dark-on-light behave differently
• Perceptual uniformity: How modern self-illuminated displays actually work

The result: fewer false positives, fewer missed failures, fixes that actually improve readability.

The Algorithm That Will Define Compliance

Your competitor's "AI remediation" runs the same 2008 formula everyone else does. They'll flag your brand colors as failures when they're perfectly readable. They'll pass combinations that strain users with low vision.

SmartQCompliance runs the algorithm that will define compliance when WCAG 3.0 ships. We're not waiting for the standard — we're already there.

Future-proof your remediation. Don't fix to a legacy formula you'll have to re-fix in two years.

Objections We've Heard. Answers That Matter.