Closed jessegreenberg closed 2 years ago
This is blocking description in Friction and Quad, and possibly others, I'll try to have it done today.
One quick patch
Ok, this was pretty straight forward once we factored out AnnouncingControlProperty. I am happy with the way it looks. I have confirmed that friction is fixed. @jessegreenberg, can you please review the implementation, and note that currently canAnnounceProperties and descriptionCanAnnounceProperties are not used at all in the project.
Things are looking good, well done on the abstraction of AnnouncingControlProperty. Updates to Voicing.ts look good.
It isn't working quite yet though. I hear voicing responses when voicingVisible
if false. I think because UtteranceQueue wasn't updated to check on the new Properties here:
https://github.com/phetsims/utterance-queue/blob/9a061765a425d1304ec70d0a8d6ee16fe7ffe6e5/js/UtteranceQueue.ts#L563-L565
Oops! I'll take a look. Sorry about that.
Ok, tested and ready for actual review.
Disposal calls added above.
I tested this by watching responses in the a11y view and with ?printVoicingResponses and saw that this is working very well.
For my own understanding, can you describe the typing here
class Utterance implements FeatureSpecificAnnouncingControlPropertySupported {
How/why does Utterance implement FeatureSpecificAnnouncingControlPropertySupported
? This enforces that Utterances has those fields?
Otherwise everything seems great here.
The key feature is that we want the type FeatureSpecificAnnouncingControlProperty
that UtteranceQueue can use. Having Utterance implement FeatureSpecificAnnouncingControlPropertySupported (the object) ensures that Utterance has those keys. Note the error when you commend out descriptionCanAnnounceProperty.
Index: js/Utterance.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/Utterance.ts b/js/Utterance.ts
--- a/js/Utterance.ts (revision 7780764fe8ed6004ff75b2831c172a4f6b2093a0)
+++ b/js/Utterance.ts (date 1656607778624)
@@ -115,7 +115,7 @@
public readonly canAnnounceProperty: AnnouncingControlProperty;
// If the value of this Property is false, this Utterance will never be announced by AriaLiveAnnouncer.
- public readonly descriptionCanAnnounceProperty: AnnouncingControlProperty;
+ // public readonly descriptionCanAnnounceProperty: AnnouncingControlProperty;
// If the value of this Property is false, this Utterance will never be announced by SpeechSynthesisAnnouncer.
public readonly voicingCanAnnounceProperty: AnnouncingControlProperty;
The typescript error here is very informative:
TS2420: Class 'Utterance' incorrectly implements interface 'FeatureSpecificAnnouncingControlPropertySupported'. Property 'descriptionCanAnnounceProperty' is missing in type 'Utterance' but required in type 'FeatureSpecificAnnouncingControlPropertySupported'.
Makes a lot of sense, thanks. That was all for this one, closing,.
We currently have
Utterance.canAnnounceProperty
which prevents the Utterance from being announced by the UtteranceQueue when it is false. The problem is that when an Utterance is shared and used for both Voicing and Interactive Description (such as by an Alerter), if Voicing.canSpeakProperty (forwarded to the Utterance.canAnnounceProperty) is false content will not be heard for Description of Voicing.To fix this, we need a dedicated Property to control the output of each feature.
UtteranceQueue will check the state of these Properties an attemptToAnnounce with something like
We liked this way the best because Utterances can still be used in more than once UtteranceQueue, and keeping the
canAnnounceProperty
(for general use) along with the other two new ones (for PhET use).Some brainstorming notes from the meeting where we thought about other options
@zepumph offered to do this as part of a review for the collection of canAnnounceProperty issues.
EDIT: Logic in above snippet could potentially be simplified: