Title, headings and language in relation to iframes

[brennanyoung]

I would like to request some clarification about titles headings and language in relation to iframes

Please correct me if I am wrong, but as I understand the spec: Both the parent page and the child page should have lang attributes and <title> elements, but the lang attribute is not required on the iframe element itself. As this is not really mentioned or indicated anywhere, there is room for doubt, which wastes time. It's plausible to imagine that these features 'cascade down' into the iframe content by default.

"Understanding Headings and Labels" uses some opaque jargon 'For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page.' - I am still not clear whether "non-embedded" includes iframe content or not, but I understand that the iframe itself needs a meaningful accessible name (most typically a title attribute).

Sufficient Techniques or Failure examples would be an adequate and appropriate way to clarify this, since these are HTML-specific topics. The same example(s) could illustrate the relevant SCs in the 'Understanding...' docs about Page Titled, Language of Page, Headings and Labels and perhaps even Info and Relationships (although that SC already has dozens of examples).

[alastc]

My interpretation (although I haven't looked into this for a while):

• Page titles would apply to the primary page you have loaded at the URL. An iframe should have a title-attribute to provide a name, but isn't required (by WCAG) to have a <title> tag.
• Language of the page would apply at the page level, but I think the contents of an iframe would be caught by Language of the Parts, and the quickest way to pass that would be applying lang at the html/body level.
• For Headings & Labels, I think you are looking at the definition of "Web page". Each relevant definition is included in the Understanding document. In this case the note you reference isn't relevant to this SC.

[brennanyoung]

I've been given a very useful tip about this.

If an iframe element has no accessible name (i.e. a title attribute) an AT user will be required to focus into the frame to discover what it is. That's a Headings and Labels violation, AFAICT.

Similarly (I suppose) it would be necessary to provide lang on the iframe element in cases where the content loaded into it is in a language other than that of the parent page, so that users don't need to focus into the iframe to discover the language used there. (Language of Parts).

If the content is in the same language as the parent page, it should (I suppose) be sufficient to put the lang attribute on the loaded child page, and omit it from the iframe element. There still needs to be a lang on the parent root/body, though.

I'd be happy to be corrected about any of this, since they are not clearly stated in the current documentation, and are a mixture of deduction and unofficial advice. So there would be real benefits in making these rules of thumb explicit with some appropriate examples.

[mraccess77]

FYI. The ACT rules only covers iFrames that are in the focus order (https://act-rules.github.io/rules/cae760)

Strictly speaking there could be other situations where an iFrame would need a name as well - when it acts like a named region of visually distinct content - however, practically, most people flag all iFrames missing an accessible name.

From the embedded standpoint - an iframe is considered part of a page. What is not covered as a web page is when a web page is embedded in something else like an Electron software app (from what I understand).

[JAWS-test]

See https://www.w3.org/WAI/WCAG21/Techniques/html/H64

[korneevamg]

From the embedded standpoint - an iframe is considered part of a page.

I'd like to chime in on this point. If an iframe is part of the page, it should also obey the overall heading hierarchy of the main page. G141 Organizing a page using headings describes the proper nesting:

To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.).

So, if I decide to embed a page as an iframe, it cannot have an h1 heading, right? It sounds a bit too harsh, unless I'm missing something.

[mraccess77]

To my knowledge there is no prohibition of having multiple h1s on the page (with or without an iframe) if they correctly denote structure of the page.

I agree for many iframes that it could be difficult to know the heading levels on the containing page. I the attempts at HTML outline were aimed at situations like this where there was syndicated content aggregated on pages and a loose heading structure was seen as desirable.

[barrierefreie-webentwicklung]

Thanks for the clarification. As the document outline concept is no longer relevant, we are back to the plain heading levels.

WHATWG is pretty clear about multiple h1s:

A document can contain multiple top-level headings (cf. section 4.3.11.1 Sample outlines, third example)

MDN documentation states it as follows:

While using multiple h1 elements on one page is allowed by the HTML standard (as long as they are not nested), this is not considered a best practice.

Several accessibility experts advise against the usage of multiple h1-heading on one page (e.g. Accessible heading structure, The Truth about “The Truth About Multiple H1 Tags”).

The WCAG does not clearly prohibit multiple h1s on one page though (at least not verbatim).

So, it sounds like an iframe can have its own h1 in addition to the h1 in the main content. I still don't know how to go about the rest of the heading structure (iframe + main content, cf. G141 Organizing a page using headings), though... Your advice is still much appreciated!