Forem: Denis Omerovic

[Boost]

Denis Omerovic — Sat, 18 Apr 2026 21:30:06 +0000

Denis Omerovic

Apr 18

I'm building a flat-priced alternative to Churnkey for SaaS doing $3k-$30k MRR

#saas #stripe #buildinpublic

Comments

2 min read

I'm building a flat-priced alternative to Churnkey for SaaS doing $3k-$30k MRR

Denis Omerovic — Sat, 18 Apr 2026 21:29:34 +0000

The problem, with real numbers

If you run a Stripe-native SaaS between roughly $3k and $30k MRR, somewhere between 5% and 10% of your monthly revenue quietly disappears to failed cards. Expired cards, insufficient funds, the usual. On $10k MRR that's $500-$1,000 a month walking out the door before you even notice.

The fix is known: smarter retries based on the decline code, plus a hosted page where the customer can update their card in 30 seconds. That second piece recovers more than retry timing ever will.

Why the existing options don't fit this band

Churnkey is genuinely good, but the floor is about $3k a year and they take 1-3% of every recovered dollar on top. That math only works once you're past $30k MRR. Stunning is cheaper but the UX feels frozen in 2017 and the config is scattered. ProfitWell Retain killed its free tier. Baremetrics Recover has been coasting for years. If you're below $30k MRR you basically write your own retry cron job and hope.

What I'm building

Nanokept. Flat pricing: $49, $149, or $349 a month by your MRR band. Never a percent of recovered revenue.

What's in the box:

Stripe Connect OAuth install, read-only, about 90 seconds
Decline-code-aware retries: soft declines retry on day 1/3/5/7/14, hard declines stop auto-retrying and trigger a branded customer email
Hosted card-update page per failed invoice
Idempotency keys on every Invoice.pay call so a network hiccup never double-charges anyone
Works against the Stripe sandbox from day one, which I was surprised to find most competitors still don't

Rails 8, SolidQueue for the retry jobs, EU-hosted on Hetzner with Cloudflare in front. I'm solo, based in Bosnia, and billing through Lemon Squeezy as merchant of record since I can't take Stripe directly from here. Previous project was AccessGuard (getaccessguard.com).

Status

Landing page and waitlist are live at nanokept.com. Product is mid-build, targeting end of May 2026 for the first paying cohort.

What I'd like from you

Two questions for anyone running a Stripe SaaS in this MRR band:

What's your actual recovery rate right now, and do you even measure it?
If you've looked at dunning tools and bounced off them, what was the dealbreaker: the price floor, the revenue share, the setup time, or something else?

Link: https://nanokept.com. Happy to answer anything in the comments.

6 Accessibility Checks Most Scanners Miss (And How AccessGuard Catches Them)

Denis Omerovic — Thu, 16 Apr 2026 20:54:14 +0000

axe, WAVE, Lighthouse, Pa11y, and Siteimprove share a rules-engine lineage and share its soft spots. Here are six checks where that baseline tends to under-report, over-report, or punt to manual review, with notes on how we approached each one.

Where scanners agree, and where they stop

Most popular accessibility scanners share a foundation — either axe-core directly or a similar rules engine that reads the static HTML. That gives them fast, reliable coverage of the obvious issues: missing alt text, empty links, heading order, deterministic ARIA misuse. It also means they all share the same blind spots.

We audited what slips through, then built detection for six of the most common gaps. This post walks through each one, explains why it is hard, and shows what a real fix looks like. If you are using any of the major scanners, use this as a checklist for what to double-check by hand.

Run the same page through axe-core, WAVE, Lighthouse, Pa11y, and Siteimprove and you will get broadly similar results for the deterministic rules. That is not a bad thing — the shared baseline catches real problems and catches them fast. What the shared baseline does not catch is anything that requires one of three things: actual browser behavior (not just the DOM), computed state that is not expressed in HTML attributes, or visual geometry that only exists after layout. That is where every scanner has gaps, and it is where we focused this round of work.

1. onclick handlers attached through JavaScript (2.1.1 Keyboard)

The problem: A common pattern in React, Vue, Svelte, and vanilla JS apps: a <div> with a click handler attached via addEventListener. The HTML looks like this:

<div class="card" data-id="42">Open</div>

No onclick attribute, no role, no tabindex — but in the browser, clicking it runs a handler and so does pressing Enter (if the framework wired up a keydown listener too).

