nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
Other
2.07k stars 624 forks source link

Dynamically loaded content inside iframe ignored #6457

Open Regis-ID-and-T opened 7 years ago

Regis-ID-and-T commented 7 years ago

Hello NVDA rockstars.

I am a learning technologist who develops dynamic content inside of learning management systems for tens of thousands of students. I have no idea whatsoever how NVDA works.

Often, my content exists as an html file that is shown inside of an iframe within a page in a learning management system.

When my html file contains content that is built on the fly via javascript, I find that NVDA does not capture the dynamic content... all dynamically generated headings and lists and etc are ignored as though they never existed. Generally, this dynamic content loads in less than 1 second.

There have been several related postings to an accessibility listserve run by my learning management system regarding iframe content being ignored; the theme I notice is that dynamic content is usually included within those iframes. Further, it seems that most of the super expensive screen readers are able to handle the dynamic content when NVDA cannot.

Is it possible to have NVDA do a periodic check to see if content has been added to an iframed html page via javascript?

I sincerely believe that this double-checking for dynamically generated content within iframes would have a huge positive impact on the accessibility of learning management system based content for students because there is a lot of this type of content.

Thanks for any consideration and for any explanations as to why my question is stupid or why the related request is easy/impossible.

derekriemer commented 7 years ago

Hi:

NV Access, the non-profit that develops NVDA has a set of tests that they have run for detecting dynamic content, but there is some rare cases in some systems where the dynamic content doesn't quite load properly. Can you give browsers you have tested this on, and a test page that shows us the bug? Also, what happens when you press nvda+f5? That should have NVDA redraw the page for you, and if it works, that suggests the issue is with detecting the load.

Thanks.

Regis-ID-and-T commented 7 years ago

Thanks much for the quick response!

I and others had tested using multiple browsers on pc, weeks ago. (Chrome, FF, IE; all the 'latest' at the time.)

Just now, I tested using Chrome Version 53.0.2785.143 m. Immediately before my test today, I updated my NVDA... and... now it seems that the single keys shortcuts for headings and list items etc have stopped working in EDIT my latest chrome but is still working in other browsers /EDIT ... or I am doing something dumb when pressing the h and l and i keys with and without my chosen NVDA modifier.

Back on topic... Some exemplar files can be found in the following repository: https://github.com/Regis-ID-and-T/WYSYWIDGETS/tree/master/locally_hosted A specific set of files that could be used from that repository are: https://github.com/Regis-ID-and-T/WYSYWIDGETS/blob/master/locally_hosted/wysywidgets.html https://github.com/Regis-ID-and-T/WYSYWIDGETS/blob/master/locally_hosted/wysywidgets.css https://github.com/Regis-ID-and-T/WYSYWIDGETS/blob/master/locally_hosted/wysywidgets.js If you don't have time to download and install those three files, and then iframe the html file into some other server, I'm glad to post it somewhere.

Thanks much for your help!

EDIT I haven't tried the nvda+f5; would've tried it now, but am struggling to get nominal stuff working. Thanks, will pass this info along. /EDIT

derekriemer commented 7 years ago

CC @jcsteh

Regis-ID-and-T commented 7 years ago

I am glad to do whatever testing you may suggest, and to screen-record or log testing sessions, while working within our learning management system since I assume that you guys don't have editing access inside all learning management systems, and because I think that there may be something special about how our learning management system handles iframes.

jcsteh commented 7 years ago

P2 because this sounds like it's high impact. However, we need to reproduce it first. A few notes:

  1. Firefox stable has a bug which causes problems like this. This should be tested with Firefox nightly as well.
  2. We should also test with Chrome Canary, as Chrome accessibility is undergoing fairly rapid changes.
  3. This is very possibly due to browser bugs and it's possible the only thing we can do is file them. However, that's still an important piece of work. :)
josephsl commented 7 years ago

Hi, May I add Edge to this equation please? That way folks using Windows 10 can also help you and see what’s up and report something to Microsoft. Thanks.

jcsteh commented 7 years ago

We should definitely test this kind of stuff with Edge, but I'd rather not address that in this issue, as Edge accessibility is still very much in flux.

MelSumner commented 6 years ago

Is there any progress or update on this issue?

Adriani90 commented 5 years ago

@Regis-ID-and-T could you please upload an example where we can reproduce this imediately without having to iframe anything? At least for me it is not possible to do it at this time. Thank you for your assistance.

brennanyoung commented 4 years ago

