My site currently has an overlay on it that performs DOM manipulation. How does RAMP handle this situation?

RAMP’s accessibility scanner tries its best to scan a webpage in the exact state that a typical new user will see it in. This means that if you have an overlay on your website, our scanner will attempt to load that overlay and the changes it makes to the HTML. 

However, due to the way the overlay widgets work we may end up scanning the page before the DOM manipulation occurs. Here are some more technical details about this:

Knowing when a webpage is fully loaded is actually a difficult problem to solve. For example, a page might “look” fully loaded but actually there is a big gif loading in the background that suddenly pops into view 5 seconds later. Or maybe a webpage is in a continual state of loading, say, with a live chat that’s constantly loading in new chats. Or an analytics service sending pings to and from the browser every few seconds. How can you know which network requests will update the page and which won’t? You mostly can’t! 

Because of this, our scanner has to draw the line in the sand somewhere and say “this is what a fully loaded web page looks like”. For our scanner, we define a webpage as “loaded” when there are 2 or fewer pending network requests (think loading images, stylesheets, gif, fonts, analytics, data fetching, etc) OR we’ve waited for 2 minutes (subject to change) and the page hasn’t made any significant progress. Once one of those conditions are met, we do our best to test the webpage in whatever state it may be in. 

It’s important to note that the “final 2″ network requests are typically things like third party analytics or, sometimes, may be your overlay scripts. If overlay scripts are particularly heavy and are consistently some of the last things to load (and execute!!) on your website, you may experience “flaky” testing within RAMP depending on whether that overlay script was fully loaded or not.