> It was specifically flagged during our diligence process of S2 Systems, the company we acquired for the Remote Browser Isolation (RBI) technology. It has been an engineering project that I have personally followed since we acquired S2 nearly two year ago.

Then why is it that, as far as I can tell, Cloudflare hasn't publicly acknowledged the problem before now?

For example, the blog post announcing the acquisition of S2 said:

> (4) Transparent user experience: S2 remote browsing feels like native browsing; users are generally unaware when they are browsing remotely.

This is emphatically not the case for screen reader users, and there was no acknowledgement that that was a challenge yet to be solved. There was also no acknowledgement in the product launch blog post during Security Week [2], and I haven't been able to find any in public documentation, though perhaps I just haven't hit upon the right search term.

> How the web is rendered and the diversity of web pages, especially dynamically updated pages, makes many solutions that seem obvious not tenable. We need to validate the solution we deliver will work across all the complexities of the web and across a broad range of accessibility devices while, at the same time, not introducing new threats.

To be clear, I know why the more simplistic proposed solutions, which amount to sending down the original HTML or some sanitized version of it, would go against the goals for this product, particularly around security. I guess it's also plausible that my proposed solution, using the Chromium accessibility tree to reconstruct just enough of an HTML DOM to expose the needed information, would reopen some types of local browser escape exploits. Your team certainly knows way more about those vulnerabilities than I do.

Edit: OK, I'm convinced; I just found a report of a use-after-free vulnerability (now fixed) in Chromium accessibility code [3]. I guess I really didn't grasp how hard this is.

> In the meantime, we provide our customers a way to bypass the RBI technology to accommodate their visually impaired employees. In these cases, we recommend that additional safeguards be put in place for these employees' machines to guard against potential security compromise.

I'm sure the mechanism for configuring this bypass is documented. But does your documentation specifically call out the accessibility limitation of your product, the need for this workaround, and the recommended additional safeguards for these employees' machines?

> As we solve these challenging problems ourselves, we will share what we've learned, how we overcame challenges, and we will not do anything to restrict the intellectual property behind the solutions so the entire industry can benefit.

I hope that Cloudflare will not develop these solutions in a vacuum, but will consult with blind people who have the expertise to help ensure you're on the right track. I still offer my advice, free of charge; as I said in my other reply, my intent in the earlier comment with the rough time estimate wasn't to push for you to hire me. But enough about me; the point is that accessibility solutions developed for us shouldn't be developed without involving us.

On reflection, I think the real problem isn't how long it's taking to make the product accessible, but the fact that you went ahead and launched the product without an accessibility solution and with no public acknowledgement of the problem (as far as I can tell). I don't think it's right to sweep our needs under the rug like that.

[1]: https://blog.cloudflare.com/cloudflare-and-remote-browser-is...

[2]: https://blog.cloudflare.com/browser-isolation-for-teams-of-a...

[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=105539...