How should we handle browser VoIP behind a Cisco WSA proxy?

Probably, yes. An HTTP web proxy isn't a general-purpose UDP forwarder, and the page loading successfully doesn't mean the audio path is working. Check the provider's network requirements and allow the documented media traffic through the firewall and NAT, with an approved path around the web proxy.

Start by checking whether the client can reach the listed STUN endpoints and whether RTP/RTCP packets are going out and coming back. A packet capture or firewall logs should help distinguish a blocked path from a problem elsewhere in the call setup.

Try not to put voice media through an extra proxy hop unless there's a good reason. Audio can be sensitive to latency, jitter and packet loss, so a permitted direct path through the firewall is generally preferable. Keep the normal web proxy for the browser traffic if that's how your environment is set up.

Ask the call center vendor about its TURN support and fallback options. STUN helps a client discover its network path, while TURN can relay media when a direct path won't work. The fact that another meeting app works doesn't establish that this service uses the same relay or transport options.

Get the vendor's supported configuration rather than assuming a relay will fix every proxy restriction. You still need to allow whatever destinations and transports that configuration requires.

Proxy is doing a lot of work as a word here. A web proxy, a SOCKS proxy and a SIP proxy serve different purposes. SOCKS5 can support UDP, but that doesn't mean this browser application or your WSA configuration can use it for media. Verify support with Cisco and the service provider before designing around it.