什么是可用性，可访问性，屏幕阅读器或任何其他开发，function，iframe的跨浏览器问题？
的可用性，可访问性，屏幕阅读器或任何其他开发，function或跨浏览器问题是什么？
还有其他选择吗？
是否有任何JavaScript / jQuery或服务器端技术可以降低的可用性，可访问性或屏幕阅读器问题？
为什么W3C不包含在XHTML Strict中的 ，而HTML 5支持 ？
更新：
我在这里也找到了一些好的想法： http ： //uxexchange.com/questions/1817/iframe-accessibility-and-usability-issues
辅助function：
- 滚动你的iframe更难，你的鼠标必须在iframe的范围内。 有运动能力的人很难
- 盲人浏览器可能不会包含您iframe中的内容，而且这些人无法访问它。
可用性：
- 当主窗口和iframe上有多个滚动条时，这并不酷。 滚动很难
其他问题：
- 移动浏览器可能无法呈现您的iframe。 即使它渲染它，它也会看起来很糟糕和丑陋。
- 搜索引擎很难在iframe中为您的网页编制索引。 可能他们会跳过它或不会正确索引
- 加载iframe将比具有相同内容且没有框架的页面花费更长的时间
为什么W3C不包含XHTML严格的iframe
因为当时它被视为广受诟病的标签的私生子。 原则上， 具有许多与相同的属性，但实际上它似乎鼓励了更有品味的使用，通常避免了框架集界面所遭受的最糟糕的导航和可用性问题。
虽然HTML 5支持Iframe？
（一个）。 因为，与 ， 已经certificate对于包括广告在内的混合文档以及许多类型的Web应用程序是必不可少的。 如其他答案中所提到的，仍然存在问题，但通常被视为必须保留的特征。 对于 ，情况并非如此，这是HTML5中的“不符合要求”（最近的HTML5可以获得任何类型的’严格’）。
（b）中。 因为HTML5的作者并不关心鼓励良好实践; 它是关于记录用户代理必须做什么的。 他们将HTML4的每个过时function都抛入标准，以及许多其他传统但狡猾的浏览器行为，包括每一个破碎的标签汤解析的最后一个怪癖。 [旁白：我很高兴看到他们列表中讨论的最新论点是如何处理
鉴于HTML5的大小和复杂性令人震惊，他们不希望额外努力宣布更有限的“严格模式”配置文件并不奇怪。 然而，随着工作的结束，我希望看到XHTML5严格或类似的努力来削减一些混乱。 目前，Hixie和chums已经对浏览器今天要兼容的每一个讨厌的黑客进行了快照，并在可预见的未来使其成为所有浏览器的标准要求，有效地纵容了不良做法。
如果你有一个iframe，那就没什么问题了。 但是，多个iframe会使问题复杂化。 焦点不明显，屏幕阅读器不够聪明，无法找到视觉相关性（表格对设计不利的原因也是如此）。 ARIA正试图解决一些类似的问题。 YUI插件链接有更多信息。
然而，iframe确实在设计中找到了自己的位置。 在我之前工作的一个项目中，页面包含两个iframe（其中一个隐藏），隐藏的框架用于下载身份validation小程序。 这不会增加任何可访问性问题，因为关注点仅限于单个iframe，它与页面无缝合并