Keeping an Eye on the iFrame
A few weeks ago, my colleague Ken Nakata, was talking with a colleague at a digital publishing house about the new accessibility test scripts that we developed in WebAlign. These are designed to enable QA testers to validate most of the WCAG requirements without resorting to screen reader testing. While we firmly believe screen reader testing is essential, we also know that most testers cannot do screen reader testing effectively. Our accessibility test scripts rely on heavily on freely available JavaScript bookmarklets that make manual accessibility testing easier. When iframes were mentioned, our colleague just groaned. Yes, iframes are a problem when it comes to accessibility testing. Yes, iframes are commonly used o webpages and get passed over too often. Because of this, we thought we needed to say a few words about iframes.
What are iFrames and Why are They a Problem?
<iframe>'s are "inline frames", and they are a more modern version of the <frame> elements found on many web pages in the 1990's and are now deprecated with the release of HTML5. If you were an Internet user in the 1990’s, you will remember how some web pages used to have "hard" dividers—and each section of the page included content that seemed to be from different sources. Frames effectively combined content from different web pages into a single page within the element. Inline frames (i.e., iframes) are quite a bit less cumbersome than regular frames. In fact, most of the time when you encounter embedded videos on web pages, that content is contained within an iframes. These iframe elements are not just used for embedded videos, they also sneak up in a lot of other content—and in particularly with pop-up content (e.g., chat bots, dialogs, etc.).
iFrames themselves do not really create accessibility problems for users. In fact, making the contents of an iframe accessible usually follows the same rules as any other web content. The problem comes up in testing iframes for accessibility. The reason it is a problem is that many automated tools, such as automated accessibility scanners and accessibility bookmarklets, can only test the page that contains the iframe. Because the content of the iframe is effectively a separate page, these tools generally cannot "see" inside the iframe and so the iframe remains a black hole.
Testing Strategies for iFrames
While there are a few automated tools that claim to test the contents of iframe's, their success varies considerably. In general, automated tools and bookmarklets can work relatively well if the contents can be rendered in a separate page or tab. Let us review how that is done by looking at a simple example from the Texas Department of Transportation (TxDOT).
In the middle of the TxDOT page on is an iframe which includes a text input field that lets the user request text message alerts of traffic events in a highway project maintained by TxDOT.
Brute Force Review of Code
The most direct way to open this text message alert iframe in a separate window or tab is to find the URL for the page in the page’s source code. In Chrome, for instance, you would open the developer tools (Ctrl+Shift+I) and use the Elements tab to find the iframe in the source code.
The screenshot above shows the <iframe> element—and the src attribute for that element (https://www.slicktext.com/widget/v2/8827fe33f9b4d2145462a472170140ac) is clearly visible. Now just copy that URL, open it in a separate browser tab, and voilà, you have a page that can be tested using basic tools! For instance, below we have the form elements quickly identified by the Forms Accessibility Bookmarklet.
You can also run any bookmarklet on that iframe once you get it out of the iframe. For instance, the screenshot below shows that ANDI reports that the text input field in the iframe is inaccessible because it is not programmatically labeled.
This is our preferred recommendation for customers who want to do their own testing. It is a little clumsy at first, but once you have done it a few times, it is quick and easy—and amazingly effective!
Extensions and ANDI
Once upon a time, Chrome had a feature that let you right-click on an iframe and open that frame in a new tab or window. Then, that feature disappeared. Since then, other developers have created Chrome extensions to add this feature right back. A quick Google search for "extensions for opening iframes" reveals "Open iFrame" and "Open Frame" in the Chrome store. Both of these extensions add back the lost iframe function to Chrome.
In addition, the Social Security Administration’s ANDI Tool will also detect and open iframes to allow that tool to effectively review the contents of iframes.
Dynamically Generated iFrame Content
Alas, these solutions are far from perfect when it comes to iframes. One big problem from a testing perspective comes to iframes that do not have a static src attribute and where content is generated dynamically.
For instance, if you’ve ever tried to learn HTML, CSS, or JavaScript, you have probably tinkered around on www.w3schools.com and their useful "Try it Yourself" feature. This is shown in the screenshot above, as I make changes to the HTML code on the left side of the page, these changes are shown as rendered HTML on the right side of the page after pressing the "run" button. But things take a turn when I use my code inspector (described above) and find that the rendered content on the right side of the screen is living in an iframe (as shown in the screenshot below) and that the iframe has no src attribute.
This may seem confusing. After all, if a frame is effectively a web page, how can that page have no source? The answer is that the contents are generated on-the-fly by other JavaScript content on the page. And, while that may (or may not) create accessibility problems for assistive technology, it most definitely creates problems for testing.
My understanding is that there is no easy way to make this content available in a separate tab or window. In the w3schools code sample above, I could copy the html code inside the iframe, copy it to a text editor, save it as a separate HTML file, and run ANDI against that. And, just to prove it can be done, below is the screenshot of running ANDI on the locally-saved file after I added a <!DOCTYPE html> at the top of the file and saved it to my computer using the awesome Brackets editor.
But doing this can be a bit time consuming and, most of the time, when iframes are being dynamically generated in this way, the generated content is rarely as well-behaved if it decides to render at all.
Whether you frequently encounter badly-behaved iframes or not seems to really depend on the site you are testing or the team you are working with. Some organizations just love to create messy iframes while others do not. In our experience, messy iframes tend to be fairly uncommon and, when you encounter them, you may need to reach out to a professional to get any sense of its accessibility.
Be Aware of iFrames
The most important point is simply to be aware of iframes. They can get easily overlooked by automated testing solutions which can give you a false sense of accessibility compliance. Plus, manual testing with tools like accessibility bookmarklets tend to ignore what is inside the iframe and require you to treat them with extra care to verify that the contents of the iframe meet accessibility compliance.
If you are unsure about how to test your web pages, we are here to help. When you have a WebAlign subscription you also have weekly access to our live Zoom calls where you can discuss accessibility topics with our experienced accessibility professionals. You can also use our WebAlign community user forum to post questions and bounce ideas off other WebAlign users who may have already dealt with issues you are current facing. For less than what most spend on coffee at their favorite coffee shop each week, you can have access to the most up to date accessibility compliance resource available today. 
To find out more about how WebAlign can help you and your team successfully design, create, and maintain accessible web content, please visit our What is WebAlign page.
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “Accessibility Testing and iFrames”