api.Document.ariaNotify - Firefox should also be marked as partial

[captainbrosset]

What type of issue is this?

Incorrect support data (example: BrowserX says "86" but support was added in "40")

What information was incorrect, unhelpful, or incomplete?

Chromium browsers are marked as partially supporting the document.ariaNotify (and element.ariaNotify) methods on macOS.
See

browser-compat-data/api/Document.json

Line 778 in 7bb620d

"Method exposed on macOS, but notifications are not reliably spoken."

From our testing, Voice Over had trouble reliably reading these notifications, and could get interrupted by user actions.

Firefox is marked as fully supporting the APIs, even though, under the hood, it very likely uses the same macOS API.

So, it would seem fair to:

• Either have both Chromium and Firefox be marked as partial, for the same reasons.
• Or, have them both marked as fully supported, if we decide that the current support is "good enough".

@janewman said he was doing some testing here. Please let us know if you find something that could help make a decision.

What browsers does this problem apply to, if applicable?

No response

What did you expect to see?

Similar support data, if both browser engines indeed use the same underlying APIs.

Did you test this? If so, how?

Not yet. To be updated when/if we find relevant test results.

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

No response

Do you have anything more you want to share?

No response

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Document/ariaNotify

MDN metadata

MDN page report details

• Query: api.Document.ariaNotify
• Report started: 2026-05-05T21:31:18.785Z

[janewman]

The issue that caused chromium to have that caveat added can be viewed on both browsers here:
MDN Shopping Example, direct link to the playground

The specific issue that was brought to me when adding the "Method exposed on macOS, but notifications are not reliably spoken." caveat was that Voice Over has trouble with is multiple competing events at the same time.

If in the shopping example you

• enter an item,
• enter a price,
• either tab or click on the submit button
  then the notification is announced as expected.

But if instead of clicking or tabbing to the submit button you hit enter from the text input on the form (where either price or name is input), Voice Over will instead prioritize the text change on the focused text input (as submitting clears the form) over the notification.

I just tested this scenario and found nearly identical behavior on both chromium (tested with Edge) and Firefox.

The only slight difference between the two is when enter is pressed from the price input field, on chromium, Voice Over announces the price that has just been cleared, but on Firefox, it announces NaN.

In any case, as I have tested, the ariaNotify behavior on the two browsers is identical.

[caugner]

This sounds like an operating system limitation rather than a browser limitation, and that no browser on macOS supports this "reliably".

According to our partial guidelines, this does not justify setting partial.

/cc @ddbeck for confirmation.

[ddbeck]

If I understand correctly that this is a VoiceOver bug in macOS and not a difference between browsers, then yes, this is out of scope for BCD, so partial_implementation shouldn't be set. That said, as a practical matter, I'd be happy for someone to add a note about the bug to the browsers where it applies (I guess this would be all of them?). It'd be better still if there was a link to bug, but I don't know if there's a public tracker for this sort of thing.

I've labeled this as "acd" so it's more findable for the accessibility compat data effort.

Edited to add: The original note text is pretty bad! I'd like to see them rewritten as well. Phrases like "fully supported" or "no support" are quite vague and I'd expect to see text like "not exposed", "undefined", "throws exception", or whatever the case may be.