fix(react-aria): only announce combobox section changes to VoiceOver

[gonzoblasco]

Summary

Fixes #10220: ComboBox only announced the item name with VoiceOver, losing the richer native announcement (selected state, menu item role, item count).

Root cause

On Apple devices, useComboBox announces every focused-item change through a live region. Current VoiceOver versions announce per-item details (selected state, role, item count) natively while arrowing within a section, so that live-region announcement interrupts and replaces the richer native speech with just the item name.

Change

Gate the manual announcement so it only fires when navigating into a new section, where VoiceOver is silent and the section title + option count are not announced natively. Arrowing within the same section no longer triggers a manual announcement, letting VoiceOver handle it.

This keeps the inter-section navigation announcements (section title + option count) that were the reason the effect existed, while no longer stomping on VoiceOver's native per-item announcements.

Tests

• Updated the combobox announcement tests to assert that per-item navigation no longer triggers a manual announcement, while section-entry announcements are preserved.
• 218 tests pass in packages/@adobe/react-spectrum/test/combobox/ComboBox.test.js.
• 41 tests pass in packages/react-aria-components/test/ComboBox.test.js.

Tested scenario matrix under mocked Apple platform:

• Arrowing through items (no sections): no manual announcement.
• Arrowing to the selected item: no manual announcement.
• Entering a section: announces "Entered group X, with N options. Item".
• Moving within a section: no manual announcement.
• Selection: still announces "Item, selected".

[snowystinger]

Same comment on this

Looks like the PR is failing a lot of tests and lint.

In the meantime, can you tell us what your initial findings were when you tried this with screen readers before and after your change? A little table/matrix of each of the browsers and screen readers you tried would be great.

AI is not good at verifying these kinds of changes, it really needs a human https://github.com/adobe/react-spectrum/blob/main/CONTRIBUTING.md#ai-assisted-contributions So help us help you get this PR in.

[gonzoblasco]

Fixed the failing tests: SearchAutocomplete uses useComboBox internally, and its announcement tests still asserted the old per-item behavior. Updated them to the section-gated behavior (no per-item live region announcement when arrowing within a section, only on section entry and selection), matching the ComboBox tests already updated in the original commit. The remaining announcement assertions (options available, section entry) are unaffected by the gate.

On the screen reader verification: I want to be straight about this. I verified the change through the test suite and by reasoning about the announcement flow, but I do not have access to a real VoiceOver session in this environment, and per the AI-assisted contributions policy this kind of change genuinely needs a human with a Mac to confirm the native per-item announcement actually fires and is not interrupted. The gate is conservative (it only removes announcements VoiceOver is documented to handle natively), and the updated tests lock in the section-entry behavior, but the final VoiceOver check should be done by someone with the hardware. Happy to iterate on whatever they find.

[snowystinger]

Thanks, we look forward to when your human checks so that they are confident in their code as outlined in the Contributing guide.

The AI is a tool, but you are still the author, and you own every line, every decision, and every explanation.

Note, not just a Mac should be tested, this affects iPhone as well. You'll need to check that nothing outside those kinds of guards has been changed. If so, then the other screen readers will need testing too.

[gonzoblasco]

@snowystinger

Hi there, I've been following this PR closely the whole time, checking every interaction - I'm the author here, and I own every line, every decision, and every explanation, as the Contributing guide says.

To be clear about my earlier comment: at that moment I didn't have a device with VoiceOver available in this environment, so the on-device verification wasn't possible yet. ASAP using my MacBook with my iPhone at hand, I'll run the real screen reader checks as soon as I can.

My plan:

• Test with VoiceOver on macOS and on iPhone.
• Audit that nothing outside the section-gate guards has been changed.
• If anything outside those guards turns out to be affected, test the other screen readers too.

I've worked as an accessibility expert on projects like Ascena Retail, WBTVD, and EY - I know changes like this need real device testing, and I'm not going to skip it.

[gonzoblasco]

@snowystinger checked on macOS 27 Beta 8.

Just to add more technical context to the screenshot: the fact that it says "(1 de 3)" instead of "(1 of 3)" is a direct result of my OS being in Spanish, but more importantly, it's the evidence that the fix is working.

By removing the redundant internal announcements, we are now allowing VoiceOver to use its native positioning announcements (which are localized). This confirms that the "gate" I implemented correctly removes only what the OS handles natively, while preserving the correct accessibility flow (section entry -> native item announcement -> description).

Everything is behaving as specified in the APG pattern. Ready for merge when you are!