[macOS] Announce DatePickerController changes in VoiceOver

[mischreiber]

Platforms Impacted

• iOS
• visionOS
• macOS

Description of changes

• Add an NSAccessibility announcement when the visible month in the DatePickerController changes.
• Clean up TestDatePickerController so popover-hosted picker works as expected.

Binary change

n/a, no Mac size testing

Verification

• Verified VoiceOver announcements happen for all three date pickers in the test screen.
• Ensured announcements happen exactly once, and only when the picker changes (not on initial appearance).

Pull request checklist

This PR has considered:

• Light and Dark appearances
• iOS supported versions (all major versions greater than or equal current target deployment version)
• VoiceOver and Keyboard Accessibility
• Internationalization and Right to Left layouts
• Different resolutions (1x, 2x, 3x)
• Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)
• iPad Pointer interaction
• SwiftUI consumption (validation or new demo scenarios needed)
• Objective-C exposure (provide it only if needed)

Microsoft Reviewers: Open in CodeFlow

[anandrajeswaran]

Doesn't this usually happen because of direct user interaction? In which case we shouldn't need an announcement? Or is there a case where it's happening indirectly?

[mischreiber]

This whole control is a bit of an accessibility mess. The bandaid here is because the header title is never announced anywhere, in any context. A VoiceOver user can still infer what's happening by reading the individual dates in the calendar, but there's no way to know what's happening when the calendar changes months.

There are two longer-term fixes possible here that are outside the scope of this targeted fix:

1. Rethink the entire accessibility hierarchy and behavior of this control, along with a variety of minor visibility and usability problems.
2. Deprecate the control and work with partners to remove and replace it with the standard macOS date picker.

I have a preference, and it's not #1 :)

[anandrajeswaran]

What about just making the header title accessible so it's announced it a user moves focus to it? Or is that not trivial?

[mischreiber]

It already is, but that's not sufficiently accessible. We need an actual announcement when the value changes.

[anandrajeswaran]

Still a bit concerned - that feels like it would solve the letter of the law of accessibility compliance but maybe not actually be better for the user? I think Apple has a general assumption that the user knows what they are focused on when they activate a button so announcing additional info beyond their activation being successful seems like it may add noise rather than resolve confusion.

Another way to put it - if the user is in a situation where they are focused on the "next month" button and don't know or can't easily infer which month that will take them to, we have already failed them?