Why static scanners miss it: axe, WAVE, and the rest read the HTML as it arrives from the DOM. They can see onclick="..." as an inline attribute, but they cannot see listeners attached with element.addEventListener("click", ...) because those live in JavaScript state, not the attribute set. So they either miss the problem entirely (no flag on a mouse-only div) or over-report (flag every div with a keydown-less onclick even when the framework attached a keydown listener dynamically).

What we do: Before the page script runs, we inject a small shim that wraps EventTarget.prototype.addEventListener. Every call to attach a click, keydown, keyup, or keypress handler gets recorded in a WeakMap keyed by the target element. After the page finishes loading, we query that map and tell the scanner which elements actually received keyboard handlers. The onclick-without-keyboard warning only fires on elements that truly have no keyboard path.

2. Pseudo-element text contrast (1.4.3 Contrast)

The problem: CSS ::before and ::after with a content property render real text to the screen, and that text is subject to the same contrast requirements as any other text. Examples: icon labels, counter numbers, status badges, the "Required" asterisk on form labels.

.badge::before {
  content: "New";
  color: #e0e0e0;
  background: #ffffff;
}

That is 1.13:1 contrast. Invisible. A screen reader will not read it, but the visible rendering still fails WCAG 1.4.3.

Why static scanners miss it: axe-core has attempted pseudo-element contrast since 2022, but the implementation has documented gaps: pseudo-elements without position: absolute are frequently missed, and icon-style pseudo-elements often produce false positives that teams waive. WAVE, Lighthouse (which uses axe), and Pa11y inherit the same behavior.

What we do: While we are in the browser computing styles for every element, we also call getComputedStyle(el, "::before") and getComputedStyle(el, "::after"). If the resulting content is a non-empty string literal, we capture the pseudo-element's color, background, and font size as a separate entry. The contrast checker then evaluates those entries with the same logic it uses for real elements.

3. Contrast over transparent backgrounds and background images (1.4.3 Contrast)

The problem: Modern layouts use transparent backgrounds constantly. A card inside a section inside the body. A header overlay on a hero image. A navigation bar with a semi-transparent background.

axe-core walks the element stack using document.elementsFromPoint to find the effective background, but the approach has documented edge cases: translucent overlays on modals are included incorrectly, opacity on ancestors is handled inconsistently, and when the effective background is a gradient or image the check either errors out or flags it as needs-review.

Why this is hard: There is no single correct answer. The "real" background behind transparent text is whatever happens to be rendered at that pixel, which depends on layout, scroll position, and z-order. For images and gradients, contrast varies across the image.

What we do: For transparent backgrounds, we walk up the DOM tree until we find an ancestor with a non-transparent background color. Between 98% and 100% of pages have a reachable opaque ancestor. For background images or gradients, we emit an honest notice instead of pretending we know the answer — the notice tells you the element sits over a background image and that contrast cannot be reliably computed, with a suggestion to verify manually.

4. Real 320px reflow at an actual viewport (1.4.10 Reflow)

The problem: WCAG 1.4.10 requires content to reflow to 320 CSS pixels without horizontal scrolling. The usual offenders: fixed-width containers, min-width greater than 320px, tables with no responsive wrapper, wide images without max-width: 100%.

Why static checks fall short: You can write static heuristics — look for inline width: 1200px, flag overflow-x: scroll on the body. But a lot of reflow failures only manifest when you actually narrow the viewport: a grid that does not collapse, a flex row that does not wrap, content hidden inside a wrapper whose child has a fixed aspect ratio that exceeds the viewport.

What we do: We run a second browser pass at 320x640 after the main scan. The viewport is resized, layout re-runs, and we query document.documentElement.scrollWidth versus clientWidth. If the page requires horizontal scrolling at 320px, it fails 1.4.10. We also enumerate the first 20 elements whose getBoundingClientRect().right exceeds 320px, so you know exactly which containers are the culprits.

5. Sectioning-aware heading hierarchy (1.3.1 Info and Relationships)

The problem: WCAG 1.3.1 requires a logical heading hierarchy. In practice, scanners flag "skipped heading levels" whenever the next heading is more than one level below the previous one — h1 followed by h3, for example. That rule is correct at the document level. It is wrong inside sectioning content. A page that has an <article> with its own <h1>, or a card layout with independent heading outlines, is following the HTML5 sectioning spec. Flagging every one of those produces 10 to 30 false positives on any page with multiple articles, sidebars, or modal dialogs.

