Wip enhance accessibility #776
Conversation
Ovgodd
force-pushed
the
access/issue-767
branch
from
c80980b to
b62182d
Compare
| <TooltipTrigger delay={tooltipType === 'instant' ? 150 : 1000}> | ||
| {children} | ||
| <Tooltip>{tooltip}</Tooltip> | ||
| <Tooltip aria-hidden="true">{tooltip}</Tooltip> |
There was a problem hiding this comment.
I have the feeling that the tooltip is still being announced by the screen reader. As a result, the label is read out twice (see screenshot below).
Hiding the tooltip might have a broader impact, and I’m not sure that disabling it would be a neutral change from an accessibility standpoint.
There was a problem hiding this comment.
hey @lebaudantoine
You’re right: even with aria-hidden="true", the tooltip gets announced because the React Aria TooltipTrigger adds an aria-describedby to the button, which points to the tooltip. That’s why the label is read twice. Disabling or hiding the tooltip isn’t neutral for accessibility—we need a different approach (e.g., a visual-only tooltip not referenced by aria-describedby) to avoid duplicating the announcement while keeping the visual hover/focus help.
Ovgodd
force-pushed
the
access/issue-767
branch
2 times, most recently
from
75bcd51 to
ad05cb2
Compare
lebaudantoine
force-pushed
the
access/issue-767
branch
from
ad05cb2 to
99bb734
Compare
| tooltip={tooltipLabel(ProcessorType.VIRTUAL, { | ||
| imagePath, | ||
| })} |
There was a problem hiding this comment.
no tooltip is displayed anymore for regular user, I guess something isn't working as expected.
Another comment I had while looking at this screenshot: do you think the visual contrast of the actual selected ring is strong enough to be clearly noticed and understood?
There was a problem hiding this comment.
Hey @lebaudantoine, I re-add the tooltip ! nice catch.
Regarding the visual contrast of the current selection ring, this is OK.
The contrast ratio is 3.14:1, which passes the “Graphical Objects and User Interface Components” criterion, requiring a minimum of 3:1.
lebaudantoine
force-pushed
the
access/issue-767
branch
2 times, most recently
from
3871664 to
532202d
Compare
Ovgodd
force-pushed
the
access/issue-767
branch
2 times, most recently
from
7a158f3 to
1d8962a
Compare
Ovgodd
force-pushed
the
access/issue-767
branch
3 times, most recently
from
1eb4c39 to
fd443ec
Compare
lebaudantoine
force-pushed
the
access/issue-767
branch
from
fd443ec to
293fae7
Compare
Ovgodd
force-pushed
the
access/issue-767
branch
2 times, most recently
from
eaa5244 to
41c974d
Compare
src/frontend/src/features/rooms/livekit/components/effects/EffectsConfiguration.tsx
Show resolved
Hide resolved
lebaudantoine
left a comment
lebaudantoine
left a comment
There was a problem hiding this comment.
Few comments
src/frontend/src/features/rooms/livekit/components/effects/EffectsConfiguration.tsx
Show resolved
Hide resolved
|
|
||
| const tooltipLabel = (type: ProcessorType, options: BackgroundOptions) => { | ||
| return t(`${type}.${isSelected(type, options) ? 'clear' : 'apply'}`) | ||
| const tooltipBlur = (type: ProcessorType, options: BackgroundOptions) => { |
There was a problem hiding this comment.
I guess same issue, the bluring option is vocalized twice on voice over
src/frontend/src/features/rooms/livekit/components/effects/EffectsConfiguration.tsx
Show resolved
Hide resolved
Ovgodd
force-pushed
the
access/issue-767
branch
4 times, most recently
from
c3388e2 to
f134a54
Compare
Refine the Effects title to clearly indicate it covers both background and effects, improving clarity. Inspired by Google Meet.
Fix an issue where the focus visual indication was hidden due to an overly tight layout with no padding on the background and effects toggle buttons.
Update the virtual background effects tooltip and ARIA label with more descriptive and concise wording based on Sophie’s feedback. This helps all users, especially those using assistive technologies, by improving how each virtual background is vocalized.
While this makes it slightly less explicit that clicking an already selected option will disable the active effect, it improves accessibility by avoiding automatic focus movement from the previously active option to a separate “none” option. That focus shift could be misleading or hard to follow for screen reader users. Open to feedback on this decision.
Hide non-essential icons and refine the labels to emphasize that one option applies a stronger blur than the other. This should provide clearer cues for screen reader users.
Use the appropriate HTML <aside> element for the side panel and enhance it with the correct ARIA attributes to improve accessibility.
Signed-off-by: Cyril <[email protected]>
improves a11y by exposing blur state to sr users and hiding visual labels Signed-off-by: Cyril <[email protected]>
removed redundant label from virtual background to improve sr clarity
improves keyboard navigation by placing focus on first actionable element
Ovgodd
force-pushed
the
access/issue-767
branch
from
f134a54 to
0421cb3
Compare
…ggles debounces blur announcements so screen readers only reflect the final state
|
Wip research works.