Clarify expected AT behavior when the accessible name of a focused control is updated.

[khiga8]

Describe your concern

Hi! I noticed inconsistent screen reader announcement behavior when the content of a button that is currently receiving focus changes. I wanted to surface this concern somewhere to get clarity. Please let me know if I should file this issue elsewhere.

We have some buttons where the content of a button (visible label/accessible name) changes to communicate a change in state.

For example:

Play → Pause
Subscribe → Unsubscribe

I tested a few different implementations so we can ensure that these changes are communicated to AT users, but noticed inconsistent behavior across different screen reader/browser combos. It is unclear what the expected behavior is. Should the AT announce this change by default if user focus is already on it, or is the expectation to rely on live region techniques?

Test scenarios

Codepen

(Note: I copied my test scenarios into the above CodePen. It is worth noting that there is a bug in VoiceOver that results in double live region announcements within an <iframe>, so you may hear an extra announcement)

Scenario 1: Button where the content is updated (base case)

• VoiceOver + Chrome - Announces new name ✅
• VoiceOver + Safari - No announcement ❌
• NVDA + Chrome - No announcement ❌
• NVDA + Firefox - Announces new name ✅
• JAWS + Chrome - No announcement ❌
• JAWS + Firefox - Announces new name ✅

Should this scenario result in an announcement?

Scenario 2: Updating aria-label in addition to the button content

Strangely enough, when the aria-label is updated, announcements seem to trigger, once, consistently.

• VoiceOver + Chrome - Announces new name ✅
• VoiceOver + Safari - Announces new name ✅
• NVDA + Chrome - Announces new name ✅
• NVDA + Firefox - Announces new name ✅
• JAWS + Chrome - Announces new name ✅
• JAWS + Firefox - Announces new name ✅

However, setting aria-label for the purpose of triggering an announcement isn't really idea.

Other scenarios

I've tested several other scenarios including:

• Setting aria-live="polite" aria-atomic="true" directly on the <button>. This is not supported in VoiceOver + Safari, and resulted in duplicate announcements in most combos.
• Populating a pre-existing live region outside of the <button>. This approach resulted in consistent announcements and feels less hacky than the aria-label update approach, but also results in duplicate announcements in some screen reader/browsers (VoiceOver + Chrome, NVDA + Firefox). (This is the recommended approach in. Multi-Function Button — Adrian Roselli)

Link to the version of the specification or documentation you were looking at at.

Link to documentation:

• button
• button pattern

[scottaohara]

related to / semi-duplicate of w3c/core-aam#224