This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
PROBLEM: while @title is a global attribute, @title should be a required attribute for FRAME and IFRAME in HTML5 DETAILS: @title has been used since HTML4 by assistive technologies to present the user with information as to the nature and function of the FRAME or IFRAME for which it is defined. This is reflected in the Web Content Accessibility Guidelines, Level 2 (WCAG 2.0) which includes "Technique H64: Using the title attribute of the frame and iframe elements" QUOTE cite="http://www.w3.org/TR/WCAG20-TECHS/H64.html" The objective of this technique is to demonstrate the use of the title attribute of the frame or iframe element to describe the contents of each frame. This provides a label for the frame so users can determine which frame to enter and explore in detail. It does not label the individual page (frame) or inline frame (iframe) in the frameset. Note that the title attribute labels frames, and is different from the title element which labels documents. Both should be provided, since the first facilitates navigation among frames and the second clarifies the user's current location. The title attribute is not interchangeable with the name attribute. The title labels the frame for users; the name labels it for scripting and window targeting. The name is not presented to the user, only the title is. UNQUOTE EXAMPLE 1: @title used in FRAME <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>A simple frameset document</title> </head> <frameset cols="10%, 90%"> <frame src="nav.html" title="Main menu" /> <frame src="doc.html" title="Documents" /> <noframes> <body> <a href="lib.html" title="Library link">Select to go to the electronic library</a> </body> </noframes> </frameset> </html> EXAMPLE 2: @title used in IFRAME <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>A document using iframe</title> </head> ... <iframe src="banner-ad.html" id="testiframe" name="testiframe" title="Advertisement"> <a href="banner-ad.html">Advertisement</a> </iframe> ... </html>
I'm not sure this is such a good idea. iframes in particular are often used as part of the UI of a page in a "transparent" way - there's some controls in it that are part of the tab cycle, but the user is generally not made aware of the fact that there even is a subframe. In such a case, it seems like there is no specific need to give a description of the iframe. As for the <frame> element (as opposed to <iframe>), it is not conforming in HTML5, so it doesn't make sense to have authoring requirements for it.
(In reply to comment #1) > iframes in particular are often used as part of the UI of a page in a > "transparent" way - there's some controls in it that are part of the > tab cycle, but the user is generally not made aware of the fact that > there even is a subframe. In such a case, it seems like there is no > specific need to give a description of the iframe. Such "iframe" elements should be given the "seamless" attribute. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless So long as HTML5 includes authoring requirements, I support requiring "title" for "iframe" elements that do not have the "seamless" attribute. It's something authors tend not to think about: a validator error would raise awareness of this issue, and it's a pretty easy fix for authors to make. > As for the <frame> element (as opposed to <iframe>), it is not conforming > in HTML5, so it doesn't make sense to have authoring requirements for it. Agreed.
(In reply to comment #2) > (In reply to comment #1) > > iframes in particular are often used as part of the UI of a page in a > > "transparent" way - there's some controls in it that are part of the > > tab cycle, but the user is generally not made aware of the fact that > > there even is a subframe. In such a case, it seems like there is no > > specific need to give a description of the iframe. > > Such "iframe" elements should be given the "seamless" attribute. > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless > > So long as HTML5 includes authoring requirements, I support requiring "title" > for "iframe" elements that do not have the "seamless" attribute. It's something > authors tend not to think about: a validator error would raise awareness of > this issue, and it's a pretty easy fix for authors to make. I'm not so sure about this. The sites doing this today do not use @seamless, and often want the content to fit in a fixed rectangle. Pushing them to use @seamless has two significant potential downsides: 1) In the long term, if they do not actually desire the layout and styling effects of @seamless, they will have to go out of their way to reverse them simply to represent that their iframe is for partition purposes only and does not have a designated purpose. 2) Currently no browser yet implements @seamless. If the validator started to require either @seamless or @title, sites could start adding @seamless as a voodoo talisman, without actually intending any effect other than to silence the validator. If a significant number of sites start doing this, it will poison the ability to really implement @seamless; the first browser to do so would break the Web. 3) Sites could end up being pushed to add @title where it is inappropriate, causing distracting and unhelpful tooltips in cases where the iframe is purely an organizational device. I am particularly concerned about point #2.
> The sites doing this often want the content to fit in a fixed rectangle. That's a design antipattern anyways, since it's unsafe to constrain text to a fixed height on the web. But it any case, it seems fairly trivial to apply a fixed height to content transcluded with "seamless". A validator could provide guidance on that point. > their iframe is for partition purposes only and does not have a designated purpose Sorry to be dense, but would you mind explaining how "seamless" would be inappropriate here with the help of a real-world example or two? Whenever "seamless" would not be appropriate, I think authors need to supply an accessible name for the iframe to allow users of screen readers and browsers that do not display iframe content (e.g. typical text browsers) to determine whether to navigate into the iframe contents, as Gregory described, since regardless of visual presentation the iframe is not, in fact, semantically part of the same document. "title" has been the traditional way to do this. Is there any other HTML-native feature you would suggest? If Case (2) is a serious risk, then we could always require "title" for *all* "iframe" elements and specify that it should be ignored when "seamless" is present. This could be better for backwards compatibility anyways. Alternatively, if "seamless" does not cover the use-case of "transparent" iframes, perhaps we need a feature that does?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I concur with Maciej's comments.
Gregory: Did you mean to add a comment when reopening it?
(In reply to comment #6) > Gregory: Did you mean to add a comment when reopening it? aloha, ian! yes, individual members of the User Agent Accessibility Working Group will be adding new information on this bug; i had initially thought that i would add to it during the UAAG telecon today, but the member who requested i log this bug wasn't in attendance, so he will be commenting on this issue himself
NEEDSINFO is the correct state for a bug for which necessary information will be added later. Please do not REOPEN until sufficient information is present for the bug to be evaluated.
The Bug Triage Sub Team agree that this should be a TF priority, @title is an important component for completeness where there are instances of iFrames/Frames in HTML content.
Since this is related to a larger discussion of embedded content, bug triage sub-team is considering this part of HTML A11Y TF Action 66 http://www.w3.org/WAI/PF/HTML/track/actions/66 and Action 90 http://www.w3.org/WAI/PF/HTML/track/actions/90 are meant to provide the information for this bug. Adding dependency on Bug 8885 to reflect that.
I think Sylvia’s responses make sense... there is currently no corresponding failure in WCAG ... so I would say that it is ok to leave this closed... I wouldn’t fall on my sword for it... iframes were not too common when we were originally making this, not the way they are used now. It was mostly to deal with Frames. The technique cited is certainly a recommended technique, but there is no corresponding failure technique for not doing it...
HTML A11Y TF has decided this bug can be closed.