| Your suggestion is probably the correct solution technically speaking, as it funnels the screen reader I/O stream through browser APIs. The immediate objection is that most popular screen readers (JAWS, NVDA) are native apps and not browser extensions, (some?) extension-based screen readers being immature. mwcampbell articulated it as much in a different post, asking for a native desktop client as opposed to a browser based client. Alas, 'native desktop client' is a different technology than Cloudflare RBI, subject to different tradeoffs, which may well be at odds with the goals of Cloudflare RBI as a product. A hypothetical browser accessibility protocol is likely to prove insufficient, as native screen reader apps will themselves become an attack vector. Unlocking the situation requires a wider industry buy-in beyond Cloudflare. Screen readers must be rearchitected with security in mind. IT departments must manage accessibility apps. Advocacy groups must commit to roadmaps that include a lot of change, and that may even degrade the status quo for many years to come. Given that existing screen reader apps have decades of engineering already poured in, it will be hard and expensive to enact change. A good early step could be creating an industry standard various entities can rally behind. https://www.afb.org/blindness-and-low-vision/using-technolog... https://chrome.google.com/webstore/detail/screen-reader https://news.ycombinator.com/item?id=28031514 https://blog.cloudflare.com/cloudflare-and-remote-browser-is... |