LotusGuild/cinny
3
0
Fork 0
Code Issues 27 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

[QA] §I Accessibility: aria-labels on edit-history / reactions / threads / replies with a screen reader #179

New Issue
Open
opened 2026-09-17 23:24:08 -04:00 by jared · 3 comments
jared commented 2026-09-17 23:24:08 -04:00
Owner
Copy Link
Copy Source

Migrated from LOTUS_TESTING.md §I on 2026-09-17 — the file is now reference-only.

How to report: tick each item as it passes; on FAIL comment with what you saw vs expected, browser/OS, web (chat.lotusguild.org) vs desktop (Tauri), theme, and any browser-console errors. Screenshots for anything visual.

With a screen reader on, navigate message hover-actions and content and confirm each control announces a meaningful label (not "button" / blank):

  • Reaction buttons announce the emoji + count (e.g. "thumbsup reaction, 3 people").
  • Edit history button announces "View edit history".
  • Thread indicator announces "View thread".
  • Reply (jump to original) announces "Jump to original message".
_Migrated from `LOTUS_TESTING.md` §I on 2026-09-17 — the file is now reference-only._ **How to report:** tick each item as it passes; on FAIL comment with what you saw vs expected, browser/OS, web (chat.lotusguild.org) vs desktop (Tauri), theme, and any browser-console errors. Screenshots for anything visual. --- With a screen reader on, navigate message hover-actions and content and confirm each control **announces a meaningful label** (not "button" / blank): - [x] **Reaction** buttons announce the emoji + count (e.g. "thumbsup reaction, 3 people"). - [x] **Edit history** button announces "View edit history". - [x] **Thread indicator** announces "View thread". - [x] **Reply** (jump to original) announces "Jump to original message". ---
jared added this to the Manual QA backlog milestone 2026-09-17 23:24:08 -04:00
jared added the a11yqa labels 2026-09-17 23:24:08 -04:00
jared commented 2026-09-18 19:22:09 -04:00
Author
Owner
Copy Link
Copy Source

Automated pass done under #185 (axe-core on timeline, settings, thread panel; sidebar/avatar/switch labels fixed). The remaining §I checks (edit-history / reaction / thread / reply aria-labels read correctly) need a screen reader in hand — leaving open for that.

Automated pass done under #185 (axe-core on timeline, settings, thread panel; sidebar/avatar/switch labels fixed). The remaining §I checks (edit-history / reaction / thread / reply aria-labels read correctly) need a screen reader in hand — leaving open for that.
jared commented 2026-09-24 12:18:50 -04:00
Author
Owner
Copy Link
Copy Source

Checked the accessible names in the live DOM (edited message, reply, thread and reaction created via the API; the speech itself still needs a screen reader):

control accessible name
Reaction "👍 reaction, 1 person" ✅
Edit history ("(edited)") "View edit history" ✅
Reply (jump to original) "Jump to original message" ✅
Thread indicator was just its visible text "1 reply · 12:16 PM", with no "thread" and the unread dot / muted bell visual-only fixed → "1 reply · 12:16 PM, view thread" (+ ", unread replies" / ", muted" when they apply). The visible text comes first, so voice control ("click 1 reply") still works.

One small inconsistency: a reaction's label sometimes uses the emoji ("🎉 reaction") and sometimes the shortcode ("tada reaction") for the same button, depending on render path. Both are readable.

Checked the accessible names in the live DOM (edited message, reply, thread and reaction created via the API; the *speech* itself still needs a screen reader): | control | accessible name | | |---|---|---| | Reaction | "👍 reaction, 1 person" | ✅ | | Edit history ("(edited)") | "View edit history" | ✅ | | Reply (jump to original) | "Jump to original message" | ✅ | | Thread indicator | was just its visible text "1 reply · 12:16 PM", with no "thread" and the unread dot / muted bell visual-only | **fixed** → "1 reply · 12:16 PM, view thread" (+ ", unread replies" / ", muted" when they apply). The visible text comes first, so voice control ("click 1 reply") still works. | One small inconsistency: a reaction's label sometimes uses the emoji ("🎉 reaction") and sometimes the shortcode ("tada reaction") for the same button, depending on render path. Both are readable.
jared commented 2026-09-26 11:35:37 -04:00
Author
Owner
Copy Link
Copy Source

