What are usability, accessibility, screen-reader or any other development, functionality, cross browser issue with iframe?

Question

What are the usability, accessibility, screen-reader, or any other development, functionality, or cross browser issues with <iframe>?

Is there any alternative for <iframe>?

And are there any JavaScript/jQuery or server-side techniques which can decrease the usability, accessibility, or screen-reader issues with <iframe>?

Why has the W3C not included <iframe> in XHTML Strict, while HTML 5 supports <iframe>?

update:

I found some good thoughts here also : http://uxexchange.com/questions/1817/iframe-accessibility-and-usability-issues

Answer 1

Accessibility:

• It's harder to scroll you iframe , your mouse must be int the range of the iframe. It difficult with people with movement desabilities
• Browsers for blind people may not include the content from you iframe and those people will not reach to it.

Usability:

• It's not cool when you have several scroll bars on the main window and on the iframe. It's difficult for scrolling

Other issues:

• Mobile browsers probably won't render you iframe. Even if it render it, it will look bad and ugly.
• Search engines will have hard time indexing your pages in the iframe. Probably they will skip it or won't take indexed properly
• Loading an iframe will take longer time than a page with the same content and no frame

Answer 2

If you have a single Iframe, there would be little issue. However, multiple iframes compound the problem. A point of focus is not clearly available and the screen readers are not intelligent enough to find visual correlation (same reason why tables are bad for design). ARIA is an attempt being made to resolve some similar issues. YUI plugin link has more information.

However iframes do find their place in design. In one project I worked before, the page contained two iframes (one of them hidden) and the hidden frame was used to download an authentication applet. This doesn't add any accessibility woes as the point of attention is limited to a single iframe which seemlessly merges with the page

Answer 3

Why W3C not included Iframe in XHTML Strict

Because at the time it was seen as a bastard child of the widely-reviled <frame> tag. In principle <iframe> has many of the same properties as <frame>, but in practice it seems to have encouraged more tasteful use, generally avoiding the worst of the navigational and usability problems that frameset interfaces suffered.

While HTML 5 is supports Iframe ?

(a). Because, unlike the <frame>, <iframe> has since turned out to be essential for mixed documents such as those including adverts, and many types of web application. There are still problems, as mentioned in other answers, but generally the <iframe> is seen as a necessary feature that is here to stay. This isn't true of <frame>, which is a “non-conforming feature” in HTML5 (the nearest HTML5 gets to any kind of ‘strict’).

(b). because the authors of HTML5 don't so much care about encouraging good practice anyway; it's about documenting what user-agents must do. They have thrown every obsolete feature of HTML4 into the standard, along with a lot of other traditional but dodgy browser behaviour including every last quirk of broken tag soup parsing. [aside: I am greatly amused to see the latest argument being discussed on their list being how the <isindex> element should be handled — an element that literally nobody has used since HTML 2.0's form elements made it obsolete in 1995.]

Given the staggering size and complexity of HTML5, it's not really surprising that they didn't want the extra effort of declaring a more limited ‘strict mode’ profile. As work comes to an end, though, I would love to see an XHTML5 Strict or similar effort to trim back some of this mess. As it stands, Hixie and chums have taken a snapshot of every nasty hack a browser has to put in for compatibility today, and made it a standard requirement for all browsers in the foreseeable future, effectively condoning the bad practice.