u/Bulky_Barracuda5727

I just launched V1 of a small app idea called FrontPR.

It is a GitHub Action for frontend projects. The goal is to help developers catch issues inside pull requests before merging.

The current version scans frontend projects for accessibility issues using axe-core. It should work with common frontend stacks like React, Vite, TypeScript, etc.

The product direction I am considering is broader than accessibility. Possible future checks include:

• GDPR/cookie consent behavior
• broken production links
• broken privacy/legal/trust pages
• SEO metadata issues
• basic frontend security checks
• AI-generated code risk detection
• AI-suggested fixes for PR issues

Before building more, I want to validate whether this workflow actually matters to developers.

V1 is still early, but it is free to try. No credit card. You can sign up with GitHub or email.

Would appreciate feedback on the idea, the setup, and whether you’d be willing to test an early version on a small frontend project.

Link: www.frontprdev.com

How many of you use github for your apps?

Personally i host my frontend on lovable and it never touches github.
But my backend is where i work with my teammates and we use github to do everything right.

The frontend feels more just like, fuck it, connect some apis and its done and we all use the same lovable account.

We are a small small team of three, so we never run into ”merge conflicts on lovable” cuz we have open communications.

How many of you use github for your apps?

Personally i host my frontend on lovable and it never touches github.
But my backend is where i work with my teammates and we use github to do everything right.

The frontend feels more just like, fuck it, connect some apis and its done and we all use the same lovable account.

We are a small small team of three, so we never run into ”merge conflicts on lovable” cuz we have open communications.

I’m thinking about building a small GitHub Action that checks for common accessibility issues before deploy.

The idea is simple:

When you open a PR or push changes, it runs accessibility checks and comments directly on the PR if it finds obvious issues.

For example:

• missing alt text
• buttons/icons without accessible labels
• bad color contrast
• form inputs without labels
• ARIA mistakes
• possible keyboard navigation issues

Not meant to be a full WCAG audit or replace proper accessibility testing. More like a lightweight guardrail that catches the obvious stuff before it ships.

Something like:

>

I originally started thinking about this after reading more about WCAG and the European Accessibility Act in the EU. I realized accessibility is something many smaller projects probably don’t check consistently, especially when building fast with tools like Lovable, Bolt, Cursor, Claude, etc.

Could be useful for vibe-coded apps, indie projects, and small teams that want a basic accessibility check inside their GitHub workflow.

First version would probably just warn and explain the issues. Later it could maybe suggest fixes or create patch suggestions.

Would this be a cool GitHub project to build, or does something already solve this well enough?

I’ve recently been reading more about WCAG and the European Accessibility Act in the EU.

I’m a developer, but to be honest, accessibility is something I haven’t thought about that seriously before. I’ve built apps and websites, but not really products where paying customers, procurement, legal requirements, or compliance pressure made accessibility a major concern.

That made me think about a simple idea:

What if there was a GitHub Action that ran on pull requests or pushes, checked for common accessibility issues, and left comments directly in the PR?

Things like:

• missing alt text
• buttons or icons without accessible labels
• contrast problems
• keyboard navigation issues
• ARIA mistakes
• form inputs missing proper labels

Not a huge enterprise platform or full consultant-style audit. More like a lightweight guardrail that says:

>

Later it could maybe suggest fixes, but the first version would mostly be warnings, explanations, and links to what needs changing.

I’m curious if other devs here think about this at all.

I see people talk a lot about performance, SEO, clean code, testing, DX, CI/CD, etc. But accessibility feels like something many smaller teams don’t focus on unless they already had a reason to care.

Maybe that’s just because I haven’t worked on a product where it became a serious issue yet. But with the EU rules coming in, I’m wondering if smaller teams will start caring earlier, or if this will still mostly be something bigger companies deal with.

Would something like this be useful in your workflow, or would it probably become another noisy CI check that people ignore?

I recently started reading more about WCAG and the European Accessibility Act in the EU.

I’m a developer, and honestly I realized I’ve never really thought that deeply about accessibility. I’ve built apps, but not the kind of app where customers, procurement, legal requirements, or real revenue make these things matter more.

So I started thinking about a simple idea:

What if you had a GitHub Action that runs on every pull request or push, checks for common accessibility issues, and comments directly on the PR?

For example:

• missing alt text
• buttons without accessible labels
• bad color contrast
• broken keyboard navigation
• ARIA issues
• form inputs without proper labels

Nothing too enterprise or consultant-heavy. Just a lightweight check that tells you:
“this change introduced these accessibility problems before you deploy.”

Maybe later it could suggest fixes too, but at first it would just be warnings and explanations.

I’m also curious if other people here have thought about this at all.

I feel like I’ve seen a lot of people talk about performance, SEO, clean code, DX, testing, CI/CD, etc. But accessibility is something I personally never really paid much attention to, at least not beyond the basic “add alt text” level.

Maybe that’s just because I haven’t worked on a product where it became a real issue yet. But with the EU rules coming in, I’m wondering if this is something more small teams will actually need to think about, or if it’s still mostly a concern for bigger companies.

Would a GitHub Action like this be useful, or just nahh dont need it?

For people building apps with Lovable, Cursor, v0, Bolt, etc — do you check accessibility before shipping?

I don’t mean full legal compliance audits. I mean basic frontend issues like:

• inputs without proper labels
• buttons/icons with no accessible name
• poor color contrast
• broken keyboard navigation
• modals/dropdowns that are hard to use without a mouse

The idea I’m exploring is a small GitHub Action that runs on PRs or preview deploys and comments only on new accessibility issues introduced by that change.

So instead of a huge report saying “your app has 80 issues”, it would say something like:

“This PR introduced 3 accessibility issues. Here’s where they are and how to fix them.”

Later, it could maybe suggest code fixes too, but only after approval.

I’m not sure if this is actually useful or if most people would ignore accessibility unless a client/legal requirement forced it.

A few questions:

1. Do you currently check accessibility at all?
2. Would a GitHub Action fit your workflow, or would you prefer CLI/dashboard?
3. Should serious issues block merges, or only leave comments?
4. Would this be worth paying for, or is it more of a nice-to-have?

Trying to figure out if this is a real workflow problem before building too much.