iframe-screenreader-chrome-bug
This code sample illustrates a bug that can be reproduced in Chromium-based browsers with the JAWS and NVDA screen readers. Occasionally reproducible with VoiceOver, too.
Issue
When the source page in an <iframe> is swapped out for another page, e.g. through a form POST or a window.location change, the screen reader is no longer able to interact with the iframed content as expected.
Logged as Chromium Issue 1179922
Try it yourself
- Download this source code on a Windows machine.
- Turn on NVDA or JAWS.
- Open /index.html in Chrome or Edge.
- Navigate into the "Add Menu Item" iframe.
- Notice the screen reader can navigate through and read all the content in "Step 1" of the "Add Menu Item" iframe content.
- Press the "Next step" button in the "Add Menu Item" iframe.
- Try to navigate through "Step 2" of the iframe content. Notice that while it may read a few sporadic pieces, the screen reader is largely silent. Tabbing between fields moves keyboard focus but the screen reader says nothing.
- Press the "Next step" button.
- Notice the same behavior in "Step 3" as in "Step 2."
(I tried refreshing the JAWS virtual buffer but that didn't help.)
Compare to OS X VoiceOver with Chrome
- Try the same steps in Chrome with VoiceOver on a device running OS X.
- Notice that sometimes it reads the content and sometimes it doesn't. Seems like it takes a few moments for the screen reader to process the new screen?
Compare to Firefox
- Try the same steps in Firefox with NVDA or JAWS.
- Notice you can successfully navigate through the controls and the screen reader reads accordingly.
Compare to non-iframed content
- Open /embed1.html in Chrome or Edge.
- Notice you you can successfully navigate through the controls and the screen reader reads accordingly.