Bug 286267
| Summary: | AX: VoiceOver does not announce text preceding some phrasing elements | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adrian Roselli <aroselli> |
| Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | andresg_22, dani, tyler_w, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 18 | ||
| Hardware: | All | ||
| OS: | macOS 15 | ||
Adrian Roselli
In a test using `<mark>`, `role="mark"`, `role="deletion"`, or `role="insertion"`, VoiceOver with Safari does not announce the opening of the sentence, instead jumping to where the element starts.
To replicate:
1. Open Safari and activate VoiceOver
2. Go to https://cdpn.io/aardrian/debug/rNRxZmP
3. Use the `read-all` command (VO + A)
4. Observe how, for most paragraphs, the first words are not announced.
Other notes:
* The unannounced text appears in the speech viewer.
* The unannounced text appears in the Braille viewer.
* The text is announced using other navigation methods.
* The text is announced in Chrome when using read-all.
* The text is announced in Firefox when using read-all.
* Code visible at https://codepen.io/aardrian/pen/rNRxZmP
More details:
* The buggy MARK examples only start announcing at `<mark>`, `<mark role="mark">`, and `<span role="mark">`.
* The buggy DEL examples only start announcing at `<del role="deletion">` and `<span role="deletion">`. There is no issue with `<del>`.
* The buggy INS examples only start announcing at `<ins role="insertion">` and `<span role="insertion">`. There is no issue with `<ins>`.
* The buggy S examples only start announcing at `<s role="deletion">` and `<span role="deletion">`. There is no issue with `<s>`.
The attached video demonstrates this. It has no captions.
Possibly related:
The following bugs also have clipped announcements, though the scenarios and elements are far different:
* 249154: AX: Role of combobox on button cuts off screen reader announcement (voice over) https://bugs.webkit.org/show_bug.cgi?id=249154
* 285047: AX: combobox button value text clipped https://bugs.webkit.org/show_bug.cgi?id=285047
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/143272808>
Adrian Roselli
Trying to attach a 1.41 MB video, but keep getting a "413 Request Entity Too Large" error, even though the file upload screen says files up to 1GB are allowed. Will try again later.
Adrian Roselli
Ok, still cannot upload video (tried multiple days and browsers). You can get to the video in this Masto post:
https://toot.cafe/@aardrian/113861850234398134
Adrian Roselli
This has regressed. Using VoiceOver / macOS 15.4 / Safari 18.4 now the elements `<del>`, `<ins>`, and `<s>` are impacted.
Daniel Koskinen
I can confirm the continuing existence of this bug, tested on Safari 18.5 (20621.2.5.11.8) on macOS 15.5 (24F74).
Adrian Roselli
I've filed issues against the web compat / Baseline tables as a result of this bug:
• https://github.com/mdn/browser-compat-data/issues/27443
• https://github.com/mdn/browser-compat-data/issues/27444
• https://github.com/mdn/browser-compat-data/issues/27445
• https://github.com/mdn/browser-compat-data/issues/27446
I'll file PRs to change the support notes and close those issues in a week or so.
Adrian Roselli
PRs filed:
• https://github.com/mdn/browser-compat-data/pull/27506
• https://github.com/mdn/browser-compat-data/pull/27507
• https://github.com/mdn/browser-compat-data/pull/27509
• https://github.com/mdn/browser-compat-data/pull/27510
Tyler Wilcock
Hello Adrian! Thanks very much for filing this.
There was a VoiceOver-side fix to address this in macOS Tahoe 26. I have the beta installed and just gave your test page a try and did hear all text announced. I'm going to close this as resolved, but please do not hesitate to re-open if you find otherwise. Thanks!
Adrian Roselli
Tyler, thanks for the note. When I get the release version of macOS 26 I'll confirm it (and come back here if there are issues).
In the meantime, can you tell me if this issue was in VoiceOver or Safari? Asking because my testing suggested it was Safari (given other browsers on macOS with VoiceOver did not exhibit it). This would be helpful in properly classifying this bug in Can I Use, Baseline, and other browser compat resources.
Similarly, when working with clients and users on this issue, is there any way for them to get the fix _without_ updating their macOS version? I want to know if user-facing guidance to working around it involves a system update or just a Safari release update.
Tyler Wilcock
This indeed was a VoiceOver side fix! Whether the bug manifested came down to differences in how browsers expose text, and expose these "marked text"-style semantics through the accessibility API, which is why other browsers were not affected. Folks will need to update to macOS 26 to get this fix.