Why most scanners get this wrong: A flat walk over all headings is easy to write. Tracking sectioning context is harder, so most engines do not bother. axe-core does not reset hierarchy at sectioning boundaries. Neither does WAVE.

What we do: We group headings by their nearest sectioning ancestor — <article>, <section>, <aside>, role="article", role="region" — before running the hierarchy check. Each sectioning root gets its own starting heading level, and skips are evaluated within that scope. We also filter out hidden headings so invisible elements do not pollute the hierarchy.

6. Framework-aware severity (2.1.1 Keyboard)

The problem: An onclick handler on a plain <div> without any keyboard path is a real bug. An onclick handler on a <div role="button" tabindex="0"> probably is not — that is a standard pattern where the framework has wired up Enter and Space key handlers. Most scanners give both cases the same severity. You end up with a dashboard full of "errors" that are often framework false positives.

What we do: Severity depends on signal strength. If a div has role="button", it is already announced as interactive — we skip it. If a div has tabindex="0" and an onclick but no explicit keyboard handler, we demote it from error to notice. If neither role nor tabindex is present, we keep it as a warning because we genuinely cannot be sure there is no keyboard path. Combined with the addEventListener tracking from item 1, the false-positive rate on this specific check drops close to zero on modern framework sites.

What to do with this

If you are evaluating accessibility scanners, ask the vendor how they handle each of the six cases above. Not because those are the only things that matter — most scanners cover the deterministic baseline, and they all matter more than these edge cases — but because how a vendor answers tells you how seriously they have thought about the long tail of real-world accessibility.

If you are just trying to make your own site accessible, the short version is:

Run any scanner. The shared baseline catches most real issues.
Hand-check the categories above on a few representative pages, especially if you use a modern JS framework, CSS pseudo-elements, or card-heavy layouts.
Treat scanner notices as signals to investigate, not as failures. Especially for 1.4.3 (contrast) and 1.4.10 (reflow), the "unknown" cases are often where real problems hide.

Originally published on the AccessGuard blog.

Accessibility Lawsuits Surged 27% in 2025. Here's Why Developers Should Care About 2026.

Denis Omerovic — Wed, 15 Apr 2026 20:26:35 +0000

Federal courts saw 3,117 website accessibility lawsuits in 2025 — a 27% jump from 2024. That spike wiped out two years of decline, and 69% of those lawsuits targeted e-commerce businesses.

If you're building websites or web apps, this matters. Here's what's driving the surge and why 2026 will be even worse.

AI Is Making It Ridiculously Easy to Sue

40% of federal ADA Title III filings in 2025 came from pro se plaintiffs — people filing lawsuits without a lawyer. AI tools now let someone generate a legal complaint in minutes. No $5,000 retainer. No attorney consultations.

Plaintiff's law firms are also using AI to scan hundreds of websites at once, flagging accessibility violations automatically, then filing batches of complaints.

The European Accessibility Act Is Now Live

The EAA took effect on June 28, 2025 across all 27 EU member states. Penalties vary but they're painful — up to €100,000 per violation in Germany and Italy, and up to 4% of annual revenue in France.

If your site has EU customers, the EAA applies to you regardless of where your business is based. Unlike the ADA, the EAA explicitly requires WCAG compliance.

The April 2026 Title II Deadline Changes Everything

The new ADA Title II web accessibility rule solidifies WCAG 2.1 Level AA as the benchmark courts reference. This makes it easier for plaintiffs to argue their case against any business.

Overlays Won't Save You

25% of all ADA lawsuits in 2024 targeted websites that already had accessibility overlays installed. The FTC reached a $1 million settlement with an overlay provider for misleading compliance claims.

Overlays don't fix your code. They add a layer on top of broken HTML. Courts aren't buying it, and plaintiff's lawyers specifically look for overlay widgets as targets.

What Developers Should Do

94.8% of websites fail basic accessibility checks. The most common issues are things developers can fix:

Missing alt text on images — the #1 issue cited in lawsuits
Broken keyboard navigation — dropdowns, modals, and cart flows are common failures
Poor color contrast — easy to fix, constantly flagged
Missing form labels — screen reader users can't complete purchases without them

The Bottom Line

