A home in a seaside forest where we're building bridges across the accessibility gap—because the stakes are deeply human.

Comfort Commons is an open-source community creating tools that help developers take their first steps toward accessibility. We're not here to automate everything or promise instant solutions. We're here to handle the mechanical stuff so you can focus on the human stuff.

We bring together people who experience the web in different ways: those who need higher contrast, those who get dizzy from certain animations, those who navigate by keyboard, those who use screen readers, and those who just want the web to stop being so overwhelming. We also bring together developers at every stage—from students building their first site to experienced engineers maintaining dozens of projects—who want to do better but don't know where to start.

Everything we build is open-source, free, and built by this community. Including you, if you'd like.

Heads up: Comfort Mode Toolkit is a living project—research, tools, and docs here are a work in progress!
We're always iterating, learning, and adding new things. Your feedback and contributions shape where we go next.

Here's the reality: accessibility sits at the intersection of conflicting needs, where the stakes are deeply human.

Accessibility advocates have valid concerns:

• They've seen tools promise "instant accessibility" while making things worse
• They've watched automation become an excuse for not hiring experts
• They've experienced the trauma of broken implementations that harm users
• They know that context, nuance, and human judgment matter

Developers have valid struggles:

• WCAG is 78 pages of technical standards
• A junior dev building their first portfolio shouldn't need years of expertise
• Perfect accessibility vs. shipping anything feels impossible
• They genuinely want to help but don't know where to start

Both perspectives are right. And that's exactly why we exist.

We're not building tools that "solve accessibility." We're building training wheels with warnings—tools that:

✅ Handle the mechanical stuff (things we can verify are 100% correct)
⚠️ Warn about judgment calls (things that need human review)
🚫 Document what they can't do (things that require context only you have)

Think of it like Grammarly for accessibility: it catches obvious mistakes so you can focus on the harder problems. It doesn't make you an expert, but it helps you avoid common pitfalls while you learn.

We believe:

• 70% accessible is better than 0% accessible (but we're honest that it's not 100%)
• Reducing barriers is valuable work, even if it's not solving everything
• Progressive improvement deserves the same grace we give to security, performance, and code quality
• Tools should teach, not just automate

We don't believe:

• Automation can replace accessibility expertise
• These tools are the end goal (they're step 1 of 10)
• One-size-fits-all solutions work for human problems
• Checking compliance boxes equals good user experience

What it does: Takes your color palette and makes minimal adjustments to meet contrast requirements. You pick your colors, we make them readable.

What it doesn't do: Tell you if your color choices make sense for your content, determine if your design is usable, or replace color theory expertise.

Why this matters: The math of color contrast is mechanical—a tool can handle it. The meaning of your color choices is human—only you can decide that.

What it will do: Catch mechanical form errors (missing labels, broken connections) and warn about ambiguous cases (generic button text, unclear purposes).

What it won't do: Write meaningful label text, determine if your form makes sense, test with real screen reader users, or guarantee WCAG compliance.

Why this matters: Linking a label to an input is mechanical. Writing a label that actually helps someone understand what to enter is human.

We're currently investigating:

• Which form accessibility errors can be safely automated vs. which require human judgment
• How certain color combinations affect people with vestibular challenges
• Why developers struggle to adopt accessibility tools (and how to lower that barrier)
• How color meaning and accessibility needs vary across cultures

We believe in radical transparency. Here's what these tools will never do:

❌ Replace accessibility expertise
❌ Guarantee your site is accessible
❌ Test with real users who rely on assistive technology
❌ Understand the context of your content
❌ Write clear, helpful text that makes sense for your users
❌ Make design decisions about usability

These tools catch mechanical errors. You still need to:

✅ Write clear, descriptive text
✅ Test with keyboard navigation
✅ Consider real user flows
✅ Learn accessibility fundamentals
✅ Consider hiring accessibility consultants for critical applications

We follow a cycle that keeps real people and real constraints at the center:

1. Someone shares a real problem they're experiencing on either side (as a user or as a developer)
2. We research together what can be automated safely vs. what needs human judgment
3. We build practical tools that fit into real workflows without making false promises
4. We test with actual humans to see if it helps (and if it causes any harm)
5. We improve based on honest feedback about what works and what doesn't

Everything happens in the open. You can watch, participate, or just lurk. All are welcome.

If you're a developer who:

• Wants to do better but feels overwhelmed by where to start
• Maintains multiple projects and can't become an accessibility expert overnight
• Knows the basics but keeps missing mechanical errors
• Wants tools that teach while they help

If you're an accessibility advocate who:

• Is tired of tools that promise the moon and deliver harm
• Wants to help developers succeed without lowering standards
• Believes in meeting people where they are
• Thinks progressive improvement is better than paralysis

If you're someone who uses the web and:

• Needs higher contrast, clearer labels, or keyboard navigation
• Is tired of sites that ignore basic accessibility
• Wants to help make things better
• Has experienced both good and bad attempts at accessibility

Whether you've never contributed to open source before or you're an experienced developer or accessibility practitioner, there's a place for you here.

You don't need permission to participate. Comment on an issue, ask a question, share an idea, tell us what we're getting wrong. That's contributing.

Building bridges to help people cross—one small, honest improvement at a time.

We're not here to solve accessibility. We're here to help you take the next step.