Take the 2-minute tour ×
Drupal Answers is a question and answer site for Drupal developers and administrators. It's 100% free, no registration required.

We need to embed a software application (by URL) into a Drupal 7 site. The resulting page needs to be Section 508 compliant. I have been told that iFrames are not Section 508 compliant. That is what we used in the past. Is there an alternative that is accessible?

share|improve this question
Who told you that iframes are not 508 compliant? The guide for Web-based Intranet and Internet Information and Applications (access-board.gov/sec508/guide/1194.22.htm) is silent on the matter, but does say that frames are allowed and provides guidance on their use. Providing alternate content for iframes is an advisory technique for WCAG 2.0 Level A, but not a sufficient one. –  MPD Mar 22 '12 at 15:38
Well, as I said at below, if a user isn't able to use their screen reader to fill in advanced search form fields due to the iFrame, then alternative content won't be considered good enough. As to who told me, let's just say the people in charge of accessibility at my organization. I will show them this discussion page, the links people have provided, and will see what transpires. –  mlangfeld Mar 22 '12 at 18:02
add comment

2 Answers

up vote 1 down vote accepted

I am not claiming to be a 508 or a WCAG expert, but I am working through some of these issues with a client right now (though, not for a Drupal site, but it is why I have all of these links handy).

In the current version of the Section 508 standard, section 1194.22 describes the standards for "Web-based intranet and internet information and applications.". iframes are not explicitly mentioned, though frames are

(i) Frames shall be titled with text that facilitates frame identification and navigation.

This is explained in the accompanying guide with some examples. You can extrapolate this to an <iframe> and use the title attribute.

The current draft doesn't really mention details like this, but everything web related essentially says that you need to meet WCAG 2.0 Level A and AA (it is more complicated that that if you dive into the draft).

If you pour through all of this, the sufficient technique is to add a title onto the iframe. There is also an advisory technique to provide alternate content.

Based on the comments in @Clive's answer, I would say the @mlangfeld's situation is more of a grey area, as the iframe contains something functional and not just non-text content.

This shows where automated testing isn't sufficient to meet all guidelines (and many of the Level A and AA ones need to be manually verified anyway); it is possible to pass these automated tests and still have a horribly inaccessible website.

Getting this back on track for Drupal, in an ideal world, I would make a custom module that would interface with the remote application via webservice, and use this instead of the iframe. The module would have forms defined to replicate the application, and the submit handlers would call out to the webservice, and then build results. If you can't do a true webservice, then I would investigate a custom module that serves as a proxy between Drupal forms and POSTing to the application's forms.

This way you can ensure that your forms are accessible, and that you eliminate the complications of the iframe. If this can't be done, then I would get an actual current screen reader and test what happens, and work through options with the client (either internal or external).

share|improve this answer
Thanks, @MPD. I agree, the best way to handle this is to test with a screen reader. So, you find that a title tag is better than a paragraph tag for the description. Sounds good. –  mlangfeld Mar 23 '12 at 14:08
add comment

I can't find a single reference on Google that says iFrames aren't section 508 compliant...however they will fail compliance if you do not:

Provide alternative content for IFRAME elements

iFrames can contain nested alternative content, like so:

<iframe src="frame.html">
  <p>Description of the loaded content</p> 

The rationale listed for this is:

Some browsers do not support the IFRAME element, or do not have the ability to load multiple documents together. It is therefore necessary to provide alternative content for this element even if the IFRAME only loads HTML.

This information came from here, but all of the other links I found on Google said exactly the same thing in one way or another.

share|improve this answer
Thanks for your answer, Clive. Would screen readers be able to access the content in the iFrame? Advanced search forms to be able to be navigated, completed, to search the content in the external application. –  mlangfeld Mar 22 '12 at 14:58
I think for the most part screen readers will be able to access iFrames (support is definitely better for iFrames than standard Frames). There's a good article on the subject here which goes into more detail. The quote from there is "Generally speaking, iFrames are better supported on screen readers than traditional HTML frames.". I guess it depends a bit on how up-to-date the particular screen reader software is –  Clive Mar 22 '12 at 15:05
If you go by the latest 508 draft (access-board.gov/sec508/refresh/draft-rule.htm), then 508 compliance for web means confirming to WCAG 2.0 Level A and Level AA success criteria. According to w3.org/WAI/WCAG20/quickref, alternate content for iframes is an advisory technique and not a sufficient one (see w3.org/TR/2012/NOTE-UNDERSTANDING-WCAG20-20120103/… for definitions). –  MPD Mar 22 '12 at 15:50
@MPD Very interesting, wasn't aware of that –  Clive Mar 22 '12 at 16:05
When I was web manager at IPM, I managed the redesign and development of our site, moving it into Drupal. We embedded two pages into our site (from an external software app) using iFrame I believe. Here's the URL of one: ipmglobal.org/about/careers/current-opportunities I just ran it through WAVE accessibility tester, and it seemed to pass, though I get an error when trying to see what it said about the iFrame. Interestingly, all it noted was some Javascript in the header, not the iFrame. Seems to have passed. –  mlangfeld Mar 22 '12 at 18:15
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.