Create and Merge a GitHub Pull Request with a Screen Reader

This is Part 5 of the GitHub series. The walkthrough uses NVDA and Brave on Windows, then an Ubuntu terminal to update the local repository. You will need a repository on GitHub, a branch with committed changes already pushed, and permission to merge into the destination branch.

Start with creating and pushing a Git branch, then review your changes in Part 4: comparing branches. Check your working tree before switching branches so that uncommitted work is accounted for.

Open the repository on GitHub and select the branch you pushed. In NVDA browse mode, D moves through landmarks, H through headings, and K through links. NVDA+Ctrl+F opens NVDA find; searching for “Contribute” can help locate the menu used in the recording. Open Contribute and choose Open pull request.

Check the direction before continuing. The base branch receives the changes; the compare branch supplies them. This example merges the working branch into main. Your repository may use a different default or destination branch, so verify both selectors.

GitHub page labels and layout can change. Follow the control names announced by your screen reader and use Tab when moving through the form.

Use a title that explains the change. The branch-style title in the recording is a personal convention, not a GitHub requirement. A concise title such as “Document the pull request workflow” also works.

Give reviewers enough context to understand the purpose, key changes, testing performed, and anything that needs attention. Include a related issue or ticket when relevant. Only claim tests that you actually ran.

A Markdown heading such as ## Detailed PR Description becomes a level-two heading in the rendered description. That structure helps screen reader users navigate. Review the description, then activate Create pull request.

After creation, use headings to find the pull request description and merge section. Wait for GitHub to finish checking mergeability. Read the review requirements and status checks for the repository before merging.

“No conflicts” means GitHub can combine these changes without resolving a merge conflict. It does not prove that the branch contains every recent commit from main, that tests passed, or that the changes are correct.

GitHub can offer a merge commit, squash and merge, or rebase and merge, depending on repository settings and permissions. The recording uses a merge commit. Select the appropriate method, review the proposed commit message, activate Merge pull request, and confirm the merge.

Once GitHub reports that the pull request is merged, the Delete branch control removes the remote branch on GitHub. It does not remove your local branch. See GitHub’s merge methods and merge conflict reference.

Return to your local repository in the terminal. Check for uncommitted work, then switch to the destination branch. In this example, that is main.

Before fetching, git status compares your branch with the last remote-tracking information stored on your computer. An “up to date” message is not a live query of GitHub. Run git fetch to refresh that information, then check status again.

Git fetch downloads objects and updates remote-tracking references without integrating those changes into your checked-out branch. Git pull fetches and then integrates according to your options and configuration. This example can fast-forward local main to the merged remote history. The local fast-forward is separate from the merge method selected on GitHub.

If Git reports local changes, diverged branches, or conflicts, stop and inspect the situation before choosing how to proceed. See the official git fetch and git pull documentation.

git log -1 limits the output to the latest commit. In this merge-commit example, check the commit message and branch references to confirm that local main points to the expected result. Other merge methods produce different history, so a merge commit is not required in every workflow.

To review terminal lines with NVDA, the desktop layout uses Numpad 7 for the previous line, Numpad 8 for the current line, and Numpad 9 for the next line, with Num Lock off. In the laptop layout, use NVDA+Up Arrow, NVDA+Shift+period, and NVDA+Down Arrow respectively. The NVDA modifier is whichever key you configured, such as Insert or Caps Lock. Consult the NVDA User Guide for your keyboard layout.

If git log opens the usual less pager, press q to quit. You normally do not need a colon or Enter. Pager behavior depends on your Git configuration. For a short check without a pager, run git --no-pager log -1.

You have now taken a pushed branch through a pull request and brought the result back to your local repository. Before starting the next change, confirm that you are on the intended branch and that your working tree is clean.