I’ve spent most of my time building personal projects, so I wanted to try something different: contributing to a real open-source project. For my first contribution, I chose VitePress, a static site generator powered by Vue. I came across issue #5530, which reported an accessibility problem with code groups.
Understanding the Problem
VitePress code groups let users switch between alternative code snippets using tabs. For example, a documentation page might show the same configuration in JavaScript and TypeScript.
Behind the scenes, these tabs use native radio inputs and labels. The problem was that the element wrapping these controls didn’t explicitly identify itself as a radio group or provide an accessible name. This could make it harder for assistive technologies to communicate the relationship between the options.
At first, it seemed like a small markup issue, but I needed to understand how the renderer generated the HTML and how the client-side code handled tab switching before changing anything.
The Fix
I traced the code-group rendering logic in src/node/markdown/plugins/containers.ts and checked the tab-switching logic in src/client/app/composables/codeGroups.ts.
One important detail was that the existing JavaScript depended on the current DOM hierarchy. Adding unnecessary wrapper elements could have broken tab switching.
I kept the change minimal by adding role="radiogroup" and aria-label="Code group" to the existing .tabs element. I also updated the corresponding unit test and its inline snapshot to verify the new markup while preserving the existing radio inputs, labels, and code panels.
Testing and What I Learned
I ran the focused code-group tests, followed by the full unit test suite. All 517 unit tests passed across 32 test files. Type checking, formatting checks, and the Git diff integrity check also passed.
I used AI as a coding assistant to help investigate the unfamiliar codebase and explore possible approaches. However, I treated its suggestions as things to verify, not answers to trust blindly. I inspected the actual implementation and dependencies between components, reviewed the diff, and ran the project's checks.
One of the harder parts was getting the development tooling working on Windows before I could run the tests. It reminded me that contributing involves more than writing code: understanding the project, respecting its conventions, and verifying changes are equally important.
This is my first step into open source, and I'm looking forward to learning from the maintainers' feedback. The PR is awaiting review, and I haven't yet performed a live screen-reader accessibility audit.
Issue: VitePress #5530
Pull request: [Add your PR URL here]
Thanks to the VitePress maintainers and contributors for building and maintaining an open-source project that developers can learn from and contribute to.
Top comments (0)