Accessibility lawsuits jumped 27% last year. AI is making them cheaper to file. The EU is actively enforcing. Overlays are being exposed. Every trend points to more lawsuits, targeting more businesses, in more places.

If you're a developer, accessibility isn't optional — it's a legal requirement that's getting enforced more aggressively every year.

Read the full breakdown with all the data: Website Accessibility Lawsuits Surged 27% in 2025. Here's Why 2026 Will Be Even Worse.

Accessible Modals: How to Build Dialogs That Don't Trap, Confuse, or Exclude Users

Denis Omerovic — Tue, 14 Apr 2026 20:17:29 +0000

Modals are everywhere. Cookie consent, login forms, confirmation dialogs, image lightboxes, newsletter signups, settings panels. The average user hits a modal within seconds of landing on most commercial websites. And most of those modals are broken for anyone not using a mouse.

We scanned over 15,000 pages through AccessGuard last quarter. Modal dialogs appeared on roughly 40 percent of them. Of the pages with modals, over 70 percent failed at least one WCAG criterion directly because of the modal itself, not the page behind it. The three most common failures were missing focus management, no keyboard escape route, and screen readers not knowing the modal existed.

This post covers every accessibility requirement for modal dialogs, what the relevant WCAG criteria actually say, and the exact code patterns that satisfy each one.

Why modals are uniquely dangerous for accessibility

A modal dialog does something no other UI pattern does: it demands exclusive attention. It sits on top of everything, it (should) prevent interaction with the page behind it, and it expects the user to deal with it before doing anything else.

For sighted mouse users, that contract is visually obvious. The backdrop dims, the box appears in the center, you click inside it or click the X to close it.

For everyone else, the contract is invisible unless you build it explicitly. A screen reader user has no idea a modal just appeared unless you tell their assistive technology. A keyboard user cannot "see" the backdrop and will tab straight out of the modal into the page behind it unless you trap focus.

The WCAG criteria that apply to modals

Modals touch a surprisingly large number of WCAG success criteria. Here are the ones that matter most:

4.1.2 Name, Role, Value (Level A). The modal must have role="dialog" or role="alertdialog", and it must have an accessible name via aria-labelledby or aria-label.

2.4.3 Focus Order (Level A). When the modal opens, focus must move into it. When it closes, focus must return to the element that triggered it.

2.1.2 No Keyboard Trap (Level A). The user must be able to leave the modal using the keyboard. The Escape key must close the modal.

2.1.1 Keyboard (Level A). Every interactive element inside the modal must be operable with a keyboard.

2.4.7 Focus Visible (Level AA). Focus indicators must be visible inside the modal.

1.4.3 Contrast (Level AA). The modal's text, buttons, and links need to meet 4.5:1 contrast ratios.

Use the native dialog element

The single biggest improvement you can make is to use the HTML <dialog> element. When opened with .showModal(), it gives you focus trapping, Escape to close, return focus, and a top layer — all for free.

<button id="open-btn" onclick="document.getElementById('my-dialog').showModal()">
  Open settings
</button>

<dialog id="my-dialog" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Settings</h2>
  <p>Adjust your notification preferences below.</p>
  <form method="dialog">
    <label for="email-notifications">
      <input type="checkbox" id="email-notifications" checked>
      Email notifications
    </label>
    <button type="submit">Save</button>
  </form>
</dialog>

No ARIA role needed (implicit). No JavaScript focus trap. No Escape key handler. No return-focus logic. Browser support is excellent across Chrome, Edge, Firefox, and Safari.

The close button problem

Almost every modal has an X button in the top-right corner. Almost every one of them is broken:

<!-- broken -->
<div class="close-btn" onclick="closeModal()">×</div>

This fails three criteria at once: not a button (2.1.1), no accessible name (4.1.2), and not focusable (2.4.7).

The fix:

<!-- fixed -->
<button type="button" aria-label="Close" onclick="closeModal()">
  <svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">
    <path d="M18 6L6 18M6 6l12 12" stroke="currentColor" stroke-width="2"/>
  </svg>
</button>

If you cannot use dialog: the manual checklist

Add role="dialog" and aria-labelledby and aria-modal="true"
Move focus into the modal on open
Trap focus inside the modal (Tab/Shift+Tab cycle)
Close on Escape
Return focus to the trigger on close
Make the backdrop inert with the inert attribute

Testing your modals in 5 minutes

