1662887 - role="timer" and aria-live="off"

Status: RESOLVED WORKSFORME

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

Description

[pmawhorter]

Attachment: aria_timer.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

1. Created a div with role="timer" and aria-live="off", placing it at the bottom of my page.
2. Wrote Javascript code using setTimeout to update the contents every second.

Actual results:

Using VoiceOver and reloading the page to trigger auto-read, the first 1 second of the content of the div is read repeatedly, and automatic reading cannot progress to the rest of the page. In the accessibility info inspector, the element has role "section" instead of "timer", although various correct-looking properties can be found in the attributes section of the accessibility infomrationlike live: "off" and xml-roles: "timer". I've attached a MWE of this behavior.

Expected results:

With either role="timer" OR aria-live="off", the updates should not be read by a screen reader. With aria-live="polite", they should be read only when other content is not being read. Only with aria-live="assertive" should the observed behavior occur.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[James Teh [:Jamie]]

Marco, can you look into this and/or forward to Eitan/Morgan if needed? It looks like we're correctly exposing AXApplicationTimer on Mac for role="timer". I guess that actually works against us in this case?
If you remove role="timer", does this go away?
Does this misbehave in Chrome or Safari? Do they expose AXApplicationTimer in this case? Do they expose some other attribute that prevents this behaviour (if indeed it is prevented)?

The "section" role in the Firefox A11y Inspector is an internal role and due to the fact that most platforms don't have a role for this (but we do expose the correct subrole on Mac). I realise this is confusing, though, and we should probably fix it... but I'm less concerned about that in this particular bug than I am about the VoiceOver behaviour.

Comment 3

[Marco Zehe (:MarcoZ)]

Yes, I guess this works against us in this case. VoiceOver seems to have a default behavior of assertive for timers, if no other aria-live property is exposed. Since we do not yet expose aria-live properties to the Apple accessibility APIs, VoiceOver has nothing to go on for the aria-live="off" part of this example. I suspect this will fix itself once we properly expose the live region attributes VoiceOver expects from us.

Comment 4

[Marco Zehe (:MarcoZ)]

Properly adding this to our Mac backlog so it gets picked up on the wiki.

Comment 5

[pmawhorter]

Thanks for the details on this!

It sounds like I should file a bug against VoiceOver as well then? Obviously exposing aria-live to Mac accessibility stuff is something Firefox should do, but the default behavior of timers being equivalent to aria-live: assertive seems directly counter to the W3 recommendation's assertion that:

Elements with the role timer have an implicit aria-live value of off.

Does this make sense to raise on their side of things, or am I misinterpreting something here?

Comment 6

[Marco Zehe (:MarcoZ)]

No, you are not misinterpreting things. This is worth raising with Apple.

Comment 7

[pmawhorter]

I've raised the issue with Apple (according to https://www.applevis.com/blog/found-accessibility-bug-ios-ipados-macos-watchos-or-tvos-here-s-how-let-apple-know-and-why-you, email is the best way to do so) and linked them to this bug report.

Comment 8

[Marco Zehe (:MarcoZ)]

Now that we support ARIA live regions in Firefox 85 Nightly, can you download a Nightly build and re-test? I cannot reproduce this bug with the steps provided. I see the content updating for VoiceOver when I explicitly navigate to it, but not automatically. VoiceOver remains silent.

Comment 9

[Eitan Isaacson [:eeejay]]

Me neither. I can't reproduce. I'm closing as WORKSFORME. Reporter can reopen if it is still an issue.