Closed Bug 1678015 Opened 4 years ago Closed 4 years ago

Make alerts fully accessible to VoiceOver

Categories

(Core :: Disability Access APIs, defect, P1)

Firefox 85
Desktop
macOS
defect

Tracking

()

RESOLVED FIXED
85 Branch
Tracking Status
firefox85 --- fixed

People

(Reporter: MarcoZ, Assigned: MarcoZ)

References

Details

(Whiteboard: [Mac2020_2])

Attachments

(1 file)

Spun off bug 914054.

Steps:

  1. 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>.
  2. 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.
  3. 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:

  1. Treat nsIAccessibleEvent::EVENT_ALERT the same as a live region add or change.
  2. Create a special Mac alert accessible that is created for anything HTML or XUL that is of role::ALERT.
  3. 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.

(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.

(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.

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>

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: nobody → mzehe
Status: NEW → ASSIGNED
Attachment #9188844 - Attachment description: Bug 1678015 - Expose assertive live region attributes ffor native and ARIA alerts, r?jamie! → Bug 1678015 - Expose assertive live region attributes for ARIA alerts, r?jamie!

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".

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.

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.

Attachment #9188844 - Attachment description: Bug 1678015 - Expose assertive live region attributes for ARIA alerts, r?jamie! → Bug 1678015 - Expose assertive live region attributes for ARIA alerts on Mac, r?jamie!, eeejay!
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
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: