Clearer distinctions for pull request reviewer status and approvals

[ghostinhershell]

We’ve enhanced accessibility in the pull request (PR) review process by making it easier for everyone to understand reviewer status without relying solely on color.

What’s changed

Previously, green and gray checkmarks were used to indicate whether a reviewer had write access or read-only/no access, but these colors were hard to distinguish and didn’t meet accessibility standards. The following updates are being released:

• Reviewers whose approval affects merge requirements (shown with green checkmarks) and GitHub Copilot are shown at the top of the Reviewers section of the sidebar along with pending reviews and requests for changes.
• Other reviewers, whose approval may not affect merge requirements (shown with gray checkmarks), are grouped in a collapsible section labeled “+X more reviewers.”
• A tooltip appears when hovering over this collapsible section, providing extra context.
• We've added visual cues and descriptive labels aligned with inclusive best practices to ensure status is always clear, regardless of how you experience GitHub.

You can see an example of these changes in WordPress/wordpress-develop#2393 or in the screenshots below

Why does this matter?

By introducing explicit indicators and descriptive text, we make the PR review process more inclusive for everyone. This change was shaped with additional input from maintainers who helped us rethink what information maintainers and contributors actually need: a clear signal about the PR’s progress and reviewer status, not just visual cues that are easy to miss.

Feedback

We’re always looking to improve our usability and your feedback helps us get there! If you have suggestions or run into issues, leave a comment below.

[mOctave]

Somehow missed this discussion on my search...

My feedback is here: https://github.com/orgs/community/discussions/169946

Basically, I think this has the potential to be a really good change but needs to be labelled clearer.

[Doc94]

This change affects the API webhook? because that thing send when a user approve but i think that not send if that approve counts or not like in the web.

[moraesc]

Hey @Doc94, this change does not affect the API webhook

[Doc94]

Cannot be consider?
Currently for webhooks can be great has this info