From W3C Wiki
IFRAME Accessibility Inquiry
The Web Accessibility Initiative, and the accessibility comunity at large, has been asked:
- What is the current state of accessibility of IFRAME?
- What are the outstanding accessibility problems inherit to IFRAME, or have they been mitigated?
- A) 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 2 documents interact and what can be done to standardize this interaction? Is it possible to harmonize W3C's efforts on IFRAME reform, which include IFRAME in XHTML2 (a subject currently being revisited after having been dropped), the XHTML IFRAME Module and the XHTML Legacy Module versus IFRAME in the latest editor's draft of HTML5 and 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:
- tension between global and scopeable UI controls (accesskey, tabindex, etc.)
- horizontal and vertical scrolling impose an undue burden for several user groups;
- one can't resize an IFRAME; one can only use the User Agent's scaling mechanism, which is crude/gross at best;
- ARIA will help with IFRAME accessibility, yes, but what is still lacking in non-ARIA enabled technology, to support IFRAME accessibly?
Definitions of IFRAME
- IFRAME in HTML4.01
- IFRAME in HTML5 (current editor's draft)
- sandboxing attribute (new)
- seamless attribute (new)
- note: the
logdescattribute for an IFRAME has been dropped from HTML5
- XHTML IFrame Module
- IFRAME in OpenAjax
- XHTML Test Suite: IFrame