Website Responsibility Scanner

An open-source tool for checking how sustainable & accessible websites really are

Most people have no idea that their websites pump out more carbon emissions than they’d like, and even when they do, they’re usually left scratching their heads about what to do about it. Meanwhile, even with new rules like the European Accessibility Act (EAA) in play, accessibility is still too often overlooked or thrown aside as too difficult to manage. The auditing tools that are out there aren’t helping either: they’re expensive, closed-source, or both, which leaves smaller agencies, non-profits, and independent devs out in the cold.

We want to change that. This project is about building an open-source website scanner that checks both sustainability and accessibility. On the sustainability side, it will check things like page weight, image and script optimization, caching effectiveness, and whether your hosting is actually green. For accessibility, it will check for compliance with the Web Content Accessibility Guidelines (WCAG). And when it finds a problem, it will give you clear, practical guidance instead of just spitting out technical jargon.

The architecture is going to be modular, so every check is self-contained. A backend does the scanning and provides an API, while a frontend makes it easy to run audits and see what’s going on. All checks will come with solid documentation: what they do, why it matters, and how to fix things. You can run the tool locally, add new features, or even self-host it yourself – no gatekeeping, no hidden fees. Just a tool that can help everyone build a better web.

Target Audience

• TL;DR: If you know how to code, design, write, or break down tough concepts into everyday language, we’ve got a spot for you.
• PHP Developers: You’ll build the checks and provide them over an API.
• Designers and JavaScript Developers: You’ll shape a frontend that will turn complicated scan results into a clean interface easy for everyone to use.
• Subject-Matter Experts: You know the WCAG, are familiar with the EAA, or have a passion for web sustainability. Your job is to make sure every check we run is actually useful.
• Content Writers: You explain what each check does, why it’s important, and how to fix problems in simple language anyone can follow.
• Technical Writers: You write straightforward documentation on self-hosting, contributing, and using the API, so nobody gets lost.
• Marketers: You create quick-start guides and materials so teams can jump in and get moving right after the hackathon.

Hackathon Goals

1. Develop an MVP able to scan any given URL and generate a report.
2. Ensure users can access results through a simple, user-friendly interface.
3. Add checks to validate sustainability. The team will decide which specific checks to include based on everyone’s expertise.
4. Add checks to validate accessibility based on WCAG standards.
5. Give concrete, actionable suggestions for every issue the tool detects, with clear guidance on how to resolve them.
6. Provide detailed documentation for each check: what it does, why it is important, and how users can make improvements.

Results

What We Built

Give the Website Responsibility Scanner a URL and it’ll audit the site for accessibility problems and environmental impact at the same time. It’s open-source, it runs checks across six modules, and it hands back a scored report with the issues it found and concrete steps to fix them. The whole point was to make this stuff actionable for people who aren’t deep in WCAG specs or carbon accounting.

The tool wires together Google Lighthouse and axe-core for accessibility testing against WCAG standards, the Green Web Foundation’s directory for hosting sustainability checks, and CO2.js with the Sustainable Web Design Model v4 for carbon footprint estimation. Carbon calculations factor in the user’s country and its average grid intensity, then break emissions down by segment: data centres, networks, end-user devices, so site owners can see where the energy cost actually lands. Findings from Lighthouse and axe-core get deduplicated and merged, which means the same issue won’t surface twice from different engines. Every piece of technical jargon in the results also gets translated into language a non-technical user can genuinely act on.

On the technical side, we built a Laravel API backend with a React frontend. Results export as JSON, PDF, or via shareable permanent links. Scan history persists so users can track changes over time. The backend runs collectors in parallel for faster scan times, and an automated release pipeline through GitHub Actions and release-please handles deployment to a Cloudron instance.

What We Achieved

In two and a half days, the team shipped 154 commits across roughly 50 merged pull requests and pushed 12 production releases (about one release every four hours). We built the entire foundation and hit every goal we set, stretch goals included (full performance checks among them). By the end, the scanner covered accessibility, sustainability, green hosting, carbon footprint, media sustainability, and design analysis.

The work also went beyond code: We put together a brand identity with logo and design system, defined personas and user stories, wrote social media posts, recorded a podcast spot, drafted a press release, shot a demo video, and gave the final presentation. All of that happened in parallel with engineering. The result felt like a real product launch preparation that goes beyond a weekend hack.

The Team

Eight people across so many different backgrounds: software engineers, a UX designer, a visual designer, an accessibility consultant, marketers, content writers, and a project manager. Nobody stayed in their lane. People picked up whatever needed doing, whether or not it matched their job title, and every person’s work can be found in the final result. It was such a fun weekend. We made deep connections fast and built something we’re all proud of.

• Alena Hackradt
• Milian Hackradt,
• Maja Benke
• Patrice Bender
• Andreas Heigl
• Christopher Kurth
• Marius Perle
• Maurice Müller
• Stefan Schleyer
• Ekaterina Streltsova

What’s Next?

We really hope the hackathon was only the first step of this project.

An accessibility expert who was also part of the hackathon gave our own tool a thorough audit during the hackathon, and fixing every issue in that report is where we start. A tool that checks others for accessibility needs to get its own house in order first. After that, we want to make the scanner significantly easier to deploy and run. Setup takes more steps than we’d like right now, and lowering that barrier matters if we want people to actually self-host it.

We’re also planning to expand what the scanner checks. Security is a likely next area since it’s a natural fit alongside accessibility and sustainability, and something site owners already care about. The plain-language explanations we built during the hackathon do their job, but we think we can push them further and get more specific, closer to “do exactly this” than “consider doing something like this.”

We’d love for team members to stay involved as the project continues, and we’re hoping to attract contributors from outside the original group as well.

Project Links

• GitHub: https://github.com/cfhack2026-wrs
• https://www.gesellschaft-zur-entwicklung-von-dingen.de/en/magazine/our-2026-hackathon-project-website-responsibility-scanner
• https://christopherkurth.com/en/event/recap-cfhack2026/