Accessibility is broken when iframes are inside of webviews

[segedyjr]

• Electron version: 1.8.4
• Operating system: Windows 10

Expected behavior

I have a web page, call it level1.html, that includes a webview element with src set to another page, level2.html, and level2.html includes an <iframe> element with src set to a third page, level3.html. Each page has a button and an input field.

I would expect that tabbing through all three buttons and input fields would cause the screen reader (JAWS 18 or NVDA 2018.1.1 in this case) to read the buttons and input fields properly.

Actual behavior

The screen readers read the button and input elements from level1 and level2 correctly, but do not read the elements from level3.

How to reproduce

$ git clone https://github.com/segedyjr/electron-quick-start
$ cd electron-quick-start
$ npm install
$ npm start || electron .

Turn on a screen reader and start tabbing around. You'll notice that the screen reader works on level 1 and level 2, but not on level 3.

From what I can tell, the OS isn't getting the accessibility information it needs (using Inspect and acevent.exe in Windows)

[wnayes]

It appears that the accessibility tree is being generated for the iframe, but when browser focus moves into the iframe, "accessible focus" is not correctly following it. Screen readers instead perceive that focus has moved back to the root document of the outer page.

This issue makes iframes within webviews inaccessible to users of screen readers.

[lawrencecushman]

For what it's worth, this is resolved in Electron 2

[segedyjr]

Do you have a working example that demonstrates it working in Electron 2? I can reproduce the problem with version 2.0.3.

[BrendanMcK]

Also confirming that this is still not working in 2.0.3

[ZacWalk]

I can confirm still not working in electron v3.0.6 or electron v4.0.0-beta.5.

[lawrencecushman]

Sorry, missed these messages. I'm not sure about those versions, but 2.0.10 works.

[segedyjr]

I'm seeing it not work for 2.0.10, so I'm not sure what we're doing differently. I just pulled this example and changed the electron version to 2.0.10 and still see the problem.

[segedyjr]

This continues to be a pretty significant pain point for my development. Are there any plans to address this issue? If not, are there any thoughts on a potential timeline for addressing it?

[rachitGulati]

Any updates on this? Or any hack that can help us to at least keep it working till we have a permanent solution.

[segedyjr]

We've been looking at using BrowserView instead of WebView. This seems to give us what we need.

[electron-triage]

Thank you for taking the time to report this issue and helping to make Electron better.

The version of Electron you reported this on has been superseded by newer releases.

If you're still experiencing this issue in Electron 6.x.y or later, please add a comment specifying the version you're testing with and any other new information that a maintainer trying to reproduce the issue should know.

I'm setting the blocked/need-info label for the above reasons. This issue will be closed 7 days from now if there is no response.

Thanks in advance! Your help is appreciated.

[electron-triage]

Thank you for your issue!

We haven't gotten a response to our questions in our comment above. With only the information that is currently in the issue, we don't have enough information to take action. I'm going to close this but don't hesitate to reach out if you have or find the answers we need, we'll be happy to reopen the issue.

[sarthak-saxena]

Still facing the same issue, the accessibility tree for webview is not getting generated as expected hence screen readers are not able to go inside webview elements.
Is using BrowserView a solution to this?

[segedyjr]

BrowserView solved the problem for us.