Accessibility: Announce notices to assertive technologies

[youknowriad]

closes #3690

This PR uses the a11y lib to announce the publish flow notices to assertive technologies.
I was wondering if I should do this systematically for all notices (in a generic way) but decided not to because the assertive message could defer from the notice's content.

[jorgefilipecosta]

I think a generic way would be preferable as by default we would always announce notices.

the assertive message could defer from the notice's content.

One option the overcome that problem in a generic approach would be to add an option called spokenMessage to createNotice options. When that option is present we would use that property instead of the normal notice message for the spoken text.

[youknowriad]

One option the overcome that problem in a generic approach would be to add an option called spokenMessage to createNotice options. When that option is present we would use that property instead of the normal notice message for the spoken text

I thought about this, but if the developer is unaware of the behavior, this might produce "wrong" messages (html inside etc...). Thoughts @afercia

[afercia]

Hm as far as I know, speak should already strip out HTML?
Ideally, the string for an audible message should be carefully crafted, for example it wouldn't make much sense to reuse "Post published! View post". Even stripping out the link, View post wouldn't make much sense. The message could simply be Post published. I'd tend to agree with @jorgefilipecosta: add a specific string for the audible messages, fallback to the notice string, educate developers, and document everything.

[youknowriad]

PR updated with the generic approach.

[jorgefilipecosta]

From the code point view changes look good to me 👍

[aduth]

These should be localized.

[youknowriad]

Actually, these are only tests. The message is localized :)