This Wiki page is edited by participants of the Protocols and Formats Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.


From Protocols and Formats Working Group Wiki
Revision as of 16:17, 18 February 2010 by Dbolter (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

IFRAME Accessibility Inquiry

The Web Accessibility Initiative, and the accessibility comunity at large, has been asked:

  1. What is the current state of accessibility of IFRAME?
  2. What are the outstanding accessibility problems inherit to IFRAME, or have they been mitigated?
    1. if, for example, one has a document embedded in an IFRAME which has access keys defined for it, will the embedded document's UI controls take precedence when the focus is in the IFRAME? what about conflicts between embedded UI controls and UI controls in host documents? what if a tabindex value has been defined for the IFRAME, and the document in the IFRAME has its own tabindex order?

The basic question is: How do the two documents interact and what can be done to standardize this interaction? Is it possible to harmonize W3C's efforts on IFRAME reform; consult, for example, the definitions of IFRAME in XHTML2 (a subject which was revisited after having been dropped), the XHTML IFRAME Module and the XHTML Legacy Module with IFRAME in HTML5; as well as with OpenAjax's support for iFrames

What Needs to Be Documented/Corraborated

What precisely are the problems with IFRAME today? here is a very rough thumbnail:

  1. tension between global and scopeable UI controls (accesskey, tabindex, etc.)
  2. horizontal and vertical scrolling impose an undue burden for several user groups;
  3. one can't resize an IFRAME; one can only use the User Agent's scaling mechanism, which is crude/gross at best;
  4. ARIA will help with IFRAME accessibility, yes, but what is still lacking in non-ARIA enabled technology, to support IFRAME accessibly?

Providing Feedback

Since this is a read-only wiki for those who do not belong to the Protocols & Formats Working Group, please send all comments to ( is a publicly archived mailing list. Please use the keyword "[iframe]" in the Subject line of your emessage.


Definitions of IFRAME


  • IFRAME in HTML4.01
    • sandboxing attribute (new)
    • seamless attribute (new)
    • note: the longdesc attribute for an IFRAME has been dropped from HTML5
      • reasons to support restoration of longdesc for IFRAME:
        • easiest rendering solution solution for UAs that do not support IFRAME or have support for IFRAME switched off
          • note: suppressing IFRAME is still, as of 2010, a regular option offered by most assistive technologies;
        • easiest work-around to having to build an IFRAME DOM subtree for the content of the IFRAME;
IFRAME-related bugs in HTML5

note: bugs are listed in numeric order by bugID number.

Other Manifestations of IFRAME

  • XHTML IFrame Module
    • note: does this document have a maintainer working group? should PF and (your suggestions here) develop one?
    • question: what is the TAG's opinion of IFrame, as a module and a concept, and what is their processing model for IFRAME?
  • IFRAME in OpenAjax

Accessibility Documentation on the Use of IFRAME

Email Threads