A super late comment, fwiw (non-blocking).
At its core is the way gender gets specified. It is optional, so it's really up to the engine to "self identify" a gender. I agree we should be more inclusive so perhaps gender being a binary isn't the right thing (enum values should maybe have more values), but I don't know if I understand the motivation for removing it entirely. The engine author is really the owner of the voice, so why is it wrong to be able to say a voice is male, female, or neither (by omission)?
Thanks David for your comment!
Re enum:
I investigated adding more values to the enum, see solution idea #2 (https://docs.google.com/document/d/1eS-XDUq-uRfRVP3jvlfAVSjG_hejvjzL0AYzBfGb0UI/edit#heading=h.tnxp6qggv2x8)
However, we landed on removing gender entirely for several reasons, including that gender is a spectrum so even the most well-intentioned enum is not going to capture all values, and more importantly, that gender is not actually such an important descriptor of a voice to be the only descriptor we include (see solution idea #3, https://docs.google.com/document/d/1eS-XDUq-uRfRVP3jvlfAVSjG_hejvjzL0AYzBfGb0UI/edit#heading=h.1m874yo3atie)
By including gender in these APIs, we are saying that gender is an important attribute of a voice -- and right now it's the only attribute we expose (we don't have age, or emotion, etc). This sends a message to developers that Chrome thinks gender is important for end users. But gender is in many ways a social construct (unlike age, for example) and it's not a binary, so saying it is important when picking a voice can be non-inclusive.
Happy to chat more about this in person or on the phone!
Comment 1 by katie@chromium.org
, Jul 16