Keyboard test: Tab to the trigger, press Enter. Does focus move into the modal? Does Tab cycle inside it? Does Escape close it? Does focus return?

Screen reader test: Turn on VoiceOver (Mac) or NVDA (Windows). Does it announce the dialog role and name? Can you navigate all content?

If either test fails at any step, you have a WCAG violation.

This is a cross-post from the AccessGuard blog where the full article includes detailed JavaScript code for manual focus trapping, alert dialog patterns, and a framework-by-framework breakdown (Bootstrap, React, SweetAlert, jQuery UI, Headless UI).

Want to check your own site? Run a free accessibility scan — no signup required.

WCAG 2.2 Has 9 New Criteria — Most Scanners Still Miss Them. Here's What They Are and How to Fix Them

Denis Omerovic — Fri, 10 Apr 2026 15:10:20 +0000

WCAG 2.2 shipped back in October 2023 with 9 new success criteria on top of WCAG 2.1. Almost two years later, most automated accessibility scanners still only catch one or two of them — the rest get punted to "manual review."

We just wrote up a deep dive into all 9 new criteria: what each one means in plain English, the most common real-world violations, and how to fix them. It's useful as a checklist regardless of which tools you use.

Here are the 3 highest-impact things you can check right now:

Your login form — Does autocomplete="current-password" exist? Does paste work on the password field? If you're blocking paste or setting autocomplete="off", you're failing 3.3.8 (Accessible Authentication).
Your help link — Is it in the same spot (header/footer) on every page? If it's in the nav on one page and buried in the body on another, that's a 3.2.6 (Consistent Help) issue.
Any drag interaction — Can a keyboard user do the same thing without dragging? If your Kanban board or sortable list has no keyboard alternative, that's a 2.5.7 (Dragging Movements) failure.

The full article covers all 9 criteria including Focus Not Obscured, Focus Appearance, Target Size (Minimum), Redundant Entry, and both levels of Accessible Authentication — with code examples and fixes for each.

👉 Read the full breakdown here

Would love to hear from anyone who's been auditing against WCAG 2.2 — what's been the hardest criterion to get right on your projects?

AltWizard: Generate SEO-Friendly Alt Text for Your Images Using AI

Denis Omerovic — Thu, 09 Apr 2026 12:50:42 +0000

Missing alt text is one of the most common accessibility issues on the web. It hurts SEO, leaves screen reader users in the dark, and often gets overlooked because writing good descriptions for every image takes time.

That's exactly why we built AltWizard — a free AI-powered tool inside AccessGuard that generates descriptive, SEO-friendly alt text for your images in seconds.

How It Works

Upload your images — drag and drop up to 10 images (JPEG, PNG, GIF, WebP, or AVIF, max 10MB each).
AI generates alt text — AltWizard analyzes each image and produces a clear, descriptive alt text.
Copy and use — grab the generated text and add it to your site. Done.

Images are automatically deleted after 24 hours for privacy.

Why Alt Text Matters

Accessibility: Screen readers rely on alt text to describe images to visually impaired users. Without it, images are invisible to them.
SEO: Search engines use alt text to understand image content. Good alt text helps your pages rank higher in image search and overall results.
Legal Compliance: Web accessibility regulations like WCAG, ADA, and EAA require meaningful alt text on images.

Who Is This For?

AltWizard is perfect for developers, content creators, marketing teams, and anyone who wants to make their website more accessible without spending hours writing image descriptions manually.

Try It Free

AltWizard is available now at https://getaccessguard.com/alt-wizard. No credit card required — just upload your images and get instant alt text.

If you care about building a more accessible web, give it a try and let us know what you think in the comments!

Why Your Clients' Websites Are Ticking Legal Time Bombs (And How to Fix It in 60 Seconds)

Denis Omerovic — Thu, 09 Apr 2026 12:36:49 +0000

If you build websites for clients — or run one yourself — there's a growing legal risk most people completely overlook: web accessibility lawsuits.

The Numbers Are Alarming

In 2025 alone, over 5,100 businesses were sued for website accessibility violations. And 69% of those were e-commerce stores.

The average settlement? $25,000 to $50,000 — and that's before legal fees.

Plaintiffs' attorneys don't manually browse websites looking for problems. They use automated scanning tools to identify targets. If your site has missing alt text, broken form labels, or poor keyboard navigation, you're on their radar.

It's Not Just a US Problem