Reaction-label inconsistency fixed in 1b5e6a37.

Cause. The label used getShortcodeFor(), which returns nothing until the lazily loaded emoji data arrives. A button rendered before that read "🎉 reaction". Once anything re-rendered it (for example someone else adding the same reaction), it read "tada reaction".

Fix. The label now always uses the emoji itself. Screen readers speak the character by its proper name ("party popper"), which reads better than the shortcode "tada". Custom (mxc) emoji were labelled only "custom emoji"; they now use the shortcode from the reaction event.

Evidence. Local Synapse run: bob sends 🎉 plus a custom emoji carrying shortcode: lotus_blob, alice opens the emoji board (which loads the data), then alice adds her own 🎉 to force a re-render.

before data after data after re-render
old 🎉 reaction, 1 person · custom emoji reaction, 1 person same tada reaction, 2 people · custom emoji reaction, 1 person
new 🎉 reaction, 1 person · :lotus_blob: reaction, 1 person same 🎉 reaction, 2 people · :lotus_blob: reaction, 1 person

The accessible names in this issue are now all correct in the DOM. What's left is the checklist's actual ask: hearing them spoken by a screen reader. Leaving this open for that human pass.

Reaction-label inconsistency fixed in `1b5e6a37`. **Cause.** The label used `getShortcodeFor()`, which returns nothing until the lazily loaded emoji data arrives. A button rendered before that read "🎉 reaction". Once anything re-rendered it (for example someone else adding the same reaction), it read "tada reaction". **Fix.** The label now always uses the emoji itself. Screen readers speak the character by its proper name ("party popper"), which reads better than the shortcode "tada". Custom (mxc) emoji were labelled only "custom emoji"; they now use the shortcode from the reaction event. **Evidence.** Local Synapse run: bob sends 🎉 plus a custom emoji carrying `shortcode: lotus_blob`, alice opens the emoji board (which loads the data), then alice adds her own 🎉 to force a re-render. | | before data | after data | after re-render | |---|---|---|---| | old | `🎉 reaction, 1 person` · `custom emoji reaction, 1 person` | same | **`tada reaction, 2 people`** · `custom emoji reaction, 1 person` | | new | `🎉 reaction, 1 person` · `:lotus_blob: reaction, 1 person` | same | `🎉 reaction, 2 people` · `:lotus_blob: reaction, 1 person` | The accessible names in this issue are now all correct in the DOM. What's left is the checklist's actual ask: hearing them spoken by a screen reader. Leaving this open for that human pass.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
a11y
Accessibility: keyboard, screen reader, contrast, motion
 area: appearance
Client area: appearance
 area: auth-session
Client area: auth-session
 area: build-ci
Client area: build-ci
 area: calls
Client area: calls
 area: desktop
Client area: desktop
 area: media
Client area: media
 area: messaging
Client area: messaging
 area: mobile
Client area: mobile
 area: moderation
Client area: moderation
 area: navigation
Client area: navigation
 area: notifications
Client area: notifications
 area: settings
Client area: settings
 area: threads
Client area: threads
 bug
Something is not working
 dependencies
Third-party package versions and advisories
 docs
README / LOTUS_* docs wrong or missing
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 needs-human-review
performance
Re-render storms, leaks, heavy work on hot paths
 planning
priority: critical
Data loss, security hole, or crash on a main path
 priority: high
Broken feature or serious usability problem
 priority: low
Minor issue or polish
 priority: medium
Wrong behaviour in an edge case or notable degradation
 qa
Manual QA: shipped, needs a human in a real environment
 question
More information is needed
 research
security
XSS, unsafe URLs, data leaks, auth/session
 tech-debt
Code health, dead code, fragile patterns
 ux
Usability or visual inconsistency
 wontfix
This won't be fixed
No labels a11y qa
Milestone
No items
No Milestone Manual QA backlog
Projects
Clear projects
No projects
Assignees
Clear assignees
cole (Cole Keller) jared (Jared Vititoe) nathan (Nathan Vititoe)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: LotusGuild/cinny#179