Context
The large permission-comparison tables in permissions-reference.mdx and users.mdx mark "granted" with a checkmark character and leave "not granted" cells blank.
A visual bug was just fixed: ✔ (U+2714) defaults to Unicode text presentation, so it fell through the site's font stack to a fallback font (Segoe UI Symbol) that rendered it as a fixed dark grey glyph regardless of theme — poor contrast in dark mode. It's been swapped to ✅ (U+2705), which defaults to emoji presentation and always renders as a color glyph, independent of the text-color cascade. That fix is purely visual.
What still needs review
Two accessibility questions remain open, and need input from someone who can test with an actual screen reader (VoiceOver/NVDA/JAWS):
- Blank "not granted" cells. A screen reader user tabbing cell-by-cell through the table hits silence for every "no" cell. That's ambiguous — it reads the same as "no data" rather than an explicit negative. Consider whether these tables should carry an explicit "Yes"/"No" (visually-hidden or otherwise) instead of relying on presence/absence of an icon.
- Emoji announcement reliability.
✅/❌-style characters are not covered by ARIA — there's no aria-label involved, so what gets spoken is entirely up to the screen reader's own Unicode/emoji pronunciation dictionary. This is usually reliable for default-emoji-presentation characters like ✅, but it's screen-reader/OS/settings dependent, not something the markup guarantees.
Suggested next step
Have someone test both tables with a screen reader and decide whether to add explicit text alternatives (e.g., visually-hidden "Yes"/"No" per cell) rather than relying purely on the checkmark glyph. This pattern (icon-only table cells) may be worth a general guideline in the style guide if it recurs elsewhere.
Context
The large permission-comparison tables in permissions-reference.mdx and users.mdx mark "granted" with a checkmark character and leave "not granted" cells blank.
A visual bug was just fixed:
✔(U+2714) defaults to Unicode text presentation, so it fell through the site's font stack to a fallback font (Segoe UI Symbol) that rendered it as a fixed dark grey glyph regardless of theme — poor contrast in dark mode. It's been swapped to✅(U+2705), which defaults to emoji presentation and always renders as a color glyph, independent of the text-color cascade. That fix is purely visual.What still needs review
Two accessibility questions remain open, and need input from someone who can test with an actual screen reader (VoiceOver/NVDA/JAWS):
✅/❌-style characters are not covered by ARIA — there's noaria-labelinvolved, so what gets spoken is entirely up to the screen reader's own Unicode/emoji pronunciation dictionary. This is usually reliable for default-emoji-presentation characters like✅, but it's screen-reader/OS/settings dependent, not something the markup guarantees.Suggested next step
Have someone test both tables with a screen reader and decide whether to add explicit text alternatives (e.g., visually-hidden "Yes"/"No" per cell) rather than relying purely on the checkmark glyph. This pattern (icon-only table cells) may be worth a general guideline in the style guide if it recurs elsewhere.