They should. A security comment must make sense with color and icons stripped out, so put severity and status in words. Some readers cannot tell certain colors apart, use screen readers, or have emoji rendered oddly in email. Plain text severity labels work for all of them, and for search.
The rule behind it
The Web Content Accessibility Guidelines include a success criterion on use of color: color is not used as the only visual means of conveying information. It applies when color alone signals an action, requests a response or sets one element apart. The intent is that people who cannot distinguish certain colors still get the information from another visual cue, such as text.
Pull request comments are not always covered by formal accessibility requirements, but the principle is sound engineering. A red circle that means "high" is meaningless to someone who cannot see red.
Words first, decoration second
| Weak | Better |
|---|---|
| A red dot | "High severity" |
| A checkmark emoji | "Passed, no new findings" |
| Three warning icons | "3 medium findings, 0 high" |
| Colored badge image | Text label plus optional badge |
Decoration can stay if it is paired with words. The test is simple: delete the icons, and see whether the message still says the same thing.
Other practical points
- Images of text. Do not post a screenshot of a table. It cannot be searched, copied or read by a screen reader. Use a Markdown table.
- Alt text. If you must include an image, give it a short, real description.
- Link text. Write "see the fix guidance for this rule", not "click here".
- Headings and lists. Use real Markdown structure so assistive tools can navigate it.
- Email rendering. Notifications often arrive as plain text. A comment built around emoji may reach the reader as a string of boxes.
Keep severity vocabulary consistent
Pick a small fixed set of labels, such as critical, high, medium, low and informational, and use them everywhere: comment text, check summary and report. Mixed vocabularies slow reading. If your scanner uses a numeric score, state how it maps. GitHub documents that security severity scores map to bands: over 9.0 is critical, 7.0 to 8.9 high, 4.0 to 6.9 medium, and 0.1 to 3.9 low. Matching those bands makes your labels familiar to readers who also use code scanning.
Test your own output. Paste a comment into a plain text editor, or view the notification email with images off, and check whether severity, location and action are still clear. A thirty second check like this catches most problems before developers do.
Tone is accessibility too
Plain, short sentences help everyone, including people reading in a second language. Avoid idioms, sarcasm and jargon without a link. A comment should be understandable by a newer developer on a bad day.
Safeguard findings use named severity levels alongside any visual styling. Try a free scan and note how severity is stated in text.
Quick check
Are emoji banned in security comments?
No. They are fine as an addition to words. They should never be the only carrier of meaning.
Is a Markdown table accessible?
Generally yes, since it keeps structure that assistive tools can read, which an image of a table does not.
Sources
- W3C: Understanding Success Criterion 1.4.1 Use of Color
- GitHub Docs: SARIF support for code scanning
Last reviewed: 19 October 2026.
