Make alerts fully accessible to VoiceOver
Categories
(Core :: Disability Access APIs, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox85 | --- | fixed |
People
(Reporter: MarcoZ, Assigned: MarcoZ)
References
Details
(Whiteboard: [Mac2020_2])
Attachments
(1 file)
Spun off bug 914054.
Steps:
- Open
data:text/html,<button onclick='let alert = document.createElement("div"); alert.setAttribute("role", "alert"); alert.setAttribute("id", "alert"); alert.textContent = "I need to be spoken ASAP."; document.body.appendChild(alert);'>Show alert</button><br /><button onclick='document.getElementById("alert").textContent = "I need to be spoken as soon as possible.";'>Update alert</button>. - Press first the Show Alert button.
- Expected: VoiceOver speaks the alert message. VoiceOver emits the chime that accompanies assertive live regions.
- Actual: Nothing is spoken. No chime is heard.
- Press the Update Alert button.
- Expected: VoiceOver speaks the updated message in full. The chime is heard again.
- Actual: Silence in both speech and sound.
Alerts are a special case in Gecko. Due to historic reasons, they have their own role, and screen readers expect a special alert event, coming from the MSAA days. Linux/ATK copied that somehow. Furthermore, the alert is contained in the Acc Description, not the Acc name. Technically, we are even violating the WAI-ARIA spec because we are not setting the aria-live attributes on accessibles created either by role "alert" or by XUL:Notification elements.
The quickest, most non-intrusive, fix for VoiceOver would be:
- Treat nsIAccessibleEvent::EVENT_ALERT the same as a live region add or change.
- Create a special Mac alert accessible that is created for anything HTML or XUL that is of role::ALERT.
- For that, hard-wire the aria-live attributes for aria-live="assertive" and aria-atomic="true" so that VoiceOver will always speak the full message for alerts, not just parts in case the text of an alert gets updated. Such alerts are always spoken in full on Windows and Linux, even if the above test case is amended with an aria-live="assertive".
Suggest to implement it this way to make both alerts in doorhangers as well as on the web (for example when liking a Tweet on Twitter) spoken by VoiceOver.
|
||
Comment 1•3 years ago
|
||
(In reply to Marco Zehe (:MarcoZ) from comment #0)
Furthermore, the alert is contained in the Acc Description
No, the description thing is NVDA behaviour. The description as reported by Gecko is empty unless aria-describedby or aria-description is set.
not the Acc name.
The acc name being empty is also correct, since the spec says only name from author.
Technically, we are even violating the WAI-ARIA spec because we are not setting the aria-live attributes on accessibles created either by role "alert" or by XUL:Notification elements.
That part is definitely true. Note that Chrome does expose live:assertive for role="alert", even on Windows. I'm guessing this might cause double speaking with NVDA, but if it doesn't (e.g. if NVDA has worked around that), we could potentially do the right thing here and treat it as a real live region.
|
Assignee | |
Comment 2•3 years ago
|
||
(In reply to James Teh [:Jamie] from comment #1)
No, the description thing is NVDA behaviour. The description as reported by Gecko is empty unless aria-describedby or aria-description is set.
OK, I actualy experimented with adding aria-live="assertive" to the test case, and found nothing wrong with NVDA speaking, or not speaking, something it should or shouldn't. So the addition of the implicit role seems to not do any harm.
That part is definitely true. Note that Chrome does expose live:assertive for role="alert", even on Windows. I'm guessing this might cause double speaking with NVDA, but if it doesn't (e.g. if NVDA has worked around that), we could potentially do the right thing here and treat it as a real live region.
Yes, I think we might be safe doing that.
|
|
||
Comment 3•3 years ago
|
||
Where I'd expect double speech from NVDA (if we're going to see any) is where the content of an alert is updated. So something like this (untested):
data:text/html,<div role="alert" id="div">initial</div><script>setTimeout(() => div.textContent = "changed", 2000);</script>
|
|
||
Comment 4•3 years ago
|
||
Oh, now I see the initial test case already covered updates. So I guess NVDA worked around this then. This will still need close testing if we patch this, but it bodes well.
|
|
Assignee | |
Comment 5•3 years ago
|
||
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Comment 6•3 years ago
|
||
If I add alert.setAttribute("aria-live", "assertive"); to the test case in comment 0, pressing the Update alert button results in double speech with NVDA. So landing this patch would thus cause double speech with NVDA for role="alert".
|
|
||
Comment 7•3 years ago
|
||
It seems Chrome doesn't fire the alert event when alerts are updated, which is why we don't get double speech there. However, I'm pretty sure that would break a11yUtils.announce for JAWS, among maybe other things.
|
|
||
Comment 8•3 years ago
|
||
A possible hack would be to only fire the alert event for updates if aria-live is explicitly set to off. That would make us consistent with Chrome, while still allowing us to get a11yUtils.announce working for JAWS. Although that'd probably break a11yUtils.announce on Mac. Blah.
|
|
||
Updated•3 years ago
|
Pushed by mzehe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5081ce938a4b Expose assertive live region attributes for ARIA alerts on Mac, r=Jamie,eeejay
|
||
Comment 10•3 years ago
|
||
| bugherder | ||
Description
•