This URL is a first contribution via accessibility: a labeled ticket, one element, contrast, alt, or keyboard. It is not a site-wide audit, a design-token migration, or CSS-in-general. Markup and stylesheet tickets that are not a11y-intent live on HTML and CSS good first issues — adjacent, not a rewrite of that post. It is not how to pick an issue that will get merged (mergeability of any ticket). It is not how to claim a GitHub issue.
The mergeable a11y evening is one control the issue already named. You do not invent a backlog.
Open the hubs, then filter for a11y
Start at the homepage if you still need a language. HTML and CSS are the usual first surface for labels, alt, and focus:
- HTML hub — markup, labels, landmarks,
alt - CSS hub — contrast, focus rings,
outline: nonethat was never replaced
Those feeds are language filters, not a11y-only. On the ticket, look for accessibility, a11y, good first issue, help wanted. Read the body. The label is a hint. The body is the job.
Generic hunting without a language: how to find good first issues. What the label even means: what is a good first issue.
Skip tickets that say “make the whole app WCAG.” That is a program, not a first PR. Skip “audit our site” with no file path. Skip “add aria everywhere.” One element is the filter this page uses.
One element, not the product
Shapes that maintainers can review in one pass:
- A form control with no
<label>, or aforthat points at a missingid - Contrast on one text/background pair the issue already named (hex or a screenshot in the ticket)
- Empty or missing
alton one image (or a wrongaltthat repeats the filename) - A focus ring a stylesheet deleted (
outline: none/outline: 0) with no replacement - A button that is a
<div onclick>the issue already identified — if they asked for a<button>, that is the patch - Keyboard: a dialog or menu the issue says cannot be reached or dismissed with Tab / Escape
Done is that element. It is not:
- A new color system
- Rewriting every
divto a landmark - Installing an a11y linter as the contribution
- Changing copy across the marketing site because you ran a scanner
If the issue lists three controls, pick one in the claim comment and do that one. Expanding the ticket in the PR is how reviews stall.
HTML/CSS technique that is not a11y (layout, a missing class name, docs site CSS) stays on HTML and CSS good first issues. Link it, then come back here when the intent is access.
Contrast, alt, keyboard — what to change
Contrast. Match the pair in the issue. Do not restyle the theme. If they quoted a failing color, change that color (or that text size) and say how you checked: browser inspector, a contrast checker, or the project’s existing token. Do not invent a new palette because the ticket mentioned gray.
Alt. Describe the image’s job in the UI, or use empty alt="" when the image is decorative and the issue said so. Do not write “image of…” filler. Do not stuff keywords. If the graphic is the only name of a control, the accessible name belongs on the control, not a novel in alt.
Keyboard. Tab order, a visible focus, Escape to close if the issue asked for it. Do not add a skip link to a page that did not request one. Do not trap focus in a modal they never mentioned.
Labels. Visible <label for="…"> is the default. aria-label is not a substitute you sprinkle because you did not want to touch markup. If the design has a visible label, wire for/id. If the issue says the visible text is already there and only the association is broken, fix the association.
Do not add role="button" on a <div> when they asked you to use a real <button>. Native elements are the first PR. ARIA is the exception the issue named.
How to test without a fake score
You do not need a certification. You do need to run what the issue described.
- Keyboard only: Tab to the control, activate it, Escape if it is a dialog
- One screen reader pass if the issue asked for it and you have VoiceOver, NVDA, or the project’s documented tool — say which, say what you heard
- Contrast: the pair they named, not a site-wide report
Do not paste a Lighthouse number as proof you fixed the ticket. Do not claim WCAG conformance for the product. The PR is the element.
How you describe that check belongs in the pull request description: what changed, how you tested. Screenshots of focus rings and contrast are useful here; a parser test is not.
What to skip
Scanner dumps. Opening 40 issues from an automated crawl is not a contribution. One labeled ticket is.
Unlabeled drive-bys. Filing “this button is inaccessible” with no repro, no expected/actual, no versions is a bad report. If you must file, that is how to write a useful GitHub issue — then wait. This page assumes the ticket exists.
Framework rewrites. “Switch this app to a different UI kit for a11y” is not a first issue.
Docs-only a11y essays. A CONTRIBUTING paragraph can be a first PR if they asked for it. A blog post in their repo about WCAG is not this URL.
After the PR, after your first open source contribution is stay or leave. Review comments: how to respond to code review.
Claim, patch, stop
Read CONTRIBUTING. Claim once. Change the one element. Open the PR against the branch they named.
If the hub shows a quiet repo, drop it. Activity is how to tell if an open source project is active.
Need a different language after this? Back to the homepage. Still on markup or styles? HTML and CSS hubs. The adjacent HTML/CSS post is for tickets that are not a11y-intent. This page stays on access: one labeled issue, one element.