W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: html 5 and accessibility issue

From: Robert Burns <rob@robburns.com>
Date: Sat, 30 Jun 2007 10:28:58 -0500
Message-Id: <3A3CCD51-C1A3-42F4-9953-7B9D70B5CD46@robburns.com>
Cc: "aurelien levy" <levy@tektonika.com>, public-html@w3.org
To: Anne van Kesteren <annevk@opera.com>


On Jun 30, 2007, at 9:08 AM, Anne van Kesteren wrote:
> On Sat, 30 Jun 2007 15:53:39 +0200, aurelien levy  
> <levy@tektonika.com> wrote:
>> - actually their is no fallback content for embed element
>
> Why is that needed for plugins?

That's when fallback content is needed: for non-text media (that is  
sometimes serviced through plug-ins).

>> - the only fallback content for iframe elements is pure text, i  
>> think we need to authorize an "a" element to link to the content  
>> of the iframe
>
> Doesn't the <iframe> do that already? I'm not sure <iframe> needs  
> "fallback" content at all.

<iframe> in HTML 4.01 has %flow fallback content. In HTML5 it is not  
supposed to contain anything but another browsing context (another  
html file I believe though that's probably not explicit or clear  
enough by simply saying a browser context ). In other words now the  
draft reads:

"An iframe element never has fallback content, as it will always  
create a nested browsing context, regardless of whether the specified  
initial contents are successfully used."

However, if it said that the type of the iframe @src had to begin  
with "text/  or "application/xml" then that might be sufficient.  
Simply saying a browser context could lead authors to think a direct  
@src link to an image or other non-text media was allowed (even PDF  
or Flash might require fallback content since those do not have the  
accessibility capabilities of HTML).

Take care,
Rob
Received on Saturday, 30 June 2007 15:29:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:01 GMT