3 ms·

There are several problems with that approach. First, there's not enough information in the serialized accessibility tree to reconstruct the DOM.[1] Second, th

by ggreer 5y ago

There are several problems with that approach. First, there's not enough information in the serialized accessibility tree to reconstruct the DOM.[1] Second, the serialization format is an internal API, so there are no constraints on backwards compatibility. It can change in any version of Chromium. In fact, the interface is updated all the time.[2] Cloudflare would have to constantly update their JS client to handle those changes. It's not an abstraction that can be relied upon. Third, the bandwidth and latency requirements for inter-process communication are far higher than what is available for most client-server communication. Even if the API were stable, I doubt it would be feasible to use on typical Internet connections. If you don't believe me, go to chrome://accessibility/ and click "Start recording" on a tab. I did this for an IRCCloud tab and got 4500 events in approximately 2 seconds. 1. https://chromium.googlesource.com/chromium/src/+/HEAD/docs/accessibility/overview.md#concepts https://chromium.googlesource.com/chromium/src/+/HEAD/docs/a... 2. https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/public/web/web_ax_object.h;bpv=1 https://source.chromium.org/chromium/chromium/src/+/master:t...

mwcampbell 5y ago
> First, there's not enough information in the serialized accessibility tree to reconstruct the DOM. There doesn't have to be enough in there to reconstruct the original DOM, just enough to expose all of the information that screen readers and other accessibility tools need. The fact that that information would be exposed through an HTML DOM in this case is irrelevant; we know the Chromium accessibility tree has all the necessary information. > Second, the serialization format is an internal API, so there are no constraints on backwards compatibility. OK, you got me there. Maybe the server side has to go all the way and construct the HTML. > Third, the bandwidth and latency requirements for inter-process communication are far higher than what is available for most client-server communication. OK, again, maybe the server side has to digest the data some more before sending it. But at least Chromium is already pushing serialized tree updates. I'll withhold a rant on how it could be much worse.

by ggreer 5y ago

mwcampbell 5y ago

> First, there's not enough information in the serialized accessibility tree to reconstruct the DOM. There doesn't have to be enough in there to reconstruct the original DOM, just enough to expose all of the information that screen readers and other accessibility tools need. The fact that that information would be exposed through an HTML DOM in this case is irrelevant; we know the Chromium accessibility tree has all the necessary information. > Second, the serialization format is an internal API, so there are no constraints on backwards compatibility. OK, you got me there. Maybe the server side has to go all the way and construct the HTML. > Third, the bandwidth and latency requirements for inter-process communication are far higher than what is available for most client-server communication. OK, again, maybe the server side has to digest the data some more before sending it. But at least Chromium is already pushing serialized tree updates. I'll withhold a rant on how it could be much worse.