Add VoiceOver accessibility to contrast-checker

[AmartyaU]

Addresses #10581 (comment)

Description

Added VoiceOver accessibility functionality to contrast-checker

How has this been tested?

Changed background and text color options in color settings and heard warning being announced in addition to it being displayed in all cases

Tested with VoiceOver on Mac in a Chrome browser

Types of changes

New feature (non-breaking change which adds functionality)

Testing

Insert Paragraph block and start playing with its colors with VoiceOver enabled.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[gziolo]

I tested it with VoiceOver enabled. It's very aggressive when you try to use custom colors. Every time I pick a new color which doesn't meet criteria triggers the announcement even if this is exactly the same message. It might be a better idea to trigger speak with 3 messages only when they change:

• no violation - no message
• violation fixed - message informing that color combination is good
• try a brighter color message
• try a darker color message

[afercia]

Wondering it the message second part is actually useful, both visually and as an audible message:

Try using a brighter background color and/or a darker text color.
Try using a darker background color and/or a brighter text color.

What is the value added by these sentences? They add cognitive load and make the entire message very long. There's a lot to absorb visually and I'd argue most users won't even get the difference between the two sentences:

Wouldn't the first part be enough? I'd consider to display and speak() this simplified version:

This color combination may be hard for people to read.

Not sure there's the need for a "violation fixed" message.

[AmartyaU]

I agree. When I was initially testing, it took me some time to realize both error messages were different.

I also think error messages shouldn't be this long, because we are expecting a long span of attention from users which users don't usually have.

On the other hand, just having "This color combination may be hard for people to read" can induce learned helplessness in users (repeated failure or errors combined with inability to form consistent explanation may induce frustration in users).

[afercia]

Yeo I'd agree there's a need to find a good balance. Not sure it can help, but for the alt text description we've tried to balance the need for a short message and the need to provide sufficient information by linking to a proper resource:

[afercia]

Discussed during today's accessibility bug-scrub, agree to recommend to simplify the messages.

[gziolo]

This color combination may be hard for people to read.

Let's update it as suggested by @afercia and it should be ready to land :)

We also need to have a similar notice with VoiceOver support for Heading level validation as described in the parent issue. I'm saying, in case you are interested in opening another PR.

[AmartyaU]

Thank you for the feedback @afercia @gziolo! I updated the messages in speak. I can also try my hand at the parent issue.

[gziolo]

It works great, thanks @AmartyaU for working on it. Nice job 💯