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?
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
This is explained in the accompanying guide with some examples. You can extrapolate this to an
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).
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).
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:
iFrames can contain nested alternative content, like so:
The rationale listed for this is:
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.