Yo @mlama007 — this is exactly what OSS needs.
The "Nothing about us without us" point is crucial. It's easy to treat a11y as an afterthought, but building it into the PR checklist and CI from day one changes the game.
That ACCESSIBILITY.md template is a clutch starting point for maintainers who want to do better but don't know where to start. Big ups for putting this together! 🎉

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

Strong points:

1. "Nothing about us without us" as the anchor message is the right framing — a11y guides that skip this and jump straight to WCAG checklists 2) tend to get ignored by maintainers
2. Baking it into PR/issue templates + CI is the actual lever that makes it stick, vs. a one-time README fix
   Starting small (ACCESSIBILITY.md, keyboard nav, alt text) is realistic for volunteer maintainers with zero bandwidth

One gap worth flagging: guides like this often get bookmarked and never applied. Worth adding a "5-minute audit" section — e.g. "run axe DevTools or Lighthouse on your site right now, fix the top 3 flagged issues" — gives people an immediate dopamine hit instead of a backlog item.

This is a practical guide, especially the focus on making accessibility part of the regular development workflow instead of an afterthought. Thanks for sharing, and I’d also recommend 666p game.

Thanks for publishing this — the “bake a11y into PR checklist + CI” framing is what actually moves OSS maintainers.

A few concrete patterns that work well as drive-by a11y contributions (Playwright / ARIA / reduced-motion):

Fast high-value issues for first-timers

• Icon-only controls → aria-label / aria-labelledby (remove / close / play are endless GFIs)
• prefers-reduced-motion on landing heroes, count-ups, and dialogs
• Skip link + a single <main id="…"> target (often missing on marketing shells)
• Contrast — not only hex tokens, but composited alpha over real backgrounds in tests

CI that stays honest

• Prefer @axe-core/playwright (or similar) on 2–3 critical routes over huge unit snapshot suites nobody updates
• Gate new violations as errors; never “log and green” without a baseline

Review culture

When reviewing, ask: can I operate this with keyboard only? If not, file a good first issue with file paths — that’s how a11y compounds in busy repos.

The ACCESSIBILITY.md + issue/PR templates you linked are a strong starter kit.

If this is about landmark structure: one main, labelled nav (aria-label), and a skip link cover most automated audits. Contrast (4.5:1 body text) and form labels usually move WCAG score more than decorative ARIA.

Nice writeup — the "5-minute audit" and "drive-by contribution" ideas in the replies above are underrated. Most a11y guides fail because they read like a compliance doc, not a task list someone can knock out in a coffee break.

One thing I'd add for maintainers who are just getting started: don't try to fix everything flagged by an automated scanner in one PR. axe/Lighthouse will dump 40+ issues on a legacy repo and that's enough to make anyone close the tab. Pick one category per week — alt text this week, form labels next, focus states after that. Small, mergeable diffs > one giant "accessibility overhaul" PR that never gets reviewed.

Also +1 to labeling good first issue for a11y fixes specifically — most of them (missing labels, icon-only buttons, focus order) are genuinely approachable for new contributors, and it's a great on-ramp into the codebase that doesn't require understanding the whole architecture first