-
Notifications
You must be signed in to change notification settings - Fork 0
Introduction to CM Research
Where we figure out what actually works (and what definitely doesn't)
Welcome to our research corner! This is where we dig into the real questions, test our assumptions, and occasionally discover that what we thought we knew was completely wrong.
Not here for academic papers? That's fine! Each section has a TL;DR so you can grab what you need and get back to building cool stuff.
We're not writing papers for professors. We're collecting insights that help developers, designers, and product folks build better experiences. Think of it as "research that actually matters to real people doing real work."
Start here: Browse our current research issues to see what questions we're actively investigating.
How it works:
- Browse issues: Look for topics that interest you
- Claim an issue: Comment on an unassigned issue to claim it
- Alternative perspectives: If you have a different take on a claimed issue, create a new issue and reference the original
- Check in: Update progress by the end of week 1
- Contribute: Submit your research following our templates
| Research Type | Typical Duration | Week 1 Check-in Required |
|---|---|---|
| Literature Review | 2-3 weeks | Progress update on sources found and initial insights |
| Case Study | 1-2 weeks | Community identified and initial data collection started |
| Tools Collection | 2-3 weeks | Scope defined and initial tool inventory completed |
| Research Proposal | 1 week | Draft problem statement and proposed methodology |
| Tech Proposal | 1-2 weeks | Technical approach outlined and feasibility assessed |
For newcomers: We provide templates and examples. Focus on clarity and practical insights over academic rigor.
For experts: Maintain the accessible tone while bringing your expertise to bear. Help translate complex concepts for developers and designers.
For everyone:
- Back claims with evidence
- Write for practitioners, not academics
- Include actionable takeaways
- Be honest about limitations
"What does the actual science say about [insert topic]?"
The Deal: Academic papers are often locked behind paywalls and written in language that requires a decoder ring. We read them so you don't have to, then translate the useful bits into human speak.
What Goes Here:
- Summaries of research papers (in plain English)
- "So what does this mean for my app?" sections
- Debunking of common myths
- Evidence for/against popular practices
# What Research Says About [Topic]
## TL;DR (2-3 sentences max)
The key findings that matter to you
## The Problem We're Investigating
Why should you care about this?
## What the Studies Found
- Main findings (no jargon!)
- Sample sizes and study quality
- What's actually proven vs. what's just theory
## So What?
How this affects your design/dev decisions
## The Fine Print
- Links to original papers
- Study limitations
- What we still don't know
## Next Steps
What should we investigate next?
"What's actually happening out there in the real world"
The Deal: Comprehensive summaries of experiences from specific communities or user groups around accessibility challenges. We dig into forums, communities, and real-world examples to understand what people are actually dealing with.
What Goes Here:
- Community-wide experiences (e.g., "How Reddit users with vestibular disorders experience high contrast")
- Developer community challenges ("What accessibility tools are React devs actually using?")
- User group analyses ("Mobile users with motor impairments and touch targets")
- Cross-platform accessibility experiences
Template:
# Case Study: [Community/Audience] and [Accessibility Topic]
## TL;DR
Key findings about this group's experiences
## The Community/Audience
- Who are we looking at?
- Size and characteristics of the group
- Where did we gather information?
## Current Experiences
- What challenges do they face?
- What works well for them?
- Common patterns and pain points
## Evidence Collected
- Forum discussions, testimonials, surveys
- Screenshots, videos, documentation
- Community responses and engagement
## Impact Analysis
- How widespread are these issues?
- Who else might be affected?
- Severity and frequency of problems
## Takeaways for Developers
Concrete lessons and recommendations
## Gaps and Opportunities
What's missing that could help this community?
## Questions for Further Research
What should we investigate next?
"The complete landscape of what's already out there"
The Deal: Comprehensive overviews of existing tools, libraries, and solutions in specific accessibility domains. We map out entire ecosystems so you can see what exists, what's missing, and what works together.
What Goes Here:
- Complete surveys of tools in specific areas (e.g., "All color accessibility tools")
- Ecosystem analyses (e.g., "React accessibility library landscape")
- Integration compatibility studies
- Gap analyses across tool categories
Template:
# Tools Collection: [Domain/Category] Accessibility Tools
## TL;DR
Overview of the landscape and key findings
## Scope and Methodology
- What area are we covering?
- How did we find and evaluate tools?
- Criteria used for assessment
## The Full Landscape
### Established Players
Major tools everyone knows about
### Hidden Gems
Lesser-known but valuable tools
### Specialized Solutions
Tools for specific use cases
### Developer-Focused vs. User-Focused
Different tool categories and their audiences
## Comparative Analysis
- Feature comparison matrices
- Pricing and licensing overview
- Integration compatibility
- Performance comparisons
## Ecosystem Gaps
- What's missing?
- Overlapping functionality
- Integration challenges
## Recommendations by Use Case
Who should use what and when
## Future Landscape
- Emerging tools and trends
- Areas ripe for innovation
"Questions we should definitely investigate"
The Deal: Ideas for studies, surveys, or investigations that would help the community. These can come from anyone - you don't need a PhD to spot a good research question.
What Goes Here:
- Community-suggested research questions
- "We need data on X" requests
- Proposed user studies
- Technical investigations
Template:
# Research Proposal: [Question/Topic]
## TL;DR
What we want to find out and why
## The Question
What exactly are we trying to answer?
## Why This Matters
- Who would benefit from knowing this?
- What decisions could this inform?
- What problems might this solve?
## Current State
What do we know/not know right now?
## Proposed Approach
- How could we investigate this?
- What kind of data would we need?
- Who should we talk to?
## Resources Needed
- Time, tools, people
- Budget considerations
- Community involvement
## Expected Outcomes
What we hope to learn
## Get Involved
How people can contribute to this research
"Here's how we could actually build this thing"
The Deal: Implementation ideas that come from research findings. Bridge between "we learned X" and "so let's build Y."
What Goes Here:
- Technical approaches to research-backed solutions
- Architecture proposals
- Algorithm ideas
- "Someone should build this" suggestions
Template:
# Tech Proposal: [Solution Name]
## TL;DR
What we want to build and why
## The Problem
What research/case study led to this idea?
## Proposed Solution
High-level approach (with code examples if helpful)
## Technical Approach
- Core algorithms/methods
- Platform considerations
- Performance expectations
- Integration points
## Feasibility Check
- Technical complexity
- Resource requirements
- Existing libraries we could use
## Success Criteria
How would we know this works?
## Implementation Roadmap
Rough timeline and milestones
## Open Questions
What needs more research before building?
## Call for Contributors
What kind of help do we need?
Terms that can't be simplified (but we'll try anyway)
The Rule: If there's a simpler way to say it, use that instead. Only include terms that are unavoidable.
Format: Term: Simple definition first, then technical definition if needed Example: How it's used in practice
- Clarity over complexity: If a 12-year-old can't understand your TL;DR, rewrite it
- Evidence over opinion: Back up claims with sources, but explain why they matter
- Practical over theoretical: Focus on what people can actually use
- Honest over promotional: If something sucks, say it sucks (constructively)
- Community feedback period (1 week for major contributions)
- Fact-check for claims and citations
- Readability check (does this actually help developers?)
- Integration review (does this fit with our existing work?)
- Use "you" not "one" or "users"
- Explain acronyms on first use
- Include code examples when helpful
- Add humor if it serves a purpose (not just for the sake of it)
- Link liberally but don't assume people will click
What we're most curious about right now
- Vestibular disorders and color triggers (stemming from Reddit community feedback)
- Developer adoption barriers for accessibility tools
- Cross-cultural color perception differences
- Performance impact of real-time accessibility adjustments
Questions about contributing research? Open an issue and tag it with research-question. We're here to help, not gatekeep.
Making accessibility research actually accessible, one plain-English explanation at a time 🌈🔬