W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2012

RE: Evaluating an iframe-based website

From: Jonathan Avila <jon.avila@ssbbartgroup.com>
Date: Wed, 29 Feb 2012 08:41:03 -0500
Message-ID: <e86b0be37dd7a8da5589761ff1cf7e1f@mail.gmail.com>
To: WAI Interest Group <w3c-wai-ig@w3.org>
[Ramon wrote]
> My interpretation is that I cannot then exclude the URI of the embedded
content from the Conformance Declaration.

You could consider creating a WCAG Support Statement rather than a
conformance statement.  Depending on the requirements or the laws you are
trying to meet this can often be a useful approach.


-----Original Message-----
From: Ramón Corominas [mailto:listas@ramoncorominas.com]
Sent: Monday, February 27, 2012 2:47 PM
To: Jonathan Avila
Cc: WAI Interest Group
Subject: Re: Evaluating an iframe-based website

Ok, let's hypothesise and put specific contents, just to see the

Situation 1: I have a page www.domain.com that has a logo and the main
menu in the header, and also a common footer. Then I have an <iframe
id="content"> where every single content is loaded. Let's say that I have
4 different simple contents: "/home.htm", "/products.htm", "/contact.htm"
and "/a11y.htm". Let's suppose that only the "/contact.htm" page (that
will be loaded inside the iframe) is not accessible (and that I can change
the <title> dynamically using scripts).

My first thought is that I can exclude the URI
"http://www.domain.com/contact.htm" from the Conformance Declaration and
assume the rest of the website is considered accessible, even if the whole
website shares the root URI. However, my concern is that I cannot give
separate URIs for the other 3 "accessible" pages, but the main one, and
thus I am not sure if I can "exclude part of a page", that is, the
"/contact.htm" iframe-based content. Indeed, there are two paragraphs in
the definition of "Web page" that seem to prohibir this possibility:

"Note 2: 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."

My interpretation is that I cannot then exclude the URI of the embedded
content from the Conformance Declaration.

And, more importantly:

"Example 2: A Web mail program built using Asynchronous JavaScript and XML
(AJAX). The program lives entirely at http://example.com/mail, but
includes an inbox, a contacts area and a calendar. Links or buttons are
provided that cause the inbox, contacts, or calendar to display, but do
not change the URI of the page as a whole."

Although I don't have an AJAX application, the result is more or less the
same: I have a single URI that is not changed while I use the site, so it
seems that I have to consider the single-URI website as a whole in terms
of conformance.

Situation 2: I have a website that is built using templates. Each page has
a single URI, but all pages share a common <iframe> where a Twitter widget
is loaded that is not accessible. Of course I have a different URI for the
widget content, but it is loaded within the specific URIs of each page of
the website. Due to CR #2 I cannot exclude this content.
That's all. But then, what is the difference with the previous case? I can
see it in terms of "real" accessibility, but formally it is not so clear
to me.

Thanks in advance,

Jonathan wrote:

> [Ramon wrote]
>> My question comes because I feel that I cannot consider the
>> iframe-based content as separate from its parent, because it could
>> lead to failures that would not exist when this content is in context
>> (for example, heading structure, links purpose, multiple ways...). So
>> I cannot separate the iframe from its context, but at the same it
>> sounds a bit hard to me that one
> You should be able to locate the URI for that frame from the DOM and
> the crub trail  and indicate the site except that page meet the
> conformance level criteria.
> While I agree that the page cannot be taken out of its context as far
> as reporting - for normative testing purposes I would generally test
> the each iFrame was a page and the containing page as a separate page.
> During functional testing the pages together would be taken into
Received on Wednesday, 29 February 2012 13:41:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:39 UTC