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 moves things around from time to time, so go by the control names NVDA announces and use Tab to move through the form.

Use a title that explains the change. In the recording I use my branch name as the title, which is just my habit. A short title such as “Document the pull request workflow” works too.

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” only means GitHub can combine the changes without you resolving anything. It does not mean the tests passed or the code is right.

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 the latest information without changing your files. Git pull fetches and then brings those changes into your current branch. In this example, pull simply moves local main forward to match GitHub.

If Git reports local changes, diverged branches, or conflicts, stop and read what it says before going further. See the official git fetch and git pull documentation.

git log -1 shows just the latest commit. In my example that is the merge commit, and I check its message and branch names to confirm local main matches GitHub. If your repository uses squash or rebase merges, the history will look different.

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. The NVDA User Guide lists both layouts.

If git log opens the pager, press q to quit. For a quick check without the pager, run git --no-pager log -1.

And there we go. You have taken a pushed branch through a pull request and brought the result back to your computer. Before starting the next change, check that you are on the right branch and your working tree is clean.