that page says that Narrator previously didn't work with Firefox. Did NVDA or other screen readers work? How could screen reader users use Firefox?

@sixohsix Yes, NVDA and JAWS have worked with Firefox since version 1.5 back in 2006. This all took a bit of a hit in 2017 when Project Quantum was rolled out. Version 57 was quite bad, 58 to 61 fixed most of the bugs, but the performance was not as good as it had been pre quantum days. This new project aims to correct design decision mistakes that were made during the Project Quantum development phase, while keeping full compatibility and extending to Narrator.

I understand. Maybe I'll look into the code changes as I don't understand how something can work with NVDA but not with Narrator, since I thought they used the same Windows API.

@sixohsix NVDA uses a multitude of Accessibility APIs available on Windows, ranging from the old MSAA plus the Linux Foundation add-on called IAccessible2, which is what LibreOffice, Firefox and chromium implement, to Java AccessBridge to Microsoft's MSAA replacement called UI Automation. Chromium implements that too since Microsoft got on board, but it is still not as good as the IAccessible2 stuff. Narrator supports UIA only.

@sixohsix Narrator can only work with MSAA and IAccessible2 supported applications through an IA2-to-UIA bridge that Microsoft implemented. The performance isn't really that good, since it all has to do cross-process calls, but with Firefox with its previous implementation, because of double-cross-process-calls, the performance was unbearable. So yeah, Narrator might have worked, but usability due to lack of performance just wasn't there. This all will be better now with everything cached.

@sixohsix A minor correction: As far as I know, the IA2 to UIA bridge runs in-process. Even though UIA clients run out-of-process, they can do batch queries and tree walks and the IA2 queries then get dispatched in-process. So, performance with Narrator will be significantly better with the cache, though still not as fast/reliable/correct as it would be if Firefox had a native UIA implementation.

@sixohsix A native UIA implementation is out of scope for this project, but this project is a foundational prerequisite for any work related to UIA. We hope to start looking into native UIA in 2024, maybe earlier if possible, but absolutely no promises at this stage.

@jcsteh Yeah I understand that UIA is out of scope for this project. Do you know by chance how good Chromium's UIA implementation is by now? Is it anywhere near production-ready yet, or is it still better to rely on IA2 for JAWS and NVDA at this stage?
@sixohsix

I think IA2 is still better for JAWS and NVDA, especially JAWS, since some features there depend specifically on buffers. I believe it's come a long way, though. I honestly don't know for sure where it's at; I haven't looked at it in a while. There are annoying deficiencies in the way UIA maps the web, though; e.g. overloading LocalizedControlType, stuffing ARIA properties into ARIAProperties instead of proper native mapping, etc.

@jcsteh Yeah, especially the ARIA mappings offloads a lot of responsibility to the screen readers to interpret that browsers traditionally are much better at, IMO. And what is the ARIA to native mapping table for then anyway, if uIA still requires the screen reader or other assistive technology to interpret the attributes themselves? This creates unnecessary friction.

@jcsteh Now that Firefox is caching the world, I wonder if it's actually worthwhile for Firefox to have a native UIA implementation. Microsoft's attempts to remake Windows into a more locked-down platform didn't actually succeed, and now they seem to have retreated from that. Why not just stick with the accessibility API that co-evolved with the screen readers and modern browsers that people actually use, and let Narrator keep using Microsoft's bridge?