Accessibility/Windows.Next

In the short term, we want to try to squeeze as much performance as possible out of the current e10s Windows a11y implementation. This could include optimising hot paths, expanding the COM client handler cache (e.g. bug 1363595), etc. However, we're reasonably certain that longer term, this is not sufficient. Dealing with this is going to require a significant refactor of our Windows accessibility implementation. Possible strategies are discussed below.

1. Caching the entire tree in the parent process (a la Chrome's approach)

• Push the entire tree from content to parent and push deltas whenever content changes.
• Significant departure from current approach.
• This currently works for Chrome in that it allows for pretty decent performance in most cases.

Advantages:

• We know it works.
• Doesn't require changes in AT.

Disadvantages:

• Will take time to get right (cache invalidation, etc.).
• Still takes AT a long time to load massive documents; e.g. ARIA 1.1 spec, AppVeyor.
• Lots of wasted calls with heavily dynamic documents.
• Huge memory waster.
• Depends on in-process injection.
• Will not work with Narrator.

Future risks:

• This is really not a future proof solution. Large documents are not going away, and the web is getting more dynamic, not less.
• We could sink a whole lot of time into this and we'll eventually have to replace it anyway.
• Mostly just including this option for completeness. :)

2. Kill buffers by extending IAccessible2

• Extend IAccessible2 to provide bulk fetch and search APIs.

Advantages:

• Still using IA2, so can leverage existing code.
• We can directly influence IA2. Potential for faster innovation.
• Works on all versions of Windows.

Disadvantages:

• Every browser has to implement the new APIs.
• So does every AT.
• Could take a long time to develop and ship.
• Will not work with narrator.

Future risks:

• Microsoft don't care about MSAA/IA2. Might run into trouble if something we need goes away (e.g. COM proxy registration or oleacc).
• Might have trouble convincing other AT to support this.
• Won't work in Windows Store and thus Windows 10S (but non-Edge browsing engines aren't allowed in the Store anyway, so this is probably irrelevant).

3. Kill buffers by using UI Automation

• Use UI Automation as Edge does.

Advantages:

• Microsoft is behind this.
• ATs are already supporting this for Edge.
• One path for all browsers/AT means less duplicate work overall and shared stake.
• Works with Narrator.

Disadvantages:

• Only works on Windows 10. The necessary stuff probably won't get backported.
• As such, users on Windows 7/8 would be stuck with crappy perf.
• UIA still has pain points concerning performance for browsers. We'd be waiting on Microsoft to fix these.
• We'd either have to cache the entire tree in the parent or work with Microsoft to find a way to allow UIA Core to work in the content process.

Future risks:

• We'd be beholden to Microsoft for any improvements to UIA.
• Our ability to innovate is thus hampered/significantly slowed down.

4. Cache the entire tree *and* support UIA (1 and 3 combined)

• We cache the tree and expose IA2 to get better perf for Windows 7-8 users, while supporting UIA for Windows 10.

Advantages:

• We support Windows 7 through 10.
• Microsoft is behind this.
• ATs are already supporting UIA for Edge.
• One future path for all browsers/AT means less duplicate work overall and shared stake.
• Works with Narrator.
• Caching the tree mitigates the problem of getting UIA Core into content.

Disadvantages:

• Still have to support old code while there are Windows 7-8 users.
• Supporting very separate code paths.
• UIA still has pain points concerning performance for browsers. We'd be waiting on Microsoft to fix these.

Future risks:

• Supporting two very separate code paths is a maintenance nightmare/time sink and might hold us back.
• We'd be beholden to Microsoft for any improvements to UIA.
• Our ability to innovate is thus hampered/significantly slowed down.

Next steps for making the decision

• Are there other strategies?
• Because UI Automation is Windows 10 only, we need metrics concerning AT usage with Firefox across various operating systems.