We're seeing a weird issue on Chrome (but not FF) with two levels of iframe nesting, where NVDA is reading content which is no longer in the DOM. The structure is

When we get to Main content, I can browse to elements from the intro page, even though they should have been completely replaced by the main content.

NVDA+f5 seems to fix the problem. Is this a related or different issue?

feerrenrut commented 4 years ago

@brennanyoung I think it is a different issue. However, I have had other reports similar to what you describe but have not been able to reproduce it myself. Could you open a new issue with a repro sample?

brennanyoung commented 4 years ago

Will do, as soon as we can narrow it down to a bare bones case!

brennanyoung commented 4 years ago

OK, false alarm. The issue does not happen on the latest Canary nightly build or on older versions of Chrome. It's a new issue and will be fixed at some point. (Thank goodness! This was a really weird symptom!)

feerrenrut commented 4 years ago

@brennanyoung do you have a chromium bug tracker link?

aminpaks commented 4 years ago

@Adriani90 Hi, we are facing the same issue. It seems that sometimes when we have multiple iframe within the page and if the focus is moving dynamically NVDA doesnt follow where the focus is at the current element by pressing "Arrow down" to move to the next element in the apge.

Here is a sample app to demo how to repro the issue.

  1. Open the app in Chrome
  2. Open NVDA and speech viewer
  3. Tab to the "Dynamic App" link and press enter
  4. Wait for the app to load and observe that focus jumps to the heading level 1 inside the iframe
  5. Press "Arrow down" and observe what's read in the speech viewer

Actual result:

Expected result:

PS: If you think this is not related to this issue I can create a new one.

bbudd commented 4 years ago

Hi all,

We've run across this same issue, but for us it seems to be that we have a React app (dynamic content) which loads an iframe which also hosts a React app (more dynamic content which only loads once the top level dynamic content is finished loading), which attempts to take focus once it's rendered. We have a lot of asynchronous stuff that happens in other places in the top level, causing different renders to happen, and I think it's just that NVDA can't keep up with all the changes, and that last bit of focus grabbing puts it over the edge. Thankfully for us, we also have messaging going from the frame on up, and we've found a (hopefully temporary while NVAccess fixes this) workaround:

If you hide the top level dynamic content with display: none, then wait for the iframe content to fully render before sending a message (we're using the componentDidMount event), then set display: block on the top level content, it appears to fix the issue for us.

Of course, we had to do the whole thing because of the different dynamic parts of our page. YMMV with a more targeted approach than our admittedly broadsword surgery.

Hope this helps!

criscoween commented 3 years ago

I'm running into an issue similar to what @bbudd describes in Chrome. We load an iframe popup (specifically, Google's invisible reCAPTCHA v2) and it receives focus. If I have NVDA running and hit "enter", the click event actually fires on the link that launched the popup, even though document.activeElement is in the iframe. If I don't have NVDA running, the click event fires on the iframe element as expected. If I click with my mouse, I see the expected behavior. If I tab back and forth between elements in the iframe before hitting "enter", I also see the expected behavior. Arrowing up and down has the same problem.

I'm able to reproduce this issue reliably on one page, but not on other pages that use the same iframe popup.

It looks like NVDA is causing focus to partially remain on the link that launched the iframe, even if I explicitly clear focus with blur(). Is NVDA somehow tracking focus independently of the browser? Is there a way to make NVDA "catch up" with browser focus?

feerrenrut commented 3 years ago

Hi @aminpaks @bbudd @criscoween it would be really helpful if you could all create your own independent issues. Due to the complexities involved in this type of problem it is very possible you are seeing different things. Due to the very active development of NVDA, browsers and web accessibility it is important to know the versions of software you are using to start to diagnose the issue. All this is requested in our bug template. Thanks!

@aminpaks In the expected / actual behavior, please quote the text you expect NVDA to read rather than describe where it is on the page, this helps to remove the ambiguity. I tested your sample app with NVDA 2020.4 and a recent alpha build, following the steps to reproduce, NVDA announced what I expected. Note, since some speech is cancelled (eg after a focus change event), but the speech viewer instantly shows all speech started, it may not accurately represent what a user will actually hear. We are aware of this limitation, and would like to improve it, however for now, I'd recommend testing as real users do.

jmuela1015 commented 2 years ago

@criscoween Did you ever find a resolution. I have similar issues with reCAPTCHA v2 (invisible) using react.js I was going to create an issue, but wanted to check to see if you had any findings.