Not able to link BrowserView accessibility tree to the main accessibility tree

[sarthak-saxena]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

Problem description

I have a use case where I have embedded a browser view inside browser window. Since browser view is not part of the DOM hierarchy hence the accessibility tree is not linked to the main window(parent browser window).

So my use case is to link the browser view accessibility tree with the main window accessibility tree such that screen readers(JAWS/NVDA) are able to enumerate all the possible landmarks for navigation

Please check this repository for source code to reproduce the issue
https://github.com/sarthak-saxena/electron-browserview-issue

Please also find attached a video in which we can see that keyboard navigation is not moving focus to browser view since it is not part of the main BrowserWindow accessibility tree.

Expected Behavior

There should be a way to link the accessibility tree of browser view to the main AX tree.

Actual Behavior

No way to link the accessibility tree of browser view.

[sarthak-saxena]

@codebytere I have attached a link to the repository for source code to reproduce the issue
https://github.com/sarthak-saxena/electron-browserview-issue.
Can you please check & help out on this :)

[codebytere]

Some digging into this unfortunately confirms that this isn't possible given that way that BrowserViews are implemented by design. WebViews are part of the primary webContents even though you can for example open devtools for the webview only - this is because we attach the webView to the primary webContents as an iframe. BrowserViews, while they are intended to be an alternative to WebViews, are isolated views by contrast - they're not linked into the primary webContents. You have to navigate between the two views in order to trigger accessible tab navigation for the webContents of each. Screen readers should themselves be able to handle this.

[sarthak-saxena]

See, the accessibility tree of BrowserView when embedded inside a BrowserWindow is separate & is not linked.
So, if we focus on the main BrowserWindow then while enumerating all possible landmark heading or links on the screen reader, it shows only for BrowserWindow & not for the embedded BrowserView
& similarly, if we focus BrowserView embedded inside of BrowserWindow, it shows enumeration only for the BrowserView.

So our use case here is when the BrowserWindow is focussed which has BrowserView embedded inside that, then the landmark enumeration for links or headings should show all the possible headings or links on that page.
Basically, the problem here is that while enumerating, headings or links of BrowserView are not getting counted in

I agree with your point that accessible tab navigation between the webContents of BrowserView embedded inside BrowserWindow is possible but an important accessibility aspect of landmark enumeration as described in this comment is missing and should be fixed or there should a workaround to achieve this functionality.

Please check the video(with audio) for more clarity on the issue
https://www.loom.com/share/5ffb738b77f7472d8039a4c66a2c905e
@codebytere can we please reopen the issue if you feel this is a problem