I love this idea but it's broken a bit if webcams and mics can't be used at least for my use-case. If I had some time I'd look into extending that with this project.
If they're USB devices, you can try tweaking the docker-machine VM definition in whatever hypervisor your Mac uses, so that the devices are mounted directly in the VM and are thus available to containers.
Have a look at Qubes OS then : https://qubes-os.org. It's even more secure (hardware VT-d virtualization), with a nice gui and allows to use webcams and microphones securely.
Pulseaudio has network support. You should be able to share your microphone. Of course you need to run pulseaudio inside the container, too. So it's no longer an application container, but a system container.
I used system containers in the past, they are not always easy. No idea whether it would work with podman.
Now that I think about it: The browser obviously uses the display of the host. How? Only over X11 network protocol? That worked in the past, does it still work today? I thought modern browsers would need /dev/dri/? If that is made available, why would Webcams not be possible?
If you read the examples you'll see that they mount /tmp/.X11-unix in the container, thats where the X-Sessions Unix domain socket is. You can do the same for pulseaudio. But you shouldn't. Use Wayland and Pipewire if you are actually interested in using this as a security measure, since they are built for sandboxing.
> I thought modern browsers would need /dev/dri/?
They only need it for hw-acceleration. You can also give the container access to it if you need that.
For Chrome inside a container, I also install the Google Talk plug-in. Unsure if that's still required, but things work well.
[1]: i.e. "--group-add plugdev", "--device /dev/hidraw4", "--device /dev/video4", "--device /dev/snd", "--device /dev/sri" and similar