The EU's European Accessibility Act is now in effect. If you sell to European customers, you're required to comply. Fines can reach €100,000 or 4% of your annual revenue.

The Problem With Most Accessibility Tools

Most accessibility scanners dump 500+ issues on you with zero context. No prioritization. No plain-English explanations. No fixes.

You're left staring at a wall of WCAG codes wondering where to even start.

Enter AccessGuard

We built AccessGuard specifically for business owners and developers who need to know:

What issues actually get businesses sued — not every theoretical violation, but the ones plaintiffs' lawyers specifically look for
What to fix first — every issue is ranked by lawsuit risk
How to fix it — AI-powered fixes you can copy-paste or send directly to your dev team

How It Works

Enter your website URL
Get a full scan in under 60 seconds
Receive a plain-English report with lawsuit risk rankings
Generate AI-powered code fixes with one click
Share reports with your team or download PDFs for legal records

It works with Shopify, WordPress, custom sites — anything with a URL.

Why This Matters for Developers

If you're a freelancer or agency developer, accessibility compliance is a massive value-add for your clients. You can:

Upsell accessibility audits using AccessGuard's scanning
Deliver fixes faster with AI-generated code
Protect your clients from lawsuits they don't see coming
Stand out from competitors who ignore accessibility

Try It Free

A scan takes 60 seconds and doesn't require a credit card.

👉 Scan your site for free at getaccessguard.com

Prevention costs a fraction of what a single lawsuit costs. Don't wait for the demand letter.

What's your experience with web accessibility? Have you or your clients ever received a demand letter? I'd love to hear your stories in the comments.

Day 7, zero signups. Pivoting my launch strategy in real-time.

Denis Omerovic — Sun, 08 Mar 2026 14:54:48 +0000

I launched AccessGuard 7 days ago. It's an AI-powered web accessibility scanner that checks sites against WCAG 2.1 AA/AAA standards and generates actual code fixes for every issue it finds.
Zero signups so far. Here's what happened and what I'm changing.

The product:
AccessGuard scans websites for accessibility issues - missing alt text, color contrast failures, broken keyboard navigation, missing form labels, etc. But instead of just flagging problems like every other scanner, it generates production-ready code fixes you can copy and deploy. It also prioritizes issues by lawsuit risk, so you know what to fix first.
I also built AltWizard - drag and drop images, get AI-generated alt text instantly.

Why I built it:
The market is genuinely huge and growing fast:

5,100+ ADA website lawsuits filed in 2025 (up 20% from 2024)
69% of lawsuits target e-commerce sites
EU Accessibility Act became enforceable June 2025 with fines up to €100K
Restaurants and fashion brands make up 60% of all lawsuits
456 businesses got sued despite having accessibility widgets installed
The FTC fined the largest widget provider $1M for misleading claims
Businesses are getting sued for $25K-$50K per case. A scanner that actually fixes issues should be a no-brainer purchase.

What I tried (and what failed):

Product Hunt launch - got buried. Hundreds of products launch daily.
Hacker News - posted, got no traction.
Reddit - multiple communities blocked me for promotion.
Twitter/LinkedIn - posted, got some likes, zero conversions.

The mistake was obvious in hindsight: The name of the app, there is too many with same name. I was marketing to developers and early adopters. My actual buyer is a scared restaurant owner in New York or a European e-commerce store that doesn't know they need EAA compliance.

What I'm doing differently today:

Cold emailing 47 businesses directly (restaurants in high-lawsuit US states + EU e-commerce companies that need EAA compliance). Leading with a free scan, not a pitch.
Partnering with web agencies - one agency converting means 10-100 client scans. They can upsell accessibility auditing to every client.
Writing SEO content targeting people who are actively searching for help - "WCAG issues that trigger lawsuits" type posts that will bring organic traffic for months.

This post. Being honest about what's not working.

The stack:

Rails 8
Resend for transactional email
25 automated WCAG checkers
AI-powered fix generation
Hosted on Hetzner

What I'm asking:
I'm not asking for upvotes. I'm asking for honest feedback:

If you run an e-commerce site or a web agency, would you use this? Why or why not?
Am I pricing wrong? (free tier with 3 scans, paid plans after)
What channels would you focus on to reach non-technical business owners?

I'll report back with real numbers from today's outreach. Emails sent, open rates, replies, signups - everything.

If you want to try it: https://getaccessguard.com - 3 free scans, no credit card.