Make Safari + VoiceOver announce the screen-reader-text within buttons in the correct order

[afercia]

Description

Fixes a Safari + VoiceOver bug where the screen-reader-text within buttons is announced not respecting the source order. For more details, please see https://core.trac.wordpress.org/ticket/42006

• Adds height: auto to screen reader text within buttons

Fixes #13219

[aduth]

Could we include a reference link as part of the inline comment, perhaps to the Trac ticket or some of the debugging from the related HTML5 Boilerplate discussion, as without it, it'd be more difficult to revisit as part of future maintenance should the bug become resolved in Safari, or a better alternative proposed.

[afercia]

Done.

[aduth]

Testing instructions:

1. Navigate to Posts > Add New
2. Insert a title and/or content
3. Activate macOS Voiceover via Cmd+F5
4. Move focus to Preview button (may require Advanced settings configuration in Safari to navigate to Preview link by Tab, otherwise Option+Tab)
5. Voiceover should read "link, Preview (Opens in a new tab)"

[aduth]

This appears to solve the issue for me in Safari, but the problem also exists (and is not fixed by these changes) for Voiceover in Chrome. Is that expected?

Is this intended to serve as a temporary fix, with a more durable one planned to be applied for all .screen-reader-text ? It's not clear to me why this should only impact buttons, or at least specifically the .component-button and not all button/link elements.

[afercia]

A more durable fix would be Apple fixing this bug 🙂

height: auto works for buttons because they have a height. Inline links or text don't have a height. Several approaches were tested on the HTML5 boilerplate issue https://github.com/h5bp/html5-boilerplate/issues/1985 but none of them works reliably.

If there are more places where height: auto can work I'd be happy to apply this fix there too. I just can't think of other components where we can do it reliably.

Re: Chrome, I wouldn't be too concerned, as many other things don't work so well with VoiceOver + Chrome and users know the best combo is Safari + VoiceOver. The reason why it doesn't work on Chrome is the inconsistent implementation of absolutely positioned flex items across browsers. In Chrome, display: inline-flex on the button does affect the position of the screen reader text, see the blue vertical line in the screenshot below:

• it is taken out from the flow (and this is correct)
• however, it's placed before the content, and this doesn't seem correct to me: in absence of left/right/top/bottom values, an absolutely positioned element should stay in its original position

The only way I can think of to fix this is by applying justify-content: flex-end on the button but I guess we don't want to touch the buttons styling. Anyways, I'd consider it a minor issue as we don't support the Chrome + VoiceOver combo.

Worth reminding the same fix is going to land in core, see https://core.trac.wordpress.org/ticket/42006