Accessibility/Electrolysis

Warning: This is from an older e10s effort. For more recent events please visit Accessibility/Electrolysis2

Summary

Topic: e10s a11y, bug 646596

Background: Electrolysis

Approach: each process has own accessible tree, i.e. no unified tree.

Motivation: every process keeps its DOM tree and its frame tree, keeping accessible tree in a process allows to minimize proxy and caching requirements, from AT and browser interaction perspective it allows AT keep working if one process hangs.

Details

Windows

Approach 1: Each process has own window (HWND), no unified tree. This is most performant approach and it allows AT to communicate with documents independently. If AT needs to crawl hierarchy then they need to operate on HWND hierarchy.

Approach 2: Each process has own window (HWND), unified MSAA tree. When process boundaries are crossed then rely on windows marshaling magic. The boundaries crossing makes sense for out-of-process calls.

The approach 1 breaks user experience in NVDA bug 649720. The same time certain screen readers feels fine with this approach. Maybe AT sniffing is a way to go.

Actions: Work with AT vendors to make their products working with new Firefox.

Backward compatibility:

1. keep a preference allowing to run browser in one process,
2. make installer to autodetect if incompatible AT is running, switch on the preference if needed.

Linux

AT-SPI is going to work with unified tree by socket mechanism currently used by plugins (bug 480317). The chrome process gets atk plugid from content process, creates the socket and connects it with the given plugid. Communication between treads is preformed by IPDL.

Mac

Needs investigation. Maybe it makes sense to get it working on one-process Firefox at all before that. Otherwise it's hard to check whether we were succeed or not.

Internals

1. accessibility service lives in each process (that makes DOM events and nsIWebProgressListener work)
2. application accessible should live in chrome process
3. root accessible should be a root in own process (not per a window) (that makes DOM events working)

Automated tests

Mochitests are depended we have unified tree, we should replace these assumptions on equivalent ones.

Tools

1. Change DOMi UI to inspect accessibility (maybe DOMi itself requires changes to work on multiprocess browser)
2. What's happen with other tools (just curious). If accProbe is based on hierarchy then it shows only chrome process tree. Work with tool developers to make sure they work with Firefox.

Manual test plan

All of these tests must be performed with various assistive technologies, primarily screen readers since these make the most use of accessibility APIs.

Single tab

1. Make sure electrolysis-enabled Firefox with only one tab open behaves identical to non-electrolysis Firefox. This is assuming the first tab always lives in the chrome process.
2. Make sure traversal between chrome and content does not lead to any unexpected results.
3. Test forms mode in various screen readers.

Multiple tabs

1. Make sure multiple tabs behave similar to the first tab which lives in the chrome process.
   1. Activate links and make sure this works as expected. Also use links list or other listing features of ATs to make sure they still get relevant information.
   2. Test forms mode. Make sure screen readers transition properly in and out, get text updates in text fields/textareas etc, and are able to activate other elements such as radio buttons or checkboxes without using forms mode.
   3. Test the return to previous page.
   4. Test mouse cursor routing to make sure people are still able to click elements in case web page authors ttrap keyboard access in their web apps.
2. Test transition of keyboard focus between content and chrome.
   1. Make sure focus doesn't get lost when tabbing between UI elements of the browser and the page, like the tab bar, awesome bar, search box, and back into the content area.
   2. Open and close both regular menus and context menus to make sure screen readers don't get stuck on any transition.
   3. Open and close chrome dialogs like About window, Options dialog, printing etc and make sure screen readers keep track.
3. Test accessible tree traversal with screen reader tools (e. g. object navigator in NVDA) to see if it gets stuck anywhere when transitioning from content to chrome and back.