I am wondering if this should be put in a more domain-specific method in the audio manager, maybe a playTryConstrainMoveTopLevelBlockSound() or something? It would hide the implementation details and puts the API a bit closer to just playing sound files, though it's a balance on where we represent the domain context and decision making. I defer to you (though this is how I was thinking of representing other similar solutions in the screen reader design doc).

I think that feels a little over-specified, but I agree it would be nice to avoid magic constants. WDYT about adding playErrorBeep()? I don't think we want separate tones for everything, basically just a "nope" beep and then the scope-change ones, which I think can be individually specified since the frequency is based on the nesting level.

Error beep might be a tad generic since different 'error' cases may justify playing that (but the same tone used in each place might be a bit confusing). I like that more than the magic number, but there are definitely pros/cons. Might be worth getting a third opinion from someone else on the team to see if we can make a case one direction or the other.

@maribethb do you have opinions here? I think we should use the same beep for all errors; this is how OSes normally work, and conditions where we want to beep are typically accompanied by a toast which should clarify the problem/what needs to be done to address it.

I think using the same error beep for all the errors makes sense unless/until we find out otherwise in testing, and until then, a playErrorBeep method sounds fine.

If we do end up having different types of error beeps later, then potentially having an enum of them to give as an argument would work (instead of the really long method name described above, and more extensible as developers could pass their own number if they wished). but for now just the one value seems fine.

Updated accordingly, thanks!