News for hackers. Stuff that matters.
Re:Launch HN: Hyperbeam API (YC W22) – Multiplayer embeds of... by unfocussed_mike on Tuesday February 22, 2022 @03:44PM (#30433482)
> indeed, that's an advantage of your approach over screen sharing.

In what way, particularly? it's streaming the video and audio from a remote browser instance, so surely that means all participants will have the same accessibility settings in the remotely viewed instance.

Re:Launch HN: Hyperbeam API (YC W22) – Multiplayer embeds of... by mwcampbell on Tuesday February 22, 2022 @03:46PM (#30433502)
Yes, that's true today. But since they're running a version of Chromium that they control, they can in principle modify it to push semantic information from the Chromium accessibility implementation along with the video stream. That would be much harder for, say, Zoom screen sharing to do, because of the way the platform accessibility APIs are designed.
Re:Launch HN: Hyperbeam API (YC W22) – Multiplayer embeds of... by unfocussed_mike on Tuesday February 22, 2022 @04:54PM (#30434453)
Ahh -- I see. Informative answer, thank you :-)
Re:Launch HN: Hyperbeam API (YC W22) – Multiplayer embeds of... by ScottyFillups on Tuesday February 22, 2022 @03:48PM (#30433532)
To add to mwcampbell's response, my cofounder Amby proposed a possible solution:

> But now that we are looking at the bigger picture, we could implement full-fledged accessibility support where we serialize the accessibility tree and send that over instead of the video stream.

What are your thoughts on this approach?

Re:Launch HN: Hyperbeam API (YC W22) – Multiplayer embeds of... by mwcampbell on Tuesday February 22, 2022 @03:50PM (#30433567)
You probably want to send the accessibility tree in addition to the video stream, not instead of it. Luckily the Chromium accessibility tree can already be serialized and pushed, because Chromium does that between the renderer